I was reflecting on your email Ben... I agree, arbitrarily segmenting a 
blob into predefined sections for processing may not be the best focus of 
this long-term. Perhaps for a small region this would be useful. (e.g. 
"What color is the object I am holding?" Then it would be able to set an 
arbitrary vicinity in the FOV inside which to search for objects, around 
your hand.) But perhaps a more useful feature would be vector creation 
using various algorithms on the blob. 

For example, if we were to hold up a solid white flash card, the system 
could distinguish it by its markedly distinct color. Using a degree of 
fuzziness it could then draw lines around the uniform regions. This would 
allow us to "wireframe" an image from raw video input and potentially even 
allow us to "imagine" or recreate a reasonably close representation of what 
is in the field of view simply by mapping out the resulting vectors. This 
would also be scalable since the precision of our edges could start nice 
and blocky (read: Nintendo level graphics) and as our code efficiency and 
hardware allow, we can refine the precision of these vectors into more 
complex and detailed renderings. 

This could also end up playing nicely with other sensors or systems that 
are used for 3d spacial construction. For example, we could have a second 
camera or "eye" and use it for distance measuring, providing us further 
data about the lines being drawn (depth and slope). This could also 
potentially be paired with sonar or radar to the same end. Both sensors 
could be feeding the same 3d construct to provide more data and better 
overall precision. 

I am getting ahead of myself with this though. I'll start with catching up 
to the abandonware first and report any progress beyond that. 

Best regards,
Noah Bliss

On Friday, September 16, 2016 at 11:37:31 AM UTC-4, Noah Bliss wrote:
> I'm going to be showing a great deal of ignorance in this post, but who 
> knows, it might help. 
> I understand an issue recently discussed with embodiment concerns methods 
> for processing visual input. It's well known that at this time sending raw 
> video into atomspace is a bad idea and that humans have built in visual 
> processors that assist our conscious minds in understanding what our eyes 
> see. (Obvious simple example being that the image is preflipped). 
> I understand opencog has (in some form) a python api which leads me to 
> think using the visual processing engine OpenCV may not be a bad idea. It 
> has a fantastic python api, allows for exporting specific data from raw 
> video such as "33% of the screen is red", or  there are 2 lines in the 
> field of view." it also has a PHENOMINAL foreground/background separation 
> engine that allows only a processing of new or moving objects in the field 
> of view. 
> While a more mature opencog engine may prefer a more "raw" processor, I 
> see OpenCV as a great place to start for getting useful information into 
> atomspace quickly. 
> I have yet to start work on this, heck, I have yet to fully learn the 
> ropes of the current opencog system, but I wanted to at least drop the info 
> here in case anyone else had comments or wanted to get a head-start on me. 
> Best regards my friends. 
> Noah B. 
> PS: My personal experience with OpenCV was specifically dealing with 
> automated turrets. There are great YouTube examples of using OpenCV for 
> face-tracking webcams attached to servos, and blob isolating security 
> cameras if you wanted specific examples to look up. 

You received this message because you are subscribed to the Google Groups 
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to opencog+unsubscr...@googlegroups.com.
To post to this group, send email to opencog@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to