Monday, May 4, 2009

the life of a blob

admittedly, i've spent the past five minutes browsing facebook instead of writing in this little blog box.

i'm a little disappointed that the rest of the team isn't really keeping up on the blog front. we've made a lot of progress in the past month, and while it doesn't always seem like there's something to say, there probably is.

last night i took a scalpel to eddie's blob detection code (which works!) and turned it into an object instead of a single program. my motivation was to make the blob server use the blob detection object in conjunction with a blob stitching object (yet to be written) to create the data it needs to send out to clients.

the surgery went well, and i made sure that the blob detection still worked when i was done with it, however it was still pretty ugly, so we spent an hour or so today going through and tidying things up, modularizing what needed to be modularized, and then we got interrupted by my desire for food and eddie's desire to walk home before it started raining.

now, we have blob detection, and we have more than a few properly filtered cameras, so i've started to investigate blob stitching more thoroughly.

with just one camera, and a simple test, my entire conception of what a blob is was thrown out the window.

as it turns out, if what would otherwise be considered a blob happens to be touching the border of the camera, the cvBlob library say "ohai, i can haz solid borders.. i aint no blabs", which, in english means, white pixel splotches in an image are only blobs if they don't touch the edge of the image.

the inherent problem is that if a single blob is touching the border of two cameras and is not fully contained by either, then it never gets detected.

so, about half of my worldview is completely fucked right now.. this means one of two things. either we go into the cvBlob library and make some changes (extremely undesirable), or we ensure that each camera has an overlap of at least one blob (mechanically difficult, poses philosophical issues).

i'm going to investigate the second option here briefly. when we first started the project, jose mentioned the desire to have a swiping type function where the user would use the side of his hand (pretend like you're playing rock paper scissors, make a rock with your right hand, and put it down on the table. now unclench your fist and straighten your hand.. then swipe your hand to the left.)

if this sort of blob behavior is to be expected or accepted, then any notion of blob size is now completely out the window, making the second option ineffective.

so now it's looking like the time to put on my white hat and get to hacking.. i wonder what licensing model they're using...

No comments:

Post a Comment

Followers