Ubuntu + Opencv = Slow ...

[jpiat]

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.

[John F. Davis]

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

[Dingo_aus]

I'm using C not Python and as fast as expected

--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

[djlewis]

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
-----

[Måns Rullgård]

djlewis <djl...@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.

--
Måns Rullgård
ma...@mansr.com

[jpiat]

What toolchain do you use to cross-compile program for ubuntu on
beagleboard ? Do you use the onboard compiler ?

On 4 avr, 01:16, Måns Rullgård <m...@mansr.com> wrote:

> m...@mansr.com

[jpiat]

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 ....

On 4 avr, 10:54, jpiat <piat.jonat...@gmail.com> wrote:
> What toolchain do you use to cross-compile program for ubuntu on
> beagleboard ? Do you use the onboard compiler ?
>
> On 4 avr, 01:16, Måns Rullgård <m...@mansr.com> wrote:
>
>
>
> > djlewis <djle...@tcworks.net> writes:

> > > I have testedopenCVon 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.  OpenCVis written

[Vladimir Pantelic]

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?

>
> On 4 avr, 10:54, jpiat<piat.jonat...@gmail.com> wrote:
>> What toolchain do you use to cross-compile program for ubuntu on
>> beagleboard ? Do you use the onboard compiler ?
>>

>> On 4 avr, 01:16, M�ns Rullg�rd<m...@mansr.com> wrote:
>>
>>
>>
>> > djlewis<djle...@tcworks.net> writes:
>> > > I have testedopenCVon 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. OpenCVis 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.
>>
>> > --

>> > M�ns Rullg�rd
>> > m...@mansr.com
>

[jpiat]

ball tracking by doing capture, RGB to HSV conversion then
threshold , smooth and HoughCircles.

[Vladimir Pantelic]

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?

[Andruk Tatum]

My guess would be the HoughCircles, as the parameter space searched in Hough transforms can be quite large.

Good luck.

-- @

[jpiat]

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.

> > beagleboard...@googlegroups.com<beagleboard%2Bunsubscribe@googlegr oups.com>