So, I probably committed all that code just a wee bit early. Here are a few silly things that i missed, but are now fixed:
So! r120 is what you are looking for now. that is the most bestest.
I tried to upload the binary to the google code site, but for some reason it is barfing on my password and login (not to mention it never asked me for a secondary login/password when i uploaded files before) so i think something is busted there.. anyway, until i get that figured out here is the r120 binary:
BBTouch.r120.app.zip
EDIT: Pawel fixed it, so now you can get the binary from the binaries link on the sidebar.
ben, great work!
maybe you can help me with an issue — the detect blobs functionality keeps turning itself off! grr… i’ve had this problem with previous versions of bbtouch, too, it’s not just in the latest build. sometimes it hangs in there a few minutes detecting blobs, other times it disables itself within 10-15 seconds.
also is there a way to flip the camera’s feed horizontally before processing?
thanks so much for sharing your work!
jeremy
Hey Jeremy,
the auto shutoff is to keep the blob algorithm from going off into the weeds if there is something wrong (like the lighting changes dramatically causing it to detect a squillion blobs all of a sudden) If it is going off all the time there are two possible problems:
One is that you may have your threshold set too low and the blob detector is getting lots of false hits.
the other is that I may have left in a hard coded number that expects a minimum FPS before it thinks something is wrong and you might be falling below that mark. (I will check that out :-)
Just out of curiosity what are you running on? what kind of mac and what kind of camera?
Cheers!
-b
Hey Jeremy, i just had a quick look at the code, the current hardcoded minimum FPS before BBTouch logs an error is 2.5 fps.
whenever you fall past that threshold it starts to throw out frames until it can catch up.
if the problem persists and you fall below 1 fps then it presumes that there is some problem and stops the detection (otherwise the program gets very very very sluggish since the detector is hogging the processor)
There may be some bugs in there somewhere :-) Also, if you could tell me if you are doing dark blobs or light blobs? what OS are you running etc..
I hope I can get it all running smooth for yah!
cheers!
-b
hey ben, thanks for the fast reply!
i’m running on a 2.4GHz core2 quad hackintosh (DIY, woot!), a plenty speedy machine running 10.5.2 (will update once i get nerve to use a vanilla kernel, and not a patched one, so i can use software update). the frame rate runs solid, i’m pretty sure it’s not falling down to the 2.5fps range. and i don’t seem to be getting any false hits — the image after processing is good and clean — the blob view is only showing my fingerpresses, i’m not getting any other noise. oh, and i’m using light blobs.
whaddyathink?
jeremy
it seems to be bailing whenever the sample time is greater than 1 (second, i presume). from Console:
8/19/08 11:42:29 PM BBTouch[392] sample time too long throw it out: 1.011681
i get lots of those messages in the Console log, but it only seems to be disabling on > 1.0.
i’ll have a look at the source next week… going out of town tomorrow through sunday. excited as i am to visit my friends, i can’t wait to get back to multitouching! :D
huh, yeah you got plenty of horsepower there. and it does only bail if it gets over a second. you can disable it if you like, it is in the BBINputController.m file, in the - (void)camera:(CSGCamera *)aCamera didReceiveFrame:(CSGImage *)aFrame; method. right in the middle. you can increase the values there if you like, or comment out that whole block and it will not stop if it drops below a second. tho if you are getting that kind of lag spiking then there is something going on there.
(very possibly in the BBTouch code)
the only other thing i can think of is if there is something else on the system that is taking over for more than a second. I dont know what that would be..
is your camera USB or firewire?
So does the blob tracking get sluggish at all before it bails?
in the console log, are there lots of sub 1.0 second sample times that it throws out before the ‘killer’ one? and are they all right before it in time (ie lots of times when like my time machine kicks on and my camera is at the end of that chain of drives, i will get a slew of bad sample times, each one slightly longer than the last until it bails)
hmm.. i do have a few ideas of where to poke around. i will see what i can find.
we’ll get it figured out :-)
i’m using the unibrain fire-i (firewire cam).
in the log there are lots of > 0.4 (the threshold for dumping to log), but they don’t come fast and furious before the death knell, they’re rather sporadic. no sluggishness as harbinger of bail.
next week i’ll add some interval logging to see how erratic the framerate is, and then will try to narrow down where the variability/spiking is coming from. i’ll also try messing with those thresholding numbers.
i’ll check in with you when i get back from my trip. thanks much for following up!
Sounds groovy! have a great trip!