Face detection and extraction predominant hue ranges

1- Detect Face using HaarClassifiers (keep the biggest hit in the image)
2- Create an ellipse surrounding the rectangle with the detected face
3- Create a binary mask: value 1 inside ellipse, value 0 outside ellipse
4- Create and calculate an Histogram using the binary mask and the image with the region of interest (ROI) established in the rectangle area (result of face detection).
5- Threshold the Histogram in order to reduce the noise
6- Normalize the Histogram


The Histogram shows the predominant HUE ranges. The same process can be done with SATURATION and HUE,so we obtain the predominant HSV ranges and we can use them , for example, to apply color segmentation algorithms.

This process can be also done using RGB color representation.

Despite of the diferent light conditions and skin colors, the predominant hue ranges are always near reds, so we could use a color segmentation algorithm in order to make a faster face detection.

Marcadores en ARTookit

ARToolkit nos brinda la posibilidad de crear nuestros propios marcadores (fiducials), aqui detallamos el proceso:

1) Se crean los marcadores que uds desean, obviamente recordando que tienen que estar dentro del cuadrado negro habitual.
Un detalle al momento de crear un marcador, es tener en cuenta que no sea ni vertical ni horizontalmente simetrico, ya que sino les pasa que ARToolkit no sabe reconocer que lado es arriba, bajo etc de la figura.
Si buscan en internet pueden encontrar el siguiente sitio: http://www.roarmot.co.nz/ar/ que ofrece la posibilidad de generar la imagen del marcador, aunque no hemos logrado utilizarlo con exito por lo que optamos por crear nuestras imagenes manualmente.

2) Una vez que tienen los marcadores tienen que imprimirlos. Una vez impresos hay que lograr generar un .patt para cada uno de ellos (son archivos enteramente numericos). ARToolkit usa esos .patt para hacer el reconcimiento real.
Tenemos dos posibles caminos, usar el mk_patt que viene en ARToolkit o usar este otro link que se puede encontrar publicado en internet (pero fue testeado por nosotros): http://flash.tarotaro.org/blog/2008/12/14/artoolkit-marker-generator-online-released/.
Tomando ambos caminos la logica es la misma, se pone el marcador impreso delante de la pantalla hasta que el borde superior izquierdo tome color rojo y el borde opuesto color verde. Detalles de este proceso estan disponibles en este link:
http://www.artoolworks.com/support/library/Creating_and_training_new_ARToolKit_markers.

 

Un ultimo detalle sobre este proceso, utilizando el mk_patt en Windows no tuvimos problemas, pero en Linux, debemos asegurarnos de exportar los parametros tal cual lo hacemos para ejecutar la aplicacion. En el extracto de codigo que se muestra a continuacion ejemplificamos el cambio que tuvimos que hacer en nuestro caso:

#  if defined(AR_INPUT_GSTREAMER)
//char *vconf = "videotestsrc";
char *vconf = "v4l2src device=/dev/video0 use-fixed-fps=false ! ffmpegcolorspace ! capsfilter caps=video/x-raw-rgb,bpp=24 ! identity name=artoolkit ! fakesink";

3)Si se quiere lograr un ejemplo que maneje detecciones multiples (similar al ejemplo Multitest), se deben disponer todas las imagenes a reconocer en una hoja e imprimirlas.

4)Ahora que todos los patrones fueron reconocidos, tenemos que lograr que ARToolkit los reconzca como a la aplicacion "multitest". Entonces debemos pasar como parametro un archivo .dat  con la cantidad de marcadores, tamaños y posiciones relativas.

Nota: Nos hemos enfrentado a un problema al generar archivos .dat en Windows y luego querer utilizarlos en Linux debido a la diferencia entre los saltos de linea entre ambos sistemas. Es por eso que si se genera un .dat en Windows, el ARTookit puede no procesarlo al utilizarlo en Linux.


Por ultimo, la logica que se puede usar para elegir los valores a asingar en las distancias del archivo .dat, es la de simplemente tomar el ejemplo del multitest como base de medicion (si lo miden con una regla, los valores del .dat de este ejemplo equivalena a centimetros). Con esas proporciones se llega a un muy buen resultado.
O sea, si nuestros fiducials miden 5.6 x 5.6, debemos especificar 56 en el tamaño correspondiente del .dat.
Los detalles de cada campo y para tener una idea mas general de esta ultima parte del manejo se encuentran disponibles aqui: http://www.hitl.washington.edu/artoolkit/documentation/tutorialmulti.htm

Problematica en desarrollo de prototipos con ARToolkit

ARtoolkit parece ser la mejor herramienta para hacer el trabajo que queremos, esta desarrollada especialmente para reconocer figuras de manera sencilla, por lo tanto, parece lo mejor incluir esas figuras en nuestro prototipo de "mouse virtual" y que nuestro programa las interprete como quiera (flecha a la izq, derecha, arriba , abajo y click).

Viendo que Artoolkit es la herramienta que mas se estaría ajustando empezamos a hacer pruebas. Obtuvimos un resultado muy bueno bajo windows y a su vez un resultado muy malo en linux. En windows la performance del ejemplo "multiTest" (ejemplo contenido en el SDK estandar de ARToolkit) es muy buena y alentadora para poder ejecutarla en el hardware de la XO, la carga de la CPU ronda entre 10 -  20%. Por otro lado en linux la situación es muy diferente, la carga de la CPU al ejecutar "multiTest" es de 100%.

Ya que se usa el mismo hardware en ambas pruebas decidimos comenzar a investigar cual puede ser la causante del problema.

1- Driver de la tarjeta de video. En windows y en linux el driver de video no es el mismo evidentemente, quizás esta pueda ser una causante del problema. Lamentablemente esta hipótesis no tiene demasiada solución ya que se esta usando el driver del fabricante (nvidia) y siempre suele ser el mas performante por motivos obvios. Lo que se nos ocurre para mitigar este riesgo es probar en linux pero usando otro hardware que en particular tenga una tarjeta de video de otro fabricante (ATI sería lo mejor, ya que la

especificación del driver de video es libre y existen implementaciones de código abierto muy buenas).

2- Implementación de opengl. Investigando acerca del problema de la carga de CPU con Artoolkit nos encontramos con que alguien tenia el mismo problema. Resulta que esta persona armo unos ejemplo usando Artoolkit. Lo probo en windows usando glut32 (implementación oficial del utility kit para desarrollar en opengl) y freeglut (implementación libre de opengl que estamos usando en linux actualmente). El resultado era que usando glut32 la aplicación tenia un carga de CPU muy baja y usando freeglut una

carga muy alta. Vista esta situación decidimos compilar ArtoolKit en windows 2 veces, una usando glut32 (que es la distribución de ArtoolKIT estándar que ya probamos en nuestras maquinas) y otra usando freeglut. Una vez compilados los ejemplos corrimos "multiTest" y para nuestro asombro no hubo diferencia, funcionaba igual de bien con glut32 que con freeglut. Aquí nos quedo la interrogante de que podría estar pasando...

a- Las operaciones que hacen funcionar mal el ejemplo en freeglut no son usadas en multiTest, en este caso a nosotros no nos importa, porque lo que queremos desarrollar se basa en multiTest y no en el ejemplo encontrado en la web.

b- La implementación de las operaciones que usa multiTest en la implementación freeglut en windows es diferente a la implementación en linux, y freeglut es realmente nuestro problema.

c - El problema no es la implementación de glut y todavía no descubrimos cual es.

d - Otra posibilidad es que el codec de video que estamos usando en linux no esta funcionado bien. Al configurar Artoolkit en linux nos da la opción de usar GSstreamer o de usar Video4Linux. Este último no lo hemos podido hacer funcionar aun y quizás funcione mejor que Gstreamer,  no lo sabemos aun, aunque en todos lados recomiendan más usar Gstreamer.

Luego de probar todas las posibilidades nos dimos cuenta de que el problema no se correspondía con ninguna de estas hipótesis, sino que la función que devuelve los frames capturados por la cámara funciona mal bajo linux y se estaban procesando alrededor de 170 frames por segundo, por eso es que la performance

era tan mala. Para resolverlo basto con agregar un sleep hasta encontrar el punto en el que la aplicación procesa 10 fps aprox.

Decidimos usar Artoolkit para hacer el seguimiento de los marcadores y una vez que un marcador no es detectado entonces se convierte la imagen a un formato manejable por OpenCV y se aplica un algoritmo sobre el marcador no reconocido para poder determinar si hay un objeto conocido (llámese mano) tapando el marcador o si no hay nada. En caso de que se detecte una mano tapando el marcador se toma como que el usuario esta presionando el marcador, de lo contrario se ignora.

En este momento estamos trabajando en el algoritmo usando OpenCV para determinar si hay una mano sobre el marcador o no. Creeemos que usar colores brillantes es una buena idea y es performante, difícilmente se confundan ya que toda nuestra escena es una hoja blanca con marcadores en blanco y negro.

Muchos temas interesantes a resolver...