I'm kind of thrilled right now.
I just updated JavaCV to the latest version (2011-07-05) which includes OpenCV 2.3.0 and some precompiled code for Android devices with an FPU (armeabi-v7a). Just by replacing JavaCV I gained an enormously computation boost. Well, of course I knew that an FPU is better for heavy number crunching than a CPU. Nevertheless I'm surprised that this makes such a big difference even in the tiny smartphone (HTC Desire HD).
My current implementation detects Shi-Thomasi corners and then tries to track them in following video frames. Where yesterday (without "FPU-code") my detector needed around 3 to 4 seconds to detect about 50 corners (even though it didn't much matter if I detected 50 or let's say 250) now it needs about 170 milliseconds and very often even less. My tracker needed about 1000 milliseconds to find known corners in new frames -- now 20 milliseconds. The detector is about 18 times faster.
I know, I know ... this is kind of supposed to be like that 😉 . But I'm just surprised to see this working. As result from that I will just target on devices with an FPU. I'm not quite sure yet if a certain Android version requires an FPU, so could just say e.g. from 2.3.0 and up my program will work or if I need to actually check this during runtime.
Just another desperate try to get something connected with OpenCV compiled under Windows.
AndroidExperimental looked promising at the beginning. But of course everything just works on Linux without problems.
The step where
get_ndk_toolchain_linux.sh is referenced won't work on Windows and actually you don't need to do everything in there if you already have the NDK. So, assuming the NDK is already installed, just run the last portion of the script. The following is what worked for me with Cygwin.
ANDROID_NDK was defined in the Windows environment variables and therefore had backslashes in it, somehow this wouldn't want to work, so I overwrite it.
NDK_TMPDIR is used in the shell script and with Cygwin it has no write access to this folder. Choosing another folder worked.
$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --platform=android-5 --install-dir=$ANDROID_NDK/android-toolchain --system=windows
ln -fs $ANDROID_NDK/android-toolchain /opt/android-toolchain
So, this prep-work is done. Unfortunately compiling the
hello-cmake sample didn't work and ends with:
-- Check for working C compiler: /cygdrive/d/android-ndk-windows/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -- broken
CMake Error at /usr/share/cmake-2.8.4/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "/cygdrive/d/android-ndk-windows/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc" is not able to compile a simple test program.
I'm not sure why this is happening. Maybe it's because the path to the project has spaces in it. Or what ever.
Trying something else for now.
JavaCV is a wrapper for a couple of libraries, including OpenCV. They also provide a pre-compiled OpenCV for Android. Looks promising. Will take a look at it. Wonder if this slows down the application somehow, because they are some more method calls because of the wrapper stuff I guess. But if it speeds up the development process I could live with that for now.
At github I found an optimized version of OpenCV for Android. Different to the original Android version this one can be compiled with the Android NDK (except with those creepy work-arounds described at opencv/AndroidTrunk).
Unfortunately, the build process took like hours: because some variables needed by the linker aren't set on Windows (but obviously on Linux). So after looots of trying it worked finally.