HeelX, this is fascinating. Any chance you could explain in simple terms (so that an idiot - say, me - would understand it) what your code does to detect the face?

Thanks

In this setup, I sample at each graph node in the source image (upper left image) the local textures at specific points of the face - e.g. the nosetip, the eye corners, the cheeks, the eyebrows, the iris, etc. The facegraph has 52 nodes, so I have 52 local texture models of parts of the womans' face. The texture models are not trivial as they code arbitrary textures by complex-valued waves... fancy stuff!

To find the face in a new image, I move the center of the graph pixelwise over the destination image.

For each pixel I and compare at all 52 graphnodes the node-textures from the source image with the texture at the position of the current graph node in the new image. This comparison is powered by a mathematically function, that returns a number, which represents the similarity of the texture patch in the new image with the texture model in the graph node. The higher the number, the more similar is the texture patch with the texture model in the node.

I sum all similarities up and divided them through 52. This is the value I write in a so called similarity map - the pixel with the highest value in this map is the position in the image where a face seems to be most likely.

There are 5 similarity maps shown in which I test 5 different similarity functions. They have all pros and cons regarding quality, speed and accuracy. The Abs-Similarity function for example is fast and accurate for a very first raw guess.

Finding the face involves more steps which I will implement over Christmas and New Year's Eve, like scaling/rotating the graph and different search steps with different similarity functions and single node-positioning. For GENERAL face detection, a special so called Maximum Likelihood Estimator is trained over a bunch of faces to create a generic and independent model of a human face.

Thank you! Explanation is much appreciated

Really interesting topic, and with such a clear use as well. I seem to remember that you're doing that as your Master's thesis, is that right?

Sort of. I have chosen a certain state of the art method and what I do is changing things and/or implementing new stuff. At the moment I am in the midst of re-creating the baseline technique with Java and OpenCV. Later I'll add my stuff and then I evaluate the methods against data. Then I compare the numbers and if my numbers are better, my proposed changes have a fair chance of being an improvement over the original algorithm. If not, then not.

First basic version of the scan-scale-and-rotate matching algorithm implemented.

(image removed)

Shown are the source image from which the model is taken and the search image with given angle = 7° and scale = 1.2; the search resulted an angle of 5° and a scale of 1.8; below the images are the similarity map (best positions), the scale map and the angle map shown. Don't care about the consumed time. It is not a realtime technique and is scheduled differently in the resulting, surrounding algorthm in a coarse-to-fine manner.

Since jcl is taking very long for the android conversion (in case he is even working on it) I took matters into my own hand and wrote my own OpenGl ES 2.0 Renderer and MDL5 mesh loader. Wasn't nearly has hard as I had thought.



So I'm also stepping away from the 3DGS after over 10 years of usage.. I had a great time with you all!

Good,
waiting for an engine that seems to be in the clouds will
just slow you down.

If you want to develop for Android better go the direct (and independent) way.

Last weekend I participated in the global game jam at InnoGames in Hamburg, we we were a team of six people who never met before and while I miss fun gameplay, we are still quite proud of our result: http://slindev.com/glow/ (should be played with sounds)

Nice concept! Though I never reached a flower. It's too dark.

Slin, it crashed for me: