Universal Objects Database

[AndrewM]

It just dawned on me (I am slow sometimes) but in the above example, even if the white rectangular box was laying on its side with a height of 1 unit and width of 1.96 units, the program could still match it easily enough because it is comparing relative dimensions and not "actualities".

[Nyx]

I really don't get how people continually relate a standard in technology to a specific model.  It is specific minimum functionality.  http://en.wikipedia.org/wiki/Internet_standard

You obviously didn't really read my comment, but anyways... It never ceases to amaze me how people with some engineering background think they can improvise themselves AI experts. There's a very active subfield of computer science called COMPUTER VISION (http://en.wikipedia.org/wiki/Computer_vision). This field has been concerned with issues like object and scene recognition for decades... And they've come up with many interesting approaches which... You should look at. Some of them are very simple to implement and computationally efficient... Like the eigenvector based approach I just mentioned. You could also think of applying Hidden Markov Models (HMM) and neural networks to such problems, or work from spectral representations of images, which are less susceptible to changes in orientation, etc.

All of these approaches make ALOT more sense than trying to send images accross a network and match them to some raw database... Which, like I said, is never going to work, and isn't very practical (requires a fast connection) no matter the format of the image you send/receive. If you use eigenvector based approaches, you only need a database for training. Once this is done, images are "compressed". They're represented by essential components only... So you can represent an image by its features, using less than 1KB of memory, or whatever you can afford to use in your system.

Lookup tables haven't been the focus of AI researchers for um, say, 60 years?

So yeah uh... The computer scientists of the world would like to tell you that:

Now sit down and learn at least a *little bit* about AI, before you start trying to reinvent us a square wheel.

[silo_xtreme]

LoL - just the approach I was getting at. 

[Nyx]

LoL - just the approach I was getting at. 

Well my advice to you, if you do design such a database, is that too much information is always better than not enough. You should design lots of standardized tags that people can put on images... Allow them to upload matching stereo pairs, etc... If they don't have some of the info, they can omit it... But when someone wants images that have all the tags, they can query the DB for only images that have all the information their system needs. You definitely want lots of info about the camera(s) that took the picture(s), the lighting in the scene, etc to be stored, if available.

*Legally speaking*, if you want to make this research friendly... You probably want some licensing terms that say whatever you upload to the database must be public domain...

[silo_xtreme]

I'm with you on that

I'm also expecting to have other forms of visual data as well.  For example, say you don't have a CCD / CMOS camera.  You can "scan" the object with your sharp IR as well and still get a visual representation of the object.

[Nyx]

If you have some kind of ontology to describe the scene and/or objects in the scene, it would be nice to be able to tag multiple pictures as being of the same object in the same scene, or from the same scene, but taken from a different angle. People in vision often like taking pictures of an object from 100 different angles when trying to build 3D reconstructions of it, for example.

I also think you want to allow as high of a resolution as possible, to allow as much detail as possible... If you want to "future proof" your design. What you can do, however, is provide a standard fixed resolution representation as well.

[AndrewM]

Lookup tables haven't been the focus of AI researchers for um, say, 60 years?

I'll avoid the whole pissing contest it seems you want to get into, but want to point out that lookup tables are still very viable for DNA programming and genetic algorithms.  I guess we will have to find Chef and do a dance off now.  Just make sure butter's tap shoes are tied off well...   

The lookup tables were for images inside the robot, as opposed to having the entire database stored inside the robot itself, or having the robot call out to the internet for object recognition.  Smaller portions of the whole data for the individual task the robot is responsible, as opposed to knowing what everything in the world is.

[Nyx]

Eigenvector based approaches are kind of like a lookup table, but the lookup is much faster than going through a table and trying to find the nearest sample, because each sample is like a point in n-dimensional space... So the samples can be put in a kd-tree, and lookup takes time log(k), where k is a constant.

[AndrewM]

I'm also expecting to have other forms of visual data as well.  For example, say you don't have a CCD / CMOS camera.  You can "scan" the object with your sharp IR as well and still get a visual representation of the object.

Is the sharp IR accurate enough to get that kind of data?  I purchase a few about a month back, but have yet to use them for anything, so I'm curious on that.  All my IR in the past has been home built.

I haven't started down the road to robotic vision yet, but I know I will be in not too distant future, so I am starting to get excited about having a database to tap into when the time comes.  Slightly off the subject, but is there any intent to possibly having sample code for a few different setups for saving images for the DB and/or using the images from (I know getting the DB set comes first, but figured I would ask)?

[paulstreats]

Sharp IR are not exactly an accurate sensor, but maybe an option in the database to search for a closest match, or even the reverse if your robot is looking in the real world for an object then it can look around till it finds something within maybe a 10% error margin. (this feature must be included anyway or a slightly dented can etc... wont match up correctly)

Im sure that when the database begins it will be important to let people know how to use it so i should think that there will be examples and documentation.... Of course the main part is to decide on a structure which i think that everybody should express an opinion on (if there is more than 1 idea then maybe a stronger better storage system can work by meging more solutions). It would be really helpful if people could link to example of the data storages that they suggest. So if somebody thinks neural net systems are best then post a link with theories/examples etc.. on so we can all see and express opinions and also make the job easier for the person who is eventually going to make the database.

silo xtreme: since you are leading the project, have you thought of any systems that you are going to use yet? (maybe somebody can help with specifics, there are some experienced programmers on this site who will probably be willing to help create structures/algorythms or even just help optimise codes if needs be )

I would like to voice my opinion on seeing kohonen feature maps (again) as a way of storage physical object data. Also it could be worth looking into existing 3d graphics systems to see how they store shapes - strip count arrays etc... (there are lots of ways of optimising 3d vertexes all aimed at reducing storage space. think about those 3d games that you occasionally come across with a single .exe file which is only like 25kb long. Maybe the graphics wont be brilliant, but theyve got a lot of 3d object data in that 25kb)

[paulstreats]

sorry for this follow on post but anyway.....

If somebody decides that they dont like the final storage structure. Then i dont see why there is a problem in using your own structure on your own robot but downloading the data from the UOD. Surely if you are capable of making an effective and efficient storage system of your own then you are capable of converting data from the UOD into your own system. Maybe you could release your own system as a real world system and also realease cross convertion tools with it....

Somebody above mentioned that if it was possible then google would have done it. THEY HAVE - its just not correctly linked. ie. search google for a can of coke and you get loads of data about it. search google images for coke and you get loads of images. search google sketchup and you get a 3d model of a can of coke what more could you need.
The difference is that google is made for people to search through and not robots.

[Tsukubadaisei]

Somebody above mentioned that if it was possible then google would have done it. THEY HAVE - its just not correctly linked. ie. search google for a can of coke and you get loads of data about it. search google images for coke and you get loads of images. search google sketchup and you get a 3d model of a can of coke what more could you need.
The difference is that google is made for people to search through and not robots.

I mentioned that. I am not talking about the current image search methods using tags or related words with some keyword, like google does right now. I was talking about using a image for searching other images. And that is what I've been talking about through all the posts. For example the robot sees an object throgh the camera, and then search for this object in the database. Asking the robot to seach for something inputing a keyword in it is actually an already solved problem(for simple shaped objects).

[AndrewM]

Searching for an object is not all that difficult.  Of course it depends on the data contained in the database and how it is all stored.  But to give one example using a coordinate system (I think the initial suggestion was cartesian coordinates, but it really doesn't matter).

Without breaking out a tape measure, we'll assume a coke can is 2 inches wide and 4 inches tall.  The primary coloring of the can is red (I don't drink soda anymore, but last I checked I think this is accurate).  So we snap off a picture of a coke can using a color camera.  Poof, we have a 2D rectangle with coordinates of {0,4}{2,4}{2,0}{0,0}.  A keyword (numeric actually) search of objects containing only 4 outside points with those same coordinates returns say 500 objects.  We add to that a primary blob of color range in red, might be an RGB color range etc.  Down to 10 objects.  Then maybe do a search on object shapes internal to the outside shape, such as a logo using the same coordinate system.  Poof, we have a 90-something% match.

And that is how we *might* search for an object.  (I like the word "poof" btw).  As I said, it depends on what data is stored and how it is stored.  But looking for coordinates, or vectors, or color ranges from a database really is as easy as typing in "Coke Can" in google, if the data is stored in the right format.

In answer to how 3D objects are stored for games, there are a couple ways, but mostly it is just coordinate pairs or vector pairs.  Either way gives you the same thing, it is just mathematically easier to rotate a set of vectors than a set of coordinates, although not by much if using a cartesian (or even polar) coordinate system and setting the point of rotation at 0,0.  Although I haven't written a game in ten years or so (God I feel old), but I used to do a lot of 3D graphic work and programming of same.

[silo_xtreme]

Ok Everyone.

I just wanted to provide an update.  I've created an distributed image processing capability that can run on any machine and be controlled by a server.

All we have to do now is agree on how we should make that "standard" vector data 

[silo_xtreme]

hmm ... maybe the project has died?   

[AndrewM]

I think getting a consensus on the style and format for storing data will be a tough one to do seeing as there is a wide variety of methods that can be used.  Anyone who is capturing image data now will want to see a format similar to what they are already using, which will make a mess trying to adopt so many different styles.

My opinion would be that seeing as you created the database and will be maintaining it, that you should just set the format "standard" (there I go with that word again )

[Admin]

The AI/vision community currently just uses Google Image search.

Tell the robot to find coke, it looks it up and runs various classical AI algorithms to find a match in the environment.

Now to do the inverse is much harder . . . it sees something red . . . the algorithm can't just search the entire internet for it. Instead, it breaks the object into components, eliminating anything that isn't round, that isn't cylindrical, that isn't some particular size, etc . . .

[R.O.B. 2.0]

I think that along with focusing on the image processing, we should also focus on the how the robot would react correctly.  Say you had a red index card that was very important to you somehow and the robot picks it up and throws it away.  If it had million dollar info on it, you would not be too happy with your robot.