Y Shape?

This forum is used for discussing hardware, software, and technical details of the AVRcam embedded system.

Y Shape?

Postby sam0737 » Wed Jan 05, 2005 1:12 am

I am trying to understand the code of FrameMgr_findConnectedness and RLE in the assembly...
and question arises...I am not sure if I have missed anything?

If it were looking at a "Y" shape, would it gives 1 tracked obj or 2?

I said it could be 2 because...seems it would first give 2 seperated RLE at the upper half...then findConnectedness merge downwards...
at the point when two part finally merge, how could it cancel the other out and merge to give single result?

any pointers?
sam0737
 
Posts: 4
Joined: Sat Dec 11, 2004 7:27 am

Postby Guest » Wed Jan 05, 2005 8:25 am

Absolutely right! The "Y" shape is a shape that is not currently handled as a single object. The findConnectedness() routine scans from top to bottom, left to right. Thus when it first finds the top "arms" of the Y, it will allocate two different objects for it. As it moves downward, it will eventually find one object on the left that includes the top left "arm" of the Y, as well as the single base of the Y, and a second object comprised of the top right "arm" of the Y.

The simple solution here is to run one final merge operation, perhaps at the end of the frame after all of the objects have been found for the frame. This new routine would look for objects that are within a few pixels of each other, and merge their bounding boxes together to consider them as one object, marking the other as invalid. This would be relatively straight-forward. The only downside is that during the entire tracking process, the "Y" object would be occupying 2 of the tracked objects entries, when it really should only have one. So if you were trying to track lots of objects, you would be wasting some space.

It may be possible to run the merge operation after, say every 10 or 15 lines. Thus the two entries in the trackedObjectTable would only be occupied for a brief window of time until the merge routine ran. This is what I am currently doing to eliminate objects that are less than a particular width or height (to reduce noise in the image), and it seems to allow for the full frame rate still. I was originally running the routine to eliminate small objects after every line. However, this hurt the throughput, reducing the processed frames/sec down to 15 or so instead of the full 30.

I'd stay give it a stab, and let me know how it works out. I can post the updated code if you'd like (I keep meaning to get a CVS repository set up so people can grab the main source tree and do their own builds from it. I really wanted to be hosted at sourceforge, but wouldn't you know that another project called avrcam already exists? bummer....maybe savannah.....we'll see...)
Guest
 


Return to AVRcam Embedded System

Who is online

Users browsing this forum: No registered users and 15 guests

cron