Rafael Sierra's profile - activity

This operation is normally called "Perspective Transform". Perhaps you can find it as "Perspective Warp".

What you are observing seems right to me. If I remember correctly the old code had a fixed image size, if I'm not mistaken it was 640x480. The new code appears to use the maximum resolution available and that probably makes rendering slow.

When running "OpenCV Tutorial 3 - CameraControl", press the menu control (three dots), select Resolution and lower it to something like 640x480 and see if it works as it did before.

I believe that's normal LinearLayout behavior, where an object grows (because of wrap_content) and pushes other objects off the screen.

Instead, what I use when I want to overlay buttons, is a RelativeLayout.

If you can process a 360x60 image in 5ms, a 1280x800 should take 47 times that: about 230ms. I guess you had a typo and you meant around 200ms, as there might be other factors (like jpeg decompression) that affect the runtime.

You outline 5 steps and I see that there is a problem with the order of the operations: (I'm assuming you use color images as input as your are converting with CV_BGR2GRAY ).

Step number 3, cvCvtColor(), should be your first step, as steps 1 & 2 dilate/erode usually don't make much sense on non-binary images: Working on 1-channel images is way faster than working on 3-channel images.

Step 4 uses cvSmooth() and depending on the method (CV_MEDIAN for instance) this usually taxes your system: avoid it if you can.

Now, regarding optimization, a 1280x800 image takes more that 3MB to hold in memory, and whatever you do will be constrained by the memory access speed of your system. Operations are faster if all the data involved is held on the CPU cache. It would be better if you design your algorithms so you can divide your image in several horizontal strips so each strip data (aggregating the input and all intermediate images) fits on the cache, and apply all of your processing steps to each strip separately.

Also you could use a few threads to process your image in parallel. Keep in mind that you want to keep most data in the CPU cache, so you might need to increase the number of strips, so most data is kept in the cache.

Cheers.

• How is 20ms unacceptable? Assuming your input comes from a regular video camera, you'd probably getting around 30fps, giving you 10ms to spare...

Hi.

For benchmarking purposes I have ported a OpenCV test application from the PC to my Android Tegra3 device (Nexus 7), using this guide.

Because my test application uses the old C API, I need to confirm if the optimizations are actually being applied to my program. The manual in chapter 19 implicitly suggests that only the C++ functions are optimized.

In order to test, I wrote a simple test comparing cv::medianBlur() againt cvSmooth (with CV_MEDIAN) and cv::add() against cvAdd(), but found no differences in runtime.

So the questions:

1. Are the C API calls being optimized the same as the C++ API calls?

2. How can I turn the optimizations on and off? The "OpenCV for Tegra Demo App" (link to google play) does it, but is seems the sources are not available for me to check how they do it.

Thank you.