You found a bug... There was a difference in the computation of the period (due to an error in order in which instance variables in the HomogeneousKernelMap object were being set). I've fixed it: https://github.com/openimaj/openimaj/commit/b584a7babe7540f76e942e1d381d4c554e67eede The bug seems to have been very low impact (e.g. caltech101 classification experiments with vlfeat and the broken openimaj version had very similar results), but it's good to have it fixed and get identical output to vl...
No known issues, but it's been years since I've played with tomcat. We've definately used the face detector in a web app in the past though. Is there nothing at all in the tomcat logs (e.g. in catalina.out [assuming that's what its still called!!))
You've sort of answered the question in the exercise - the problem is that Java doesn't auto-box /unbox arrays, so you have to do the conversion manually, which incurs a potentially significant cost. To do the conversion you can do something like this: float[] fp = new float[3]; for (int i = 0;i < 3;i++){ fp[i] = pixel[i]; }
OpenIMAJ probably isn't what you want if you just want to read files - behind the scenes it uses other libraries (including JAI as a fallback) & doesn't really offer much control over how files are read. Something like https://github.com/haraldk/TwelveMonkeys might fit your needs better if you need fine control over reading of files.
In general you'd need to learn this using an experimental set up with training and validation sets; you would then learn (for example) a distance threshold that gives you the required false acceptance rate.
I'm not all that hot on how the audio bits work, however it's possible that the tutorial has just got out of sync with the actual API. For all the tutorial chapters there is code in the github repo which should mirror what the chapters do. Can you use this as a starting point: https://github.com/openimaj/openimaj/tree/master/documentation/tutorial/tutorial-code/src/main/java/org/openimaj/docs/tutorial/fund/audio
The number of cameras returned by getCameras() is equal to the number of sets of matching points used at construction time - if you use matches from a calibration pattern across 8 images, then you'll get 8 camera objects returned (all with the relevant extrinsic parameters set, giving the positions of the camera in the scene [on the assumption that the camera moves and the calibration pattern is stationary of course]). There isn't currently any stereo calibration code - only single cameras are dealt...
I was assuming that template referred to the FImage instance reresenting the template; the above code should work as is under that assumption without the need for ant methods to be added,