Hi,
i'am trying to run opencv with the python binding on a beagleboard C3
running Ubuntu Lucid. Everything works fine, but very slow. With
python script only capturing frames, i only get 10 frame/sec. When
running some ball detection i get 4 frame/sec. Do you have any idea
why it is so slow ... I will give a try at angstrom to see if the
problem comes from the OS.
On a C3 board with Ubuntu 9.04 and OpenCV 1.0, I ended up using SDL for the image capture and then extracting intensity values to an OpenCV matrix for image processing. This led to a student’s successful walking robot processing 10 fps from a Logitech 9000.
To begin to identify your problem, I suggest you try open-source luvcview and see how many frames per second it gives.
John
jpiat wrote:
I’m using C not Python and as fast as expected
I have tested openCV on various Angstrom versions as have others.
It is a slug with video capture and any image processing, period.
On the bright side I see there is a GSoC proposal for a faster
openCV 
I have not tried the latest Angstrom version (2.0 i believe).
I dnload sources and build my own native.
Don -- djlewis
djlewis <djlewis@tcworks.net> writes:
I have tested openCV on various Angstrom versions as have others.
It is a slug with video capture and any image processing, period.
On the bright side I see there is a GSoC proposal for a faster
openCV
Whoever takes that takes has my deepest sympathies. OpenCV is written
in monstrous C++ sprinkled with x86 inline asm. Adding ARM
optimisations is going to be a bitch. The inline asm simply isn't
expressive enough to write efficient NEON code.
What toolchain do you use to cross-compile program for ubuntu on
beagleboard ? Do you use the onboard compiler ?
I have tried running the same programm coded in C, but the results are
all the same. I'am able to achieve 4FPS at 640x480 ....
jpiat wrote:
I have tried running the same programm coded in C, but the results are
all the same. I'am able to achieve 4FPS at 640x480 ....
doing what?
ball tracking by doing capture, RGB to HSV conversion then
threshold , smooth and HoughCircles.
jpiat wrote:
ball tracking by doing capture, RGB to HSV conversion then
threshold , smooth and HoughCircles.
and what does profiling tell you about where the bottleneck is?
My guess would be the HoughCircles, as the parameter space searched in Hough transforms can be quite large.
Good luck.
– @
HoughCircles can take some time, but it appear that with better
binarized image it become slower than thresholding. I now use adaptive
threshold on the gray scale image, and then some erode and i get
better results. The drawback is that now i spend more time on
threshold + erode than HoughCircle. I can now get 4 frames/s with
320x240 frames, and 2 frames/s with 640x480 frames. It seems that i
need les erode steps with 640x480 frames. I guess that recoding some
parts with NEON intrinsics coud help.