Hi all,
I am very excited to be taking on my first build. I have read diligently and am learning so much as I go. I hope to have collected all the parts for my table and start building this weekend. I have reviewed the camera form and was going to go with a Phillips SPC900-NC. However, was presented with an opportunity to buy a BumBlebee from point grey research the specs can be found at this link Bumblebee Point grey . I am not sure though if this would be the best way to go? I can not find any info on the filters. Do I need an IR lens on it? If I was to use this camera I am not sure that I could use a Bandpass Filter or an IR lens because of the characteristics of this model aka the location of the lens. (Seen in the photo under link above). This is not the newest model the bumblebee 2 it is the original model from 2005. Also does anyone no if having a stereo camera is better?
no a stereo camera is not better, that just means it takes two offset images to see in 3d like human eyes, unless you wanted to do real time 3d tracking which could be interesting. just go for the spc900-nc, or if you want something easy to program get a wiimote and a bluetooth adapter, which works great on slow pc’s
The Firefly MV has the best sensitivity to IR of all the cameras from Point Grey Research, or so I’m told. I think the PDF says that as well, but I’m not certain. I was just about to purchase a Firefly MV when I discovered how well my Logitech Ultra Vision SE was tracking blobs. My Logitech camera comes with facial tracking software and is capable of wide angle high-resolution HD (960 x 720) video. But I get fast blob tracking and good resolution at 320x240. The IR filter is as easy to remove as any other camera, and it seems to work _extremely_ well with just three layers of film negative, nothing more. I suppose I’m going to have to record some video before anyone really believes me. The *best* feature by far is the Automatic RightLight® settings that automatically adjust the exposure, gain, and a bunch of other variables. It just works with so little hassle. And the native throughput of the video is fast enough for facial tracking right out of the box, so blob tracking is _much_ easier and less processor intensive. I am trying to grab the automatic settings from the driver and pass them to touchlib, bypassing the need to use config.xml. If I am successful, this would be the cheapest, fastest camera for a MT setup. The only reason I would buy a Firefly MV now would be to daisy-chain two or more together for a really large display.
Adam, what are the specs of the Logitech Ultra Vision SE? I’m not sure why you would say it could be the “fastest camera for a MT setup.” I mean, the firefly will do 60fps @ 640 x 480 through firewire. So how would a USB @ 30 fps and lower resolution be faster (better)?
First of all, the 30fps is the “guaranteed minimum average speed” of the camera and software. The camera has a digital zoom, so it supports ROI handling (same as the Firefly), and with a 1.3 mega pixel sensor at USB 2.0 speeds it can extract a 320x240 region of interest (ROI) from the default 960x720 max resolution of the camera, significantly increasing the fps. The specifications listed are bogus marketing crap generated by nervous corporate lawyers. The frame rate drops with a bunch of movement in the image space, and fingers blobs, even quite a few, will never dent that threshold. If the included software can automatically do a background subtraction and all the steps necessary to track facial gestures (like smiling or frowning) at 640x480@15~20fps, full color, with head movement, then it stands to reason it’s even better at 320x240@30~60fps in B&W, with only a few groups of pixels (blobs) changing over the image.
BTW, the filtering of the light levels appears to affect the pixel information being captured and sent to the computer. So with proper calibration, the amount of camera data drops to only what’s needed (B&W, high contrast) and more data is able to be pumped at a higher speed than advertised*.
*This is a non-standard application for the camera.
In the future I may become irritated and prejudiced if there is too much lag because I can’t directly (with code) access the camera’s internal functions or driver settings. But the automatic light adjusting software more than makes up for the lag in development time spent calibrating against ever changing external light pollution. I will run some benchmarks when I get the time, but I don’t need as many touchlib filters to configure proper blobs in the configapp as I do with other camera solutions. I still haven’t compared it directly with a Firefly, but I can’t get over how well it can automatically reach the proper image contrast for blob detection at a _very_ workable speed. I run it off an old Compaq Presario R3000 and there still isn’t much lag to be noticed. Again, if I can access the driver internals, I could really make this camera sing! *sigh* If there were only ‘N’ of me, where ‘N’ is a really large number.
The Firefly, while sending more raw data faster, just means that the computer is stuck with the task of filtering, repeatedly, the images until they produce proper blobs. The Logitech handles much of this on the camera driver side, thus increasing the amount of useful data sent that requires less computer filtering by touchlib resulting in fast blob detection and tracking. Just because the Firefly can pump out a bunch of frames is meaningless if you are spending a bunch of processor cycles filtering them. Firefly vs. Logitech Ultra Vision is only going to matter on the fastest computer available, slower computers I suspect will always favor the Logitech for what I hope are obvious reasons.
Another trick is to turn your camera 90 degrees to the left or right. The way the camera scans is lateral and the fastest movement that people seem to want to make on a touch screen is lateral, so I have found that you can track blobs better if you aren’t moving with or against the scan at high speeds.
Warning! This may (more than likely will) require manually changing code!
wow, that was a lot said. i had to take a breather and sip a beer
adam, you make some interesting correlations, some of which could be correct (i like the rotating camera concept).
i have a logitech orbit, which came out right around when that company started advertising those features. it is important to know that the tracking is all done computer side, I am almost positive of that. the extra electronics in the camera-head of the orbit is actually motors to do tracking(the camera-head rotates to follow you). it also includes a stabilizer to smooth it all out. so for any special electronics other than this? I am pretty sure not. needless to say, it’s probably a great camera
as for sensor speed, it’s locked down by it’s physical construction/size of the sensors ability to convert the photons into electricity. once digitized, if that’s a useful word, then compressed into a format for the drivers, then it passes the information through usb to your computers drivers, decompressing the information into something useful, and finally hit a program (this is where the tracking comes in). with all of this said, b/c the processing is targeted at the computers processing ability (as most usb cameras are) as well as these drivers ability to do their work, there is a huge amount of data shuffle between that initial charge of electrons through your motherboard and components, and to the software. the facial tracking is done in the software, not necessarily at the driver level (if that makes sense). couple this with the concept of mini-hd like picture size, and you have noticeable lag. you mention the tiny resolution hitting 60fps, this happens b/c the sensor is more than likely a native vga sensor (640x480) @ 30fps, thus ‘halving’ the resolution would more than likely double the throughput of the whole process, and doubling the resolution? right, more than likely it will halve the framerate of capture. there is only so much information being capture by that chip.
a firewire/ethernet camera, and may I point out pointgrey has a grasshopper camera 640x488 @ 200fps, does half the work of this whole process. by the time it hits the computer, processing is done. you could write this stream right to a disk I bet and not need any muxing around with the data. can my computer take 200fps? that amount of data is insane, but firewire-b 800 or a gigabit nic would deliver the results with ease, do I need to process @ 200fps, no; so it does not matter-- I’m pretty sure that high framerate is for postprocessed evaluation; 60+fps is a pretty good sweet spot I’d say. important to note, this specific camera is possibly very fast at higher resolutions, but that remains to be seen when more specs are released.
what about sensor size on a firewire camera? you guessed it, the concept is identical on any system used, it has a physical maximum. think of the light hitting the chip as a means to charge up the photovoltaic cells until they reach their minimum voltage needed to fire off the electron. higher resolution than the native size of the sensor requires the sensor to do twice the amount of work resulting in twice the amount of time. least this is how i seem to think of it.
another thing to consider is cmos vs ccd sensor types. cmos in theory is actually faster at converting these electrons due to it’s ability to fire off the electrons independantly from eachother, however it has poor low-light sensitivity and unfortunate noise population due to it’s physical construction.
could usb be just as good? hell yeah, if the processing was done on the camera side, the data could be sent easily with vga@60-120fps; especially since there was mention of usb3.0’s intended release.
so where does this leave us? well now I an empty beer, but also I hope I explained things a bit, as well nothing is meant in a condescending manner-- text can always skew mannerisms! and of course I could definitely be incorrect in my information
I just want to point out that I said “camera driver side” when I was referring to what was the computer using the camera drivers to actually filter the image data before sending it to the touchlib application, not that the camera itself was doing any processing of the image. I believe that the optimized code contained within the Logitech drivers and configuration software are far superior to using a “Development Kit” to manually fiddle with the Firefly drivers for $200 more money than the Logitech QuickCam Ultra Vision SE.
I was working at Apple when they invented Firewire. It originally used standard headphone jacks and audio wire. I watched the first digital “film” streamed to a computer using Firewire while working at Apple. It was called “Mail Bonding” and I saw the premiere here in San Francisco. I’m a big fan of Firewire because I’m a big fan of simplicity, but USB 2.0 can be faster as long as you’re not using a Macintosh. And it really matters whether we are talking about Firewire 400 or 800. 800 can be faster than USB 2.0, but that just really doesn’t matter when you take a much larger view of things. Like Windows XP SP1 for the Firefly! Come on! You’re not going to tell me that you’ll be plugging away on a $300 camera that won’t run on SP2 or Vista, or very well on a Mac, with little 3rd Party support in Linux, that requires a rather high technical bar of knowledge to configure, when there is a $120 camera that works on everything, even Linux (easily) and automatically adjusts itself to the lighting conditions and is not hard to use. Reduce all that down to Firewire vs. USB 2.0 and you’re left with not that big a difference.
Here, I made a quick video showing how easy the Logitech does rear-DI in normal room lighting. I’ve opened the curtains wide and let all the sunlight in and it automatically adjusts perfectly. This is not how I normally use it, because I’m focusing on FTIR at the moment. But it’s virtually indistinguishable as far as writing and testing MT applications goes. So, *shrug* it’s looking good for people who don’t have a lot of money and want a easy camera that will just work. The only setting I think I had to initially calibrate on the camera was the Brightness setting. I had to turn the Rectify and Threshold filter to zero. It just does so good you hardly need all the touchlib filters.
The specifications listed are bogus marketing crap generated by nervous corporate lawyers. The frame rate drops with a bunch of movement in the image space, and fingers blobs, even quite a few, will never dent that threshold. If the included software can automatically do a background subtraction and all the steps necessary to track facial gestures (like smiling or frowning) at 640x480@15~20fps, full color, with head movement, then it stands to reason it’s even better at 320x240@30~60fps in B&W, with only a few groups of pixels (blobs) changing over the image.
I agree that region of interest has a lot of potential to improve fps (and thus also resolution since they are often inter-related). But Adam, your thoughts are not very clear or organized and its hard for me to distill much else from your posts.
I totally disagree about 320x240 being acceptable. Or, perhaps you meant a 320x240 region of interest from a much higher resolution?
Everyone, please organize your points, or at least break up your content into paragraphs, digestible chunks, etc.
And it really matters whether we are talking about Firewire 400 or 800. 800 can be faster than USB 2.0, but that just really doesn’t matter when you take a much larger view of things. Like Windows XP SP1 for the Firefly! Come on! You’re not going to tell me that you’ll be plugging away on a $300 camera that won’t run on SP2 or Vista, or very well on a Mac, with little 3rd Party support in Linux, that requires a rather high technical bar of knowledge to configure, when there is a $120 camera that works on everything, even Linux (easily) and automatically adjusts itself to the lighting conditions and is not hard to use. Reduce all that down to Firewire vs. USB 2.0 and you’re left with not that big a difference.
