Speeding up OpenCV on ARM?

edit

The easiest way to do this is to trick the build setup by doing the modifaction mentioned below in the file CMakeLists.txt.

# Other optimizations 
if(USE_O2)

    set(EXTRA_C_FLAGS_RELEASE "${EXTRA_C_FLAGS_RELEASE} -O2 -mfpu=neon")

endif()

Dont forget to turn ON the USE_O2 options while configuring your build. This modifcation only applies to earlier versions of OpenCV. The latest version of OpenCV (version 2.3.1) supports building OpenCV with NEON enabled directly via CMake

I have done lot of optimization work on OpenCV on ARM and not ARM. Main gains I got us just looking into OpenCV code and just optimizing it for my particular use. For example often there is a some sort of "if ( 8 bit color) or ( 16 bit color)" and I make millions of calls to this function. Of course I never use randomly different color depths, so I just can remove this "if". Doing this in as many places possible usually leads with huge boost from some point as compiler realize some way to optimize it after. Mostly with inlining, comptuting constants while compiling etc. All kind of magic with GCC flags usually provides result in range of 1% up to 5%, no more. Of course when -O2 at least in place. So just cut and paste parts of OpenCV you use into own code and then strip them down as much you can. Do not worry too much, usually those algorithms are just few hundred lines.

I represent a company called Uncanny Vision. Our first product UncannyCV is an OpenCV like image processing/vision library optimized for Cortex A series ARM. We use all kinds of techniques like Neon instruction, algorithm optimizations, cache optimization etc to get a good speed-up. The performance gains vary from algorithm to algorithm. Sometimes its as low as 2x and some others are as high 20x.

For good points to track, we get nearly 8x improvement over standard openCV on Cortex A8. On BeagleBoardXm with a single core Cortex A8 running at 1GHz, we can do a VGA frame in 45ms(ofcourse the performance is also a little image dependent), meaning 22 fps. On 720MHz(which is the case discussed above), this would translate to 62.5ms.

For non-commercial purposes(university development projects) we can provide the trial version of the library for free. You can come to our website and drop us an email.

I would suggest profiling with either Valgrind or Gprof to see what the primary bottle neck might be. Once you see what part is slowing execution the most, you might be able to find specific issues which might be easier to research re compile flags.

i will try to use DSP core - OpenCV DSP acceleration