Performance seems to be very dependent on the camera hardware, and the capture resolution. My best camera gets about 5 frames per second in Arch Linux, at 320x240, which is pretty hopeless. With the stock OpenCV package available via apt for the Squeeze distribution, I'm not able to control resolution so far, and get less than 1fps at 640x480.
So, I think it doesn't make much sense to compare someone else's figures with your own. Much better if you're able to compare identical hardware and test scripts side by side with the 2 OSs.
I've been playing a bit with the latest official Raspbian Wheezy image.
It's early days, but the stock python-opencv package is at least as performant as the Arch Linux one, which is a relief as I'd been thinking I might need to cross-compile a more recent build of the OpenCV source on Debian Squeeze. Current very rough benchmarks suggest about 2-3 FPS doing colour-based blob detection at 320x240 on a crappy camera.
I've noticed that Motion is able to achieve about 6-7 FPS at around 50% of CPU, so there's probably a fair bit of optimization possible.
The one thing that really causes me problems in OpenCV, and that I've not yet found a solution for, is that the camera capture stuff seems to maintain a buffer of several frames, so it's really hard to get realtime detection - it's usually lagging a second or two behind the action.
Opencv facedetect Debian / Raspbian compare.
Ive been using a logitech C200 usb camera, no external power. installed openCV (did the make overnight) Using ./facedetect in the build/bin/folder . detect time for debian wheezy was ~30 seconds , for Rasbpian wheezy is ~6.5 secs,never under 6 . when i used the raspbian pisces R3 this was slightly faster at around 6 sec average, may be the background content / ambient light.
Still a long way from what a camera could do which this chip was partly designed for so im keeping my fingers crossed for the direct port camera. Maybee just my cheap C200 ?
It'll be slower than you're expecting because OpenCV is running entirely on the low-power CPU, and making no use of the powerful GPU. And (unless something like OpenCL gets released for Pi) there's no way you can change that
(unless something like OpenCL gets released for Pi) there's no way you can change that
well , just had a brownout at 00:39,
So how do we get open CL, because if thats what Rpi needs to be as good as a sony camera then BCM can deliver, I know its all about licensing like dolby but if there is a way to optomize HW for the better good of all ( this is a dev board after all) then even the licence holders may bend for education ?
There was talk of the official camera module using some of the GPU acceleration - I think there's a good chance that will have signifcantly improved perf for some of the capture and immediate postprocessing steps. It seems doubtful right now that it will be able to use GPU for subsequent matrix-heavy image processing though
Have any of you played with the newest python openCV bindings available by apt-get?
A really basic example of just opening up a window and displaying an image fails w/o error (no window). Exact code works fine on my laptop.
Have any of you tried something similar? I've seen posts claiming success http://mitchtech.net/raspberry-pi-opencv/ when manually compiling. Before I go down that route, I was wondering if anyone else has had any experiences?