Geometry recognition

[Maxemillian_X]

I am working on a project that has to incorporate the recognition of at least basic geometry (i.e. rectangles, squares, circles etc.) to simple shapes (example: a tree) from a picture. I'm not what really a programming wiz (otherwise I would have figured it out already). The things I want to know about this topic are:

- How heavy would coding be (for either basic geometry or simple shapes or both)?

- What the best and minimal resolution for the picture would be?

- How long could it take to set-up a prototype?

- Would such a program be able to run on a handheld device i.e. a DSi, iPhone or Andriod phone?

- Would depth perception be possible?


I thank all in advance for reviewing my questions and/or answering them.

[yaustar]

Q. How heavy would coding be (for either basic geometry or simple shapes or both)?
A. You are basically doing image recognition which is quite advanced material.

Q. Would such a program be able to run on a handheld device i.e. a DSi, iPhone or Andriod phone?
A. Yes.

Q. Would depth perception be possible?
A. Not without a reference point and/or multiple images from different angles.

[Protector one]

- How heavy would coding be (for either basic geometry or simple shapes or both)?
Most image recognition techniques I've encountered rely on a fairly advanced algorithm and large sets of sample images on which to train and test. The coding itself doesn't have to take very long. (If I didn't answer your question, please define 'heavy'.)

- What the best and minimal resolution for the picture would be?
This is dependent on your algorithm, your training data and your application. Test, evaluate and repeat!

- How long could it take to set-up a prototype?
If you know what you're doing, a day, otherwise a few days (mostly spent researching techniques, I reckon).

- Would such a program be able to run on a handheld device i.e. a DSi, iPhone or Andriod phone?
Yes, but you have to make trade-offs. (Usually speed or accuracy is sacrificed.)

- Would depth perception be possible?
Yes, but it's not trivial.

[Maxemillian_X]

Originally Posted by Protector one

- How heavy would coding be (for either basic geometry or simple shapes or both)?
Most image recognition techniques I've encountered rely on a fairly advanced algorithm and large sets of sample images on which to train and test. The coding itself doesn't have to take very long. (If I didn't answer your question, please define 'heavy'.)

With heavy, I meant if it would end up making the app big in size because of the amount of code and algorithms. But I wouldn't be wrong to think that the sample images would take up the most space in the app.

Originally Posted by Protector one

- How long could it take to set-up a prototype?
If you know what you're doing, a day, otherwise a few days (mostly spent researching techniques, I reckon).

That's nice to know.

Originally Posted by yaustar

Q. Would such a program be able to run on a handheld device i.e. a DSi, iPhone or Andriod phone?
A. Yes.

Originally Posted by Protector one

- Would such a program be able to run on a handheld device i.e. a DSi, iPhone or Andriod phone?
Yes, but you have to make trade-offs. (Usually speed or accuracy is sacrificed.)

Oke, I take it that the trade-off would be greater on DSi than on iPhone.

[Protector one]

Originally Posted by Maxemillian_X

With heavy, I meant if it would end up making the app big in size because of the amount of code and algorithms. But I wouldn't be wrong to think that the sample images would take up the most space in the app.

Well, you usually don't ship the training samples with the product, only the result of training. Say, for example, you're using SIFT, then you would only include the found SIFT-descriptors. I'm not sure how much data we're talking about then, but I'm fairly sure it's less than the training data.

As for image recognition on the DSi, there is some basic functionality included in the DSi out of the box. However, I don't know if this functionality is available to developers through an API. (Most likely not.)