java.lang.IllegalStateException this should only be called when the cursor is valid

You might want to call stopManagingCursor in onResume()

The package glossaries seems to be state of the art. I set it up as the following on my Windows machine with TeXnicCenter:

% in the preamble
\usepackage{glossaries}
\makeglossaries

Define a new output profile: Copy one of the existing profiles (e.g. "LaTeX > PDF") and add the following entries to the postprocessing tab:

• makeglossaries #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".glg -o "%bm".gls "%bm".glo
• makeacronyms #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".alg -o "%bm".acr "%bm".acn
• pdflatex #2
  copy from (La)Tex tab
• makeglossaries #2
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".glg -o "%bm".gls "%bm".glo
• makeacronyms #1
  Application: {full path to}/makeindex.exe
  Arguments: -s "%bm".ist -t "%bm".alg -o "%bm".acr "%bm".acn
• pdflatex #3
  copy from (La)Tex tab

This procedure avoids to use of makeglossaries.exe which requires that you have Perl installed. The iterative calls are described in the Latex Wikibook and it seems to work well this way. You can import my output profile: latex-pdf-glossary+acronym.tco

Mind, that if you use the hyperref package, to load this before the glossaries package. This way glossary entries will be automatically linked in the PDF output.

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.

Last updates were in January this year, so quite up-to-date actually.

Oh, btw, guys why can't I find you when I search for "AR Android". I mean seriously, take care of your website keywords

Hopefully this can boost my project a little.Will see.

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.

export ANDROID_NDK=/cygdrive/d/android-ndk-windows
export NDK_TMPDIR=$ANDROID_NDK/../ndk-tmp

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

But there is more. Qualcomms QCAR augmented reality SDK is well up to date and working incredibly good. Though, there is a huge problem: If you want to track images with natural features you'd need to first upload your images, let them go through Qualcomms "Image Target System", download some binary file (which has most likely interest points from the image in it) and then compile everything into the Android application. I mean, come on! How useful is that!? So I cannot use QCAR either, because I want to dynamically load interest points and other information during runtime.

What is left? I guess I need to try it on my own. OpenCV has all the functionality I need (There is this Android-optimized version which compiles nicely with the NDK). I "just" need to use it. JavaCV is Java-based wrapper to the OpenCV API, it is not commented at all but hopefully it will be of any use for me.

If there is someone out there with (helping) suggestions, please drop me a line in the comments.

Similar to PTAM Wagner et. al also use a separated detection and tracking system. The detection system tries to find known targets in the currently available camera image using a modified SIFT algorithm. Instead of calculating the kind of expensive Differences of Gaussian (DoG) they use a FAST corner detection over multiple scales. Memory consumption is then reduced by using only 36-dimensional features instead of the original 128-dimensions of SIFT. Found descriptors are matched with entries from multiple spill trees, which is a similar data structure like the k-d-tree used in the original SIFT.

-- unfinished --

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.

$\sum\limits_{i,j\in W}(Image_1(i,j) - Image_2(x+i, y+j))^2$

There are some variations of SSD. Like the Zero-mean Sum of Squared Differences (ZSSD):

$\sum\limits_{i,j\in W}(I_1(i,j) - \overline{I}_1(i,j) - I_2(x+i, y+j) + \overline{I}_2(x+i, y+j) )^2$

See also:

• http://siddhantahuja.wordpress.com/2010/04/11/correlation-based-similarity-measures-summary

We're going to perform computations for every pixel of the target bitmap. floating-point operations are very slow on ARMv5, and not too bad on ARMv7 with the exception of trigonometric functions. For better performance on all platforms, we're going to use fixed-point arithmetic and all kinds of tricks

I stumbled upon this one or two times before. So it really seems like this is an issue needed to be addressed, since I want to do lots of heavy pixel-by-pixel computation stuff (a.k.a. image processing). Maybe there is a better way to do this: instead of translating everything from floating-point to fixed-point operations or even finding and implementing "all kind of tricks", I could do everything with OpenGL. Android 1.6 supports OpenGL ES 1.1 and from Android 2.0 and up OpenGL ES 2.0 is supported. Such OpenGL-operation are probably performed on the same CPU, but I assume if OpenGL is doing some floating-to-fixed-point translation this is more effective than I could do.