NIVision EllipseMatch Problems

[bronxbomber92]

There are several fields in EllipseMatch struct that seems less than useful (though, they shouldn't be).

First are the majorRadius and minorRadius fields. They are almost useless because no information is given on which axis they lie on. Is there someway to tell what axis each lie on (either accounting for rotation of ellipse or not)? If the NIVision library provided the axis that each were on it would be very easy to tell if ellipse matches were concentric.

My other problems pertain to the score field. Is a low score or high score good? If a high score is good, how large can this value be? Also, in the example code given for this year they're calculating their own score value, but it's not obviously clear what exactly they're doing means. Can anyone shed some light on this?

Thanks!

[Greg McKaskle]

The ellipse descriptor from IMAQ contains the rotation of the ellipse. You'll have to reference the documentation or experiment to determine where zero is and which way positive rotates.

The ellipse score ranges form 0 to 1000 with higher meaning better. In fact, the score starts at 1000 and points are deducted each time a pixel doesn't fall on the mathematical ellipse. Note that this means that the same quality shape scaled up has more pixels, and even though it is really the same, it will score lower because it has more pixels to subtract for. For this reason, the sample code computes a normalized score that corrects for size and will remain more constant as the size the image up and down. The sample code will also scale the centers and sizes to be a ratio of the image size so that it is not relying on a particular camera resolution.

By the way, are you reading through the C, Java, or LV source? They were done similarly, but the comments and style may differ. You may find it useful to look at the algorithm in the different languages and compare.

Greg McKaskle