UNIVERSIDAD POLITECNICA DE MADRID

Escuela Tecnica Superior De Ingenierıa DeSistemas Informaticos

Facetracking for Headtracking

Grado en Ingenierıa de Computadores

Plan 2014 - curso 2018/19

Madrid, Junio DE 2019

Autor: Leonardo Niels PardiTutor: Angel Arroyo Castillo

Indice

Indice de figuras 3

1. Resumen 5

2. Abstract 6

3. Introduccion 73.1. La problematica, el Headtracking . . . . . . . . . . . . . . . . 83.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. Especificaciones 124.1. Dispositivo de entrada . . . . . . . . . . . . . . . . . . . . . . 124.2. Escenario de captura . . . . . . . . . . . . . . . . . . . . . . . 124.3. Entorno de ejecucion . . . . . . . . . . . . . . . . . . . . . . . 134.4. Prestaciones y capacidades . . . . . . . . . . . . . . . . . . . . 14

5. Estado del arte y soluciones disponibles 155.1. Headtrackers . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2. Facetracker disponible . . . . . . . . . . . . . . . . . . . . . . 165.3. Librerıas y frameworks disponibles . . . . . . . . . . . . . . . 17

6. Diseno e implementacion del facetracker 196.1. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2. Aproximacion sencilla con Haarcascades . . . . . . . . . . . . 19

6.2.1. El sistema de deteccion . . . . . . . . . . . . . . . . . . 196.2.2. Integracion del detector con OpenCV . . . . . . . . . . 226.2.3. Correccion de sombras . . . . . . . . . . . . . . . . . . 236.2.4. Inicio del programa . . . . . . . . . . . . . . . . . . . . 246.2.5. Bucle principal . . . . . . . . . . . . . . . . . . . . . . 266.2.6. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3. Facetracker de Saragih . . . . . . . . . . . . . . . . . . . . . . 326.3.1. El dataset de entrenamiento . . . . . . . . . . . . . . . 326.3.2. Detectores de caracterısticas . . . . . . . . . . . . . . . 346.3.3. Modelos de Forma Activa . . . . . . . . . . . . . . . . 376.3.4. Restricciones geometricas . . . . . . . . . . . . . . . . 376.3.5. El bucle principal . . . . . . . . . . . . . . . . . . . . . 396.3.6. Resultados del facetracker por defecto . . . . . . . . . . 406.3.7. Modificaciones . . . . . . . . . . . . . . . . . . . . . . . 41

1

7. Comparacion y pruebas 447.1. Vıdeos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . 447.2. Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.3. Consumo de recursos . . . . . . . . . . . . . . . . . . . . . . . 457.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8. Aspectos sociales, eticos y medioambientales 568.1. Compromiso social y etico . . . . . . . . . . . . . . . . . . . . 568.2. Compromiso medioambiental . . . . . . . . . . . . . . . . . . . 57

9. Conclusion 589.1. Posibles mejoras y futuras lıneas de trabajo . . . . . . . . . . 58

9.1.1. Mejoras en el facetracker . . . . . . . . . . . . . . . . . 589.1.2. Futuras lıneas de trabajo . . . . . . . . . . . . . . . . . 59

10.Anexos 6010.1. Acronimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6010.2. Codigo fuente del simple facetracker . . . . . . . . . . . . . . . 61

11.Referencias 67

2

Indice de figuras

1. Etapas del headtracker del anteproyecto . . . . . . . . . . . . 102. Ejemplos de escenarios de captura . . . . . . . . . . . . . . . . 133. Ejes de rotacion y traslacion de referencia. . . . . . . . . . . . 144. Distintas posturas y la ubicacion de las caracterısticas . . . . . 205. Rectangulos de caracterısticas del Haar classifier . . . . . . . . 216. Mejores caracterısticas obtenidas . . . . . . . . . . . . . . . . 217. Ecualizacion del histograma . . . . . . . . . . . . . . . . . . . 238. Resultados de la correcion de sombras . . . . . . . . . . . . . . 249. Simbologıas del simple facetracker . . . . . . . . . . . . . . . . 2910. Resultados de ejemplo del simple facetracker . . . . . . . . . . 3111. Anotacion del dataset MUCT . . . . . . . . . . . . . . . . . . 3312. Modelos de parches entrenado . . . . . . . . . . . . . . . . . . 3513. Inicializacion del detector . . . . . . . . . . . . . . . . . . . . 3614. Dependencia geometrica sobre el detector . . . . . . . . . . . . 3715. Resultados del analisis de Procrustes . . . . . . . . . . . . . . 3816. Subespacio que representa el modelo de la cara . . . . . . . . . 3917. Resultados del facetracker de Saragih por defecto . . . . . . . 4118. Facetracker de Saragih personalizado . . . . . . . . . . . . . . 4319. Primer test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4620. Error siguiendo el ojo en la biblioteca . . . . . . . . . . . . . . 4621. Error siguiendo la nariz en la biblioteca . . . . . . . . . . . . . 4722. Tiempo de procesamiento del primer test . . . . . . . . . . . . 4823. Segundo test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4924. Error siguiendo el ojo con sombra . . . . . . . . . . . . . . . . 4925. Error siguiendo la nariz con sombra . . . . . . . . . . . . . . . 5026. Tiempo de procesamiento en el segundo test . . . . . . . . . . 5127. Tercer test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5228. Error siguiendo el ojo lejano . . . . . . . . . . . . . . . . . . . 5229. Error siguiendo la nariz lejana . . . . . . . . . . . . . . . . . . 5330. Tiempo de procesado en el tercer test . . . . . . . . . . . . . . 5331. Tiempo de ejecucion de las pruebas . . . . . . . . . . . . . . . 54

3

Agradecimientos

A mis padres Jose Alberto y Marcela, quienes mehan ayudado en momentos en los que el tiempo escasea.

A mi tutor Angel por apoyarme con este proyecto.

Y a mis companeros y amigos Alex, Roberto, Juany Pablo por hacerme el grado mas ameno y divertido.

4

1. Resumen

La realidad virtual y mixta es una de las areas de la tecnologıa que pro-mete cambiarnos la forma con la que interactuar con la informacion. Perotodavıa es una tecnologıa que no esta bien asentada y es poco accesible.

Por ello, este trabajo tiene como objetivo mejorar la accesibilidad de unade las manifestaciones de esta area: el headtracking. Proceso por el cualun programa obtiene la pose de la cabeza de un usuario en tiempo real.En particular, se tratara de enfocar esta funcionalidad a los simuladoresy videojuegos con el objetivo de mejorar la interaccion del jugador con elentorno virtual.

Para ello, una vez analizadas las caracterısticas del headtracker necesa-rio, el trabajo se centrara en la investigacion y desarrollo de un facetracker,componente base, que permitira capturar las caracterısticas de la cara conuna webcam para posteriormente estimar la postura del usuario.

El documento expondra la implementacion de un facetracker sencillo quese basara en el detector de objetos de Paul Viola y Michael J. Jones [16]. Queluego sera comparado con el facetracker implementado por Jason Saragih [19]para ponerlo en perspectiva con una solucion moderna. En esa comparacionse observara que el facetracker propio implementado queda lejos de alcanzarlas caracterısticas de la version de Saragih, que demostrara ser la solucionideal.

No obstante, se aprovechara la licencia de codigo abierto para modificarsu facetracker y ası enfocarlo al problema propuesto. Terminado por asentarel componente base necesario para implementar el headtracker objetivo.

5

2. Abstract

Mixed and virtual reality are one of the technologies, which aims to chan-ge the way we interact with information. Unfortunately, this technologieshaven’t already settled properly and lack of accessibility.

That’s the purpose of this document, to aim for a better accessibility inone of the areas of augmented reality: Headtracking. A process in which aprogram captures the user’s head pose in real time. Specifically, the targetsof this functionality are simulators and videogames as a way of improvingthe interaction between user and virtual environment.

To do that, once we have analyzed the features of the headtracker needed,this study will focus on the research and development of a facetracker, a basecomponent that will allow capturing face features from a webcam to estimatethe user’s head pose afterwards.

The document will show an implementation of a simple facetracker basedon the object detector from Paul Viola and Michael J. Jones [16]. Which willbe compared with Jason Saragih’s facetracker [19] to put the first solutionin perspective with a modern approach. During the evaluation, the results ofthe simple facetracker will show it’s shortage against Saragih’s version thatwill demonstrate to be the ideal solution.

However, we will take advantage from the open-source license by modif-ying J. Saragih’s facetracker to focus it on the problem introduced. Finishingby setting the base component for developing the objective headtracker.

6

3. Introduccion

En esta era de la sociedad de la informacion, uno de los fenomenos tec-nologicos que mas esta destacando en esta decada es, sin duda, la realidadvirtual y mixta. Que ha irrumpido para mostrarnos una nueva forma en laque representar la informacion a los usuarios. Ya sea sumergiendonos en unentorno virtual, enganando a nuestros sentidos con unos dispositivos hapti-cos y cascos que cubren casi la totalidad de la cabeza, o incorporando en elentorno real elementos virtuales que ayuden a visualizar objetos ficticios enel espacio fısico o viceversa.

Estos ultimos anos hemos podido ser testigos del amplio despliegue quehan tenido estas tecnologıas en varias areas. Proporcionando nuevas solu-ciones en campos como la medicina, ayudando al entrenamiento de medicosdurante operaciones y a pacientes a paliar el dolor, la educacion, recrean-do escenarios historicos para su estudio, o el comercio, ensenando modelosdigitales de productos en el espacio fısico etc.

Una de las areas que no se ha mencionado, pero que sin duda destacaentre el resto, es el ludico. Puesto que con ayuda de estos nuevos dispositivosse ha podido dar la oportunidad de elaborar una nueva forma de entreteni-miento. Una que no esta limitada por el marco de una pantalla estatica y lostradicionales perifericos que nos han acompanado por varias decadas ya. Larealidad virtual brinda una forma de vivir experiencias recreativas en entor-nos irreales como si te trasladara a ella. Por otro lado la realidad mixta hahecho posible que un mundo virtual se incorpore en el mundo real para inter-actuar con ambos. Todo ello por un precio asequible para el publico medio,o mas o menos. Sin duda, como con casi todas las novedosas tecnologıas queirrumpen en el mercado, la comercializacion de estos sistemas se ha podidoproducir por una notable accesibilidad a esta tecnologıa (abaratamiento deldesarrollo y produccion hardware y software).

No obstante, y a pesar del gran avance que ha tenido la realidad virtualy mixta en estos ultimos anos, a dıa de hoy estos dispositivos no terminanformar parte del jugador medio, como lo harıa en su lugar una videoconso-la, ordenador o smartphone (Aunque este ultimo puede ser la excepcion).Comparando las ventas de videoconsolas en el ano 2018, que asciende a los46 millones de unidades [1], con las de los dispositivos RV/RA, superior a 5millones (aun considerando las ventas destinados a usos no recreativos) [2],se deja claro que este hardware esta lejos aun de jugar el mismo papel quelas consolas en la vida cotidiana.

El principal motivo por el que la realidad virtual/mixta esta en esta si-tuacion es por el hecho de que todavıa son bastante caros. Pues el precio

7

de entrada del headset estandar ronda los 400e para aquellos que requierande un ordenador/consola (y sin contar con el precio de este), mientras quelos smartphones por otro lado tampoco salen tan baratos, pues para poderusarlo como headset se requiere un movil de altas prestaciones, manteniendoel precio por encima de los 300e. Esto sumado a la caracterıstica de quealgunos de estos equipos son aun muy aparatosos o que su despliegue re-quiere de condiciones poco favorables (como colocar sensores alrededor de lahabitacion) ralentiza su incorporacion en las casas del usuario medio.

Sin embargo existen otras alternativas para acercar esta tecnologıa a laspersonas que no cubren de estos requisitos y presupuestos excesivos paratener el ultimo hardware. Una de ellas es el smartphone que, incluso en lasterminales de bajo rendimiento, es capaz demostrar alguna funcionalidadparticular como, por ejemplo, la reproduccion de vıdeos 360o. Por otro ladoestan los casos de las videoconsolas que han hecho uso de sensores especiales(como el Kinect) para incorporar al jugador al videojuego de una formadistinta. Ambos casos haciendo uso de un hardware relativamente accesibley facil de incorporar.

3.1. La problematica, el Headtracking

Llegados a esta situacion, el problema que este proyecto propone resolver,es el de acercar este nuevo horizonte a aquellas personas (o entusiastas) quequieran probar nuevas experiencias y sacar partido de el. Estudiando la via-bilidad de implementar un headtracker accesible para su uso en videojuegosy simuladores.

El headtracking es un proceso informatico en el cual un programa iden-tifica los movimientos de la cabeza de un usuario en tiempo real, haciendouso de uno o varios sensores en el proceso. Las principales aplicaciones deesta funcionalidad pueden ser la mejora de la interaccion con el ordenador o,simplemente, el registro del movimiento identificado [3].

Su presencia abarca tanto videojuegos y simuladores, para ofrecer una ma-yor inmersion e interaccion con el entorno virtual, como seguridad y domoti-ca, donde los movimientos son registrados o utilizados para ofrecer una ma-yor accesibilidad. En los simuladores de vuelo y de conduccion en particular,cuando la perspectiva desde la que se representa el entorno es en primerapersona (visualizando la cabina del vehıculo), el Headtracking se utiliza paraimitar el movimiento de cabeza del usuario con el de la camara del entornovirtual, ayudando a percibir el area virtual con mayor facilidad.

A dıa de hoy el headtracking se lleva a cabo con la ayuda de los sensoresinfrarrojos y emisores colocados en la cabeza del usuario. Proporcionandouna precision excepcional frente a otras soluciones pero a un coste superior.

8

Afortunadamente existe otra forma de llevar a cabo la captura. Con unacamara RGB convencional, como podrıa ser la de una webcam comun, ymediante vision artificial, se puede identificar la posicion de la cabeza conel uso de tecnicas de facetracking, o con la asistencia de elementos externos(p. ej: gorras o gafas especiales que sirvan como referencia [7]) entre otrasopciones.

El facetracking es una funcion algorıtmica que trata de ubicar en el planobidimensional de una imagen la posicion de las caracterısticas faciales mascomunes de las personas. Estas pueden ser la posicion de los ojos, las pupilas,los extremos de las cejas, la sucesion de puntos que perfila la nariz o laconjuncion de todos ellos. Su uso puede aplicarse para estimar la posturade la cara (ubicacion y orientacion en el espacio tridimensional) o para laconstruccion y modelado de la cara en tres dimensiones para su registro oaplicacion en un entorno virtual.

3.2. Objetivo

Inicialmente, el objetivo definido en el anteproyecto [3], pretendıa imple-mentar una aplicacion software para escritorio, que elaborara un headtrackerpara simuladores y videojuegos, cuya estimacion de la postura se dedujerade las imagenes recogidas por la webcam. Comunicando esos datos al vi-deojuego/simulador con ayuda de el servicio gestor de trackers open-source,Opentrack [8], quien transformarıa los datos para adaptarlos al protocolo decomunicacion correspondiente al videojuego/simulador de turno, y ası, queeste aplicara el giro/traslacion de la camara del entorno virtual al ejecutadopor el usuario.

Un programa como este, tendrıa a grosso modo, el siguiente flujo: La en-trada de datos del programa serıa un stream de vıdeo de imagenes RGBcapturadas por una webcam corriente. A continuacion, un facetracker, ubi-carıa la posicion de unas caracterısticas de la cara que sirvan como referenciapara estimar la postura (p. ej: ojos y nariz). Una vez obtenidos los puntos enel plano bidimensional de la imagen, se estimarıa la posicion de la cabeza delusuario. Despues, la postura deducida se pasarıa al servicio gestor de trackersa traves de su API, quien convertirıa el formato de datos de uno a otro enfuncion del protocolo que use el videojuego o simulador destino. Por ultimo,el videojuego o simulador cambiarıa la posicion/rotacion de la camara dentrodel entorno virtual en funcion del stream de datos proveniente de Opentrack,dando como resultado final una perspectiva distinta. La figura 1 describe lasetapas mencionadas.

El desarrollo de tal programa requerirıa de la implementacion de los si-guientes componentes o modulos con las siguientes caracterısticas

9

Figura 1: Esbozo de las etapas del headtracker propuesto en el anteproyecto.

1. Facetracker, este modulo serıa la primera etapa del pipeline, quiencon la imagen obtenida por la webcam, calcularıa la ubicacion en elplano bidimensional de los elementos de la cara que se estan siguiendo(ojos, nariz, cejas...). Los elementos a seguir deberıan ser los suficientespara que el estimador pueda deducir la postura, y el mınimo para queel tiempo de procesamiento invertido en obtener tales puntos no seademasiado alto. Ademas este tracker requerirıa de una cierta robustez atodas las variables que se pueden presentar en la imagen (Origen y tonode la iluminacion, complexion facial del usuario...). Su implementacionpodrıa llevarse a cabo utilizando clasificadores de objetos (haarcascadeso redes neuronales) o detectores de caracterısticas faciales reforzado conla definicion geometrica de de la cara entre otras alternativas.

2. Estimador de postura, segunda etapa del pipeline, que usarıa lospuntos de los elementos de la cara obtenidos por el facetracker paraestimar la postura del usuario. Por postura, se hace referencia a latraslacion y rotacion en los distintos ejes. Esto Puede variar en fun-cion de las prestaciones que se deseen. Pudiendo ser una estimacion

10

en 6D (tres dimensiones de traslacion y tres dimensiones de rotacion)o una simple en 2D (solo cabeceo y guinada). La implementacion deeste modulo podrıa realizarse mediante un control multivariable o cons-truyendo un modelo 3D de la cara que se usase como referencia paraencajar las imagenes obtenidas.

3. Conexion tracker-entorno virtual, este componente se encarga deconectar el videojuego o simulador con el tracker. Implementando en elestimador de postura las comunicaciones con Opentrack a traves de suAPI. Este servicio ademas permite modificar la forma de la salida (paramanipular el comportamiento del videojuego/simulador a los cambiosde postura) y el filtrado de la entrada (Controlar hasta que angulo odesplazamiento se permite el giro o traslacion etc). Su uso es totalmenteaccesible gracias a su licencia open-source.

4. CLI/GUI, componente interfaz de usuario. Como cualquier otro pro-grama, una interfaz de usuario es necesaria para poder inicializar yconfigurar el programa. La solucion mas sencilla serıa elaborar unaCLI para manipular el programa a traves de una consola/shell. Aun-que lo ideal serıa implementar una GUI/Interfaz grafica que resultemas intuitiva y accesible para cualquier usuario. Cabe mencionar queOpentrack cuenta con su propia GUI para configurar su servicio (Trac-kers, protocolo, filtrado...). No obstante una CLI/GUI adicional serıanecesaria para configurar el facetracker y el estimador.

Cabe mencionar que la complejidad y esfuerzos necesarios para imple-mentar los dos primeros puntos son considerablemente mayores al del resto.Si bien la perspectiva inicial del proyecto consideraba viable la implementa-cion de los cuatro puntos en el perıodo del cuatrimestre, el resultado finalha demostrado que se habıa tenido una perspectiva muy optimista. Debi-do a esta situacion, el objetivo final del proyecto se ha limitado a enfocarseunicamente sobre el desarrollo de un facetracker.

Por tanto, el objetivo de este proyecto consiste en analizar los requi-sitos de un facetracker que sirva para implementar un headtracker de lascaracterısticas anteriormente descritas. Una vez aclarados estos requisitos,se procedera a averiguar si existe actualmente un facetracker de libre accesoque los cumpla y, de lo contrario, se investigara sobre como elaborar uno. Ental caso se estudiaran los posibles enfoques de desarrollo del facetracker y seimplementaran y evaluaran dos metodos distintos.

11

4. Especificaciones

Segun las caracterısticas del headtracker mencionado en el apartado 3.2.El facetracker que se esta buscando es uno que cuente con las siguientesespecificaciones:

4.1. Dispositivo de entrada

El dispositivo que se usara para capturar las imagenes sera una webcamcorriente. Generalmente, las webcams que vienen incorporadas en los portati-les o se acoplan a un ordenador de sobremesa, suelen tener una resolucionmaxima de 1280x720 pıxeles. Con una frecuencia de refresco que oscila entre10 y 30 FPS dependiendo de la resolucion a la que se esta capturando laimagen. Estas suelen ser las especificaciones estandar de una webcam comunque a dıa de hoy se puede obtener por 15/30e. La resolucion y la tasa derefresco de la camara van a ser las caracterısticas mas determinantes parael facetracker, pues la primera determinara la calidad de la imagen que seva a tratar y, por tanto, influira en el analisis y en la busqueda de la cara.La segunda caracterıstica, la tasa de refresco de los frames, sera relevante ala hora de determinar el tiempo de respuesta que tiene el facetracker sobreel videojuego o simulador. Tambien influira en la busqueda de la cara paraaquellos facetrackers que dependan o tomen como referencia el anterior frame(dado que a mayor FPS menor es la distancia de la ubicacion de la cara entreun frame y otro).

4.2. Escenario de captura

Las condiciones de uso del facetracker exigiran que la webcam este coloca-da por encima o por debajo del monitor y siempre centrado horizontalmente.Tratando de colocarlo en la posicion mas favorable para estos tres casos: quela cara este centrada a la webcam (para que esta tenga margen de despla-zamiento en caso de considerarse la captura de la traslacion de la cabeza),que el plano de la superficie de la cara en reposo, sea aproximadamente per-pendicular a la lınea formada por el centro de mira de la webcam y, porultimo, que el usuario permanezca en un rango de entre 0,5 y 3 metros dedistancia de la camara. Por otro lado se exigira tambien que las condicioneslumınicas no sean totalmente desfavorables. Lo que significa que el escritoriodebera contar con la iluminacion suficiente para que las imagenes capturadastengan un mınimo de contraste para poder distinguir los objetos presentes.Esto implica que la fuente de luz principal no debe estar colocada por detrasdel usuario en direccion al monitor. Las condiciones mas favorables serıan

12

aquellas donde la fuente de la luz esta por detras y a la misma altura del mo-nitor apuntando al usuario. No obstante se intentara que el facetracker sea losuficientemente robusto como para que estos requisitos no sean estrictamentenecesarios y, por tanto, sea operativa incluso en casos donde la camara puedano estar alineada en una posicion favorable o la fuente de luz este por encimao a un lado del usuario por ejemplo.

Figura 2: En la representacion de la izquierda aparece un escenario de cap-tura de ejemplo como ideal (usuario centrado respecto a la camara, fuentede luz frente al usuario y tras la camara etc). El de la derecha, por el contra-rio, representa un escenario de captura desfavorable donde la fuente de luzprincipal incide por un lateral y el usuario no esta alineado con la camara.

4.3. Entorno de ejecucion

Puesto que el facetracker que se pretende desarrollar es un modulo deun headtracker cuya principal caracterıstica es la accesibilidad. La platafor-ma destino seran los ordenadores de escritorio/portatiles que sean capacesde ejecutar videojuegos y simuladores de la presente decada. La plataformade referencia sera la usada para el desarrollo y prueba del tracker, un Intelcore i5 4670, procesador de gama domestica x86 64, que cuenta con cuatronucleos y cuatro hilos trabajando a una frecuencia de 3,6Ghz. El resto deespecificaciones del equipo seran irrelevantes para el ambito de la investiga-cion (uso de RAM y discos duros mınimos...). Aunque cabe mencionar quela ausencia de especificacion de GPU se debe a que los trackers a desarrollarse enfocaran principalmente en el uso de la CPU. El alcance de este proyectono contempla el estudio de la aceleracion del facetracker por GPU en casode presentarse la posibilidad. Por ultimo mencionar que el sistema operativoen el que se desarrollara la aplicacion sera una distribucion GNU/Linux porpreferencias del desarrollador. Sin embargo los trackers podrıan enfocarse acualquier sistema operativo de escritorio perfectamente.

13

4.4. Prestaciones y capacidades

Ya se ha mencionado anteriormente (seccion 3.2, componente 2) que losheadtrackers mas sofisticados pueden llegar capturar el seguimiento en hastaseis dimensiones. Esto implica que el usuario es totalmente libre de despla-zarse en el entorno virtual como desee, siempre y cuando este al alcance delsensor. Si bien estas prestaciones pueden aportar mayor inmersion e intui-tividad al sistema, en realidad lo mınimo que necesita un headtracker es elseguimiento de la cabeza en dos dimensiones: rotacion en el eje x (cabeceo ocoloquialmente conocido como el gesto del asentimiento) y rotacion en el ejey (guinada, equivalente al gesto de la negacion). Estos dos ejes de rotacionson los de facto en todos los juegos y simuladores cuya camara toma unaperspectiva en primera persona. De modo que el facetracker a implementardebera capturar un mınimo de componentes o caracterısticas de la cara quepermitan a un estimador (segundo componente del pipeline del headtracker)deducir al menos la rotacion en esos dos ejes.

Figura 3: Ejes de rotacion y traslacion de referencia.

14

5. Estado del arte y soluciones disponibles

Como se definio en el apartado 3.1, el headtracking es el proceso porel cual un programa identifica los movimientos de la cabeza de un usuarioen tiempo real. Mientras que el facetracking es la funcion algoritmica queanaliza las imagenes recogidas por una fuente de vıdeo en tiempo real, paraubicar unas caracterısticas faciales en ella. El headtracker es un componentesuperioar al facetraker. Este involucra varios subcomponentes que pueden serel capturador, el estimador y la comunicacion del la ubicacion con el entornovirtual. Un facetraker podrıa ser usado como para formar el subcompontecapturador de un headtracker, y eso es lo que se tratara de hacer en estetrabajo como ya se ha dicho. Pero antes hace falta un poco de historia sobreambos elementos.

5.1. Headtrackers

Actualmente existen varios headtrackers a disposicion de los usuarios.Con soluciones tanto comeriales como libres/open-source.

A dıa de hoy la implementacion del Headtracking en soluciones comercia-les involucra el uso de camaras infrarrojas, usadas como punto de referenciay captura, y sensores infrarrojos que se colocan en la cabeza del usuario [4].Proporcionando una precision excepcional frente a otras soluciones pero aun coste superior y de un despliegue mas complejo. Ademas estas solucio-nes suelen proporcionar su propio software que implementa todo lo necesario.Aunque existe algun hardware comercial que puede ser utilizado por softwareopen-source como Opentrack o FacetrackNoIR.

Otra alternativa para la captura del movimiento de la cabeza involucraun sistema empotrado que, acoplado a la cabeza del usuario, puede captu-rar los movimientos gracias a los acelerometros y giroscopios [5]. Para luegotransmitirlos a la aplicacion informatica alojada en el ordenador. Esta op-cion puede tambien replicarse haciendo uso de un smartphone comun quedisponga de los sensores senalados [6]. Estas alternativas caseras funcionanexclusivamente usando los programas de codigo abierto ya mencionados.

Sin embargo, las soluciones mencionadas presentan la inconveniencia derequerir de hardware adicional que en la mayorıa de los casos esta limitadaa simplemente desempenar la tarea de captura de la cabeza. Y por otro ladotenemos que ademas son invasivos, dado que necesitan que el usuario llevepuesto un equipo especial en la cabeza. De ahı la idea de querer implementarun headtracker que se base en el facetracking.

15

5.2. Facetracker disponible

Curiosamente ya existe un headtracker que ademas de gestionar variostrackers y protocolos de comunicacion con varios videojuegos. Tiene comoopcion la de utilizar un facetracker con una webcam.

FaceTrackNoIR [11] es a dıa de hoy la unica opcion de libre acceso quepermite usar como tracker una webcam que sigue las caracterısticas faciales.No obstante, FaceTrackNoIR es un sistema que engloba distintas solucionesen un solo programa. Ofreciendo varios trackers y protocolos a elegir. Lo quelo convierte en una alternativa a Opentrack. De hecho Opentrack uso comobase del codigo el presente en FaceTrackNoIR.

Su facetracker, denominado faceAPI, hace uso en el backend de una APIno comercial de SeeingMachines, una empresa que ofrece trackers y otrassoluciones relacionadas con la vision artificial para el area de la seguridadprivada. Este facetracker opera con una webcam corriente y es capaz desacar las suficientes caracterısticas faciales para que luego el estimador deFaceTrackNoIR sea capaz de captar los movimientos en 6D, al menos en lasmejores condiciones.

Desafortunadamente, y a pesar de que este tracker fuera el que llevarala iniciativa de todo el desarrollo de FaceTrackNoIR, el facetracker es ac-tualmente la solucion menos usada por los usuarios con bastante diferenciarespecto del resto de trackers que ofrece el programa. Dado que su robustezy precision queda muy lejos de lo que ofrecen las soluciones asistidas porhardware externo (emisores infrarrojos, giroscopios y acelerometros...).

Esta situacion es la consecuencia de que el facetracker se fundamentarasobre una librerıa privativa que, ya de por sı, era una version limitada delsoftware comercial que la empresa ofrecıa. Esto sumado al hecho de que laempresa dejo de dar soporte a esta librerıa a finales de la decada de 2010y, que aun ası el codigo permaneciese cerrado al publico [12], imposibilitola labor de, no solo dejar a los desarrolladores de FaceTrackNoIR intentarcorregir las carencias del facetracker, sino de siquiera dar posibilidad de seguirmanteniendolo. No teniendo otra opcion que dejar la librerıa congelada y, portanto, al facetracker en un estado pobre.

Entonces, si bien ya existe una solucion accesible que cumple, relativa-mente, con las especificaciones descritas en las seccion 4. El desgraciado finalque ha tenido este facetracker, que ha acabado totalmente abandonado y sinposibilidad de resurreccion por culpa del uso del software privativo, plantea lanecesidad de elaborar uno distinto, desde cero y cuyas bases (librerıas) seanlibres, para ası ofrecer una alternativa funcional y accesible para que cual-quier usuario lo use y para que cualquier desarrollador lo estudie, modifiquey mejore con total libertad.

16

5.3. Librerıas y frameworks disponibles

Llegados a este punto, si alguien se propone implementar un nuevo face-tracker desde cero. ¿Cuales son las herramientas disponibles para desarrollaresta area?

Pues para poder investigar sobre la implementacion de un facetracker hacefalta contar con una librerıa que disponga de varios algoritmos relacionadoscon la vision artificial con el que podamos probar y evaluar diferentes metodospara resolver el problema. Para ello se ha escogido una de las tres principaleslibrerıas de referencia.

ccv [13], es una librerıa que se presenta como la opcion cuya implemen-tacion es la mas ligera y minimalista. Aunque esta caracterıstica no lahace destacar por la cantidad de algoritmos que tiene, si lo hace porla calidad de la implementacion de estos. Su extension abarca todoslos sistemas operativos modernos que cuenten con un compilador de C,lenguaje al que esta enfocado.

dlib [14], se caracteriza principalmente por estar enfocada al machinelearning en general, y proporciona soluciones para problemas de visionartificial con metodos mas modernos. Al igual que OpenCV, dlib esuna librerıa muy completa que puede desplegarse en muchos sistemasoperativos.

OpenCV [10], esta es sin duda la librerıa mas popular del campo de lavision artificial. Vendiendose por tener mas de 2500 algoritmos optimi-zados para vision artificial y machine learnig y por su uso por grandescorporaciones como Google, Microsoft, Intel etc, que corroboran su granpotencial. Tambien cuenta con un amplio soporte en una gran varie-dad de lenguajes de programacion (Python, C++, Java, Matlab..) yde sistemas operativos (Windows, Linux, Android...) ademas de imple-mentar los algoritmos con aceleracion por hardware con instruccionesSIMD o programacion de GPUs.

De las tres librerıas presentadas, se ha decidido usar OpenCV para im-plementar el facetracker principalmente por los siguientes tres motivos:

1. Familiaridad con la suite de OpenCV. Pues ya se cuenta con experienciacon su operacion de anteriores proyectos universitarios.

2. Integracion con Python y C++. OpenCV esta implementado funda-mentalmente en C++, que es el lenguaje en el que se resuelven los

17

problemas reales. No obstante ofrece modulos precompilados para Pyt-hon que permiten hacer uso de toda su librerıa en este lenguaje. Graciasa ello, con la flexibilidad de Python a la hora de programar, se puedeutilizar este lenguaje para prototipar y probar algoritmos o compro-bar la funcionalidad de la librerıa, entre una infinidad de utilidades, encuestion de minutos. Ofreciendo una alternativa que complementa larigidez de C++ para estos casos.

3. Gran cantidad de documentacion y libros de referencia. El hecho deque OpenCV abarque tantas plataformas y ofrezca tantas herramien-tas y algoritmos lo convierte en una librerıa tan popular que cuentacon innumerables libros y otro material de referencia a parte de la do-cumentacion oficial.

18

6. Diseno e implementacion del facetracker

Los apartados de a continuacion describiran la investigacion llevada acabo para el desarrollo y estudio de dos implementaciones de un facetrackerpor dos metodos distintos.

6.1. Desarrollo

Los facetrackers implementados tienen dos enfoques distintos. Por un ladose ha atacado al problema con una solucion propia y con un enfoque simple.Por el otro lado, se ha estudiado la implementacion del facetracker de JasonSaragih y se ha manipulado para probar ajustarlo al problema que se pretenderesolver.

6.2. Aproximacion sencilla con Haarcascades

Aquı se detalla la composicion y el funcionamiento del simple facetrackerimplementado. Un sencillo programa de apenas 300 lıneas de codigo procedu-ral en C++, que realiza el seguimiento de unas caracterısticas de la cara conayuda del detector de objetos de Paul Viola y Michael J. Jones. El proyecto,que ademas incluye otras herramientas para el estudio, puede encontrarse enel repositorio GitHub [15].

Como el objetivo del facetracker consiste en obtener la ubicacion de lospuntos suficientes para cumplir con las especificaciones descritas en el apar-tado 4.4 (rotacion en dos ejes). El programa elaborado trata de capturar untotal de tres puntos de referencia: dos de los ojos y uno de la nariz. Puestoque la posicion y distancia de estos tres puntos en las distintas posturas dela cabeza deberıan proporcionar los datos necesarios para que un estimadorcalcule la rotacion en al menos dos ejes.

Para ello se utiliza el detector de objetos propuesto por Paul Viola yMichael J. Jones [16] para detectar las caras en una imagen y sus partes.

6.2.1. El sistema de deteccion

El detector de caras de Viola y Jones, pese a tener ya 18 anos, ha de-mostrado ser increıblemente robusto para la deteccion de objetos (no solocaras) contenidos en una imagen. Incluso en la era actual donde este tipo deproblemas se atacan principalmente con deep learnig, el algoritmo de Violay Jones sigue siendo una alternativa viable.

El algoritmo tiene tres componentes clave para lograr sus excepcionalesresultados. El primero es el uso de un formato para la representacion de las

19

Figura 4: Distintas posturas que muestran las distintas relaciones en la ubi-cacion de los puntos. Controlando la posicion de la nariz respecto de los ojosen sus componentes x e y se podrıa elaborar un estimador con un controlmultivariable por ejemplo.

imagenes llamado “integral image”, que se obtiene del preprocesamiento dela imagen y que ayuda a aligerar el computo para el clasificador de carac-terısticas. El segundo es el clasificador formado por el algoritmo aprendizajeAdaBoost que selecciona un numero pequeno y crıtico de caracterısticas deun gran set de potenciales caracterısticas. El tercer componente es el meto-do por el que se combinan los clasificadores en “cascadas”, de forma que elsistema invierte mas tiempo en el analisis de porciones de la imagen que sonmas propensas a contener una cara en vez de por ejemplo el fondo de estas.

Los tres componentes mencionados no dejan de ser un resumen muy com-primido de como funciona el algoritmo. Pero para nuestro objetivo, basta conentender los Haar classifier que, en definitiva, son los clasificadores que de-tectan la presencia de una caracterıstica comun del objeto. El sistema utilizaunas figuras rectangulares para identificar las caracterısticas mas notoriasque el sistema entrenado clasifica como util a la hora de distinguir si se tratadel objeto buscado o no. Esta figura puede tener 2, 3 o 4 porciones de distintorelleno que senalizan el tono de oscuridad o claridad que deberıa tener unaporcion de la imagen (en blanco y negro) para considerar que contiene lobuscado.

El sistema entrenado obtendra la figura que resulte mas efectiva a la horade senalar si la imagen tiene unas altas probabilidades de contener el objetobuscado. En el caso de la deteccion de caras, el resultado obtenido por Violay Jones es el que se muestra en la figura 6.

20

Figura 5: “Ejemplo de rectangulos de caracterısticas mostrados en su posicionrelativa respecto de la ventana de deteccion. La suma de los pıxeles que seencuentran en los rectangulos blancos es restada de la suma de los pıxeles enlos rectangulos grises.” - Figura 1 del paper de Viola y Jones [16].

Figura 6: “Primera y segunda caracterıstica seleccionada por el algoritmode aprendizaje. Las dos caracterısticas son mostradas en la fila superior ysobrepuestas en una tıpica imagen de entrenamiento en la fila inferior. Laprimera caracterıstica mide la diferencia de intensidad entre la region delos ojos y la region superior a las mejillas. La caracterıstica se centra en laobservacion de que la region de los ojos es a menudo mas oscura que la delas mejillas. La segunda caracterıstica compara la intensidad en las regionesde los ojos a la intensidad en la region del puente de la nariz.” - Figura 5 delpaper de Viola y Jones [16].

21

6.2.2. Integracion del detector con OpenCV

Como es de esperar, este algoritmo esta implementado en todas las li-brerıas de vision artificial. OpenCV por su parte, ofrece un modulo para ladeteccion de objetos basado en este algoritmo con la mejora anadida porRainer Lienhart [17].

CascadeClassifier es el objeto que OpenCV proporciona para la detec-cion. Para ser inicializado este objeto requiere de un fichero .xml con el clasi-ficador que se desea usar. Afortunadamente, OpenCV ya proporciona variosclasificadores haarcascade con ese formato listos para cargar y ser usados,liberandonos de la tediosa tarea de reunir un dataset gigantesco del ordende miles de imagenes, preprocesar los datos para ajustarse a las condicionesdel entrenamiento y reunir la maquinaria para ello. En concreto, usaremos elclasificador entrenado para detectar caras frontales y otro clasificador parabuscar los ojos. En el caso de la nariz se ha hecho uso de un clasificadorpublicado en la tesis doctoral de Modesto Fernando Castrillon Santana [18].

Ası, tras inicializar el objeto con su correspondiente clasificador, se rea-lizara la busqueda a traves de la llamada al metodo detectMultiScale delobjecto CascadeClassifier.

de t e c tMu l t iS ca l e ( InputArray imageToSearchIn ,std : : vector<Rect>& object sDetected ,double imageScaleFactor = 1 . 1 ,int minNeighbors = 3 ,int l e gacyF lag s = 0 ,S i z e minObjectSize = S i z e ( ) ,S i z e maxObjectSize = S i z e ( ) )

Al metodo se le pasa por el primer parametro la imagen en blanco y ne-gro en la que se quiere realizar la busqueda. Tras ejecutarse el algoritmo, elmetodo devolvera a traves del segundo parametro una lista con las areas enlas que se ha detectado la cara. El resto de parametros especifican la confi-guracion de la ejecucion del algoritmo, donde el tercer parametro, especificacuanto se reducira el tamano de la imagen en cada escalado. Dado que el mo-delo del clasificador que se esta usando tiene unas dimensiones fijas durantesu entrenamiento, es necesario que la imagen se vaya reescalando a tamanosmenores para que la cara que se esta buscando adquiera unas dimensionessimilares a las del modelo del clasificador. Despues tenemos el cuarto parame-tro que limita las areas detectadas a aquellas que tengan un valor mınimo devecinos muy proximos entre sı. Cuanto mas alto sea este valor menos carasse detectaran pero las que se detecten seran con mayor precision (evitandoası la deteccion de fantasmas). El quinto parametro conserva funcionalidadesde versiones anteriores de OpenCV que no son necesarios mencionar. Paraterminar tenemos los ultimos dos parametros que restringen el tamano de lascaras encontradas a unas dimensiones mınimas y maximas en pıxeles.

22

6.2.3. Correccion de sombras

Antes de pasar a aplicar el algoritmo de deteccion de objetos a la sobreuna imagen a la ligera. Conviene mencionar las limitaciones que presenta eldetector ante una iluminacion desfavorable.

Como se ha mencionado en la descripcion del detector de objetos. Elalgoritmo identifica la presencia de un objeto concreto en una imagen com-probando la equivalencia de una porcion de la imagen con varias plantillasque senalizan areas de tonalidad clara y areas de tonalidad oscura como seobserva en la figura 6. Si bien este sistema de deteccion cuenta con ciertarobustez para detectar y ubicar los objetos de la imagen incluso con partesde este objeto mas oscuras de lo habitual, el algoritmo no termina de hacerfrente a condiciones muy adversas en las que, por ejemplo, una buena porciondel objeto queda considerablemente sombreado.

Pero para eso existe una solucion que ayuda a corregir la perdida decontraste de las areas sombreadas: la ecualizacion del histograma. Por histo-grama se refiere a la representacion de la distribucion de la tonalidad de laimagen digital, que en este caso se refiere a la distribucion de la frecuenciadel valor de las escalas de grises por pıxel. La ecualizacion de un histogramaincrementa el contraste global de la imagen a base de distribuir los tonos degrises mas frecuentes en todo su rango. Esto, aplicado al caso de una ima-gen con una porcion muy sombreada, consigue que la tonalidad de grises deambos extremos se nivele y se resalte un poco mas la parte sombreada y unpoco menos la parte clara.

Figura 7: Representacion del histograma y ejemplo de transformacion con laecualizacion del histograma.

Sin embargo la aplicacion de este metodo sobre las imagenes que se reci-ben por la webcam no proporciona una ayuda tan significativa al detector conuna iluminacion desfavorable. Este metodo funciona bien cuando la distribu-cion del valor de los pıxeles es cercana, sino similar, a lo largo de la imagen.Incluso puede desfavorecer imagenes donde la cara esta bien iluminada pero

23

el fondo es muy oscuro, en cuyo caso reduce el contraste de la cara pudiendorepercutir negativamente en la precision de la deteccion.

Pero para eso existe una variante que solventa estos problemas: la ecua-lizacion del histograma adaptativa/local con contraste limitado (CLAHE).Esta alternativa elabora la ecualizacion del histograma en distintas porcionesde la imagen distribuidas como una malla regular. Dando mejores resultadosen imagenes con una o varias partes de la imagen muy oscura y otras partesmuy claras. El unico inconveniente que presenta es la resaltacion del ruidoen la imagen final, que se manifiesta cuando las dimensiones de las porcionesde la maya son suficientemente pequenas como para contener zonas cuyosvalores de los pıxeles son muy homogeneas.

Figura 8: Este ejemplo de imagen representa un caso desfavorable con unaporcion significativa de la cara cubierta por una sombra. La imagen de laizquierda es la captura original en blanco y negro. La del centro es la mismatras aplicarle la ecualizacion del histograma. En el se aprecia una ciertamejora en el contraste pero el tono de la sombra sigue siendo muy agudo. Ala derecha esta el resultado de la aplicacion del CLAHE. Donde la porcion dela cara sombreada es mucho mas clara. Tambien se aprecia la amplificaciondel ruido en esta ultima imagen.

6.2.4. Inicio del programa

El programa realiza en lıneas generales estas funciones: capturar framesde una fuente de vıdeo, detectar la cara y las caracterısticas en ella y mostrarsu deteccion por pantalla pintando una simbologıa que representa lo detec-tado por el tracker. Pero ademas, para flexibilizar la prueba y analisis de losresultados del facetracker implementado, el programa presenta una interfazpor lınea de comandos por el que se pueden seleccionar distintas opciones deejecucion del tracker que ofrecen lo siguiente:

24

Seleccionar la fuente de vıdeo de entrada. Pudiendo ser esta la web-cam del equipo, donde se puede probar la ejecucion en tiempo real deltracker, o un vıdeo almacenado.

Seleccionar que caracterısticas seguir aparte de la cara. Ofreciendo laposibilidad de ademas seguir los ojos y/o la nariz.

Proporcionar distintos haarcascades a cada caracterıstica por parame-tro para probar distintos haarclassifier entrenados.

Mostrar la imagen de salida en blanco y negro con su consecuentepreprocesado.

Almacenar la salida de vıdeo (vıdeo de entrada mas simbologıas de lasdetecciones).

Almacenar en un fichero el tiempo invertido en cada frame en realizarel tracking.

Sacar por la salida estandar la ubicacion de los ojos, nariz o ambas.

Todas sus opciones se pueden obtener ejecutando el comando con el flagde ayuda –help. La codificacion de la interpretacion de los argumentos seresuelve en la funcion init(), que con ayuda del objeto CommandLineParserde OpenCV, interpreta todos los comandos e inicializa las variables y objetosglobales cambiando la logica del bucle principal.

Ptr<CLAHE> c l ahe = createCLAHE ( 2 . 0 ) ; // Gray range e q u a l i z e rCas c ad eC l a s s i f i e r faceCascade ; // Face h a a r c l a s s i f i e rbool searchEyes = fa l se ; // Track eyesCas c ad eC l a s s i f i e r eyesCascade ; // Eyes h a a r c l a s s i f i e rbool searchNose = fa l se ; // Track noseCas c ad eC l a s s i f i e r noseCascade ; // Nose cascadeVideoCapture capture ; // Video where the face i s t rackedbool writeVideo = fa l se ; // Write output v ideoVideoWriter outputVideo ; // Video output streambool gray = fa l se ; // Output gray v ideo in s t ead o f co louredbool noseLoc = fa l se ; // Output nose l o c a t i onbool eyesLoc = fa l se ; // Output eyes l o c a t i onofstream p r o c t im e f i l e ; // F i l e stream to s t o r e process time

// inve s t ed in t rack ingint main ( int argc , char∗∗ argv ){

// Parse command l i n e arguments and i n i t g l o b a l v a r i a b l e si f ( i n i t ( argc , argv ) != 0)

return 1 ;

La descripcion de la implementacion de la funcion init() no se contemplaen este documento puesto que queda fuera del proposito principal de este.Basta con entender que allı se interpretan los argumentos recibidos y secontrola la correcta inicializacion de los clasificadores y los streams de vıdeode entrada y salida.

25

6.2.5. Bucle principal

Una vez definido el funcionamiento del detector, su integracion con la li-brerıa y el preprocesado de la imagen. Se puede ha pasar a definir la ejecuciondel bucle principal donde el facetracker entra en juego. Esta etapa realiza elsiguiente procedimiento iterativo.

1. Capturar una imagen de la camara haciendo uso del objeto VideoCa-putre de OpenCV, quien nos proporciona una interfaz de alto nivelpara configurar la camara del sistema o vıdeo y obtener la imagen enun formato manipulable.

2. Reducir el canal de colores de la imagen a la escala de grises, formatoen el que el detector de objetos opera.

3. Aplicar la Ecualizacion del Histograma Adaptativo de Contraste Limi-tado para reducir el contraste de las sombras de la imagen y con elloanadir robustez frente a una iluminacion no favorable.

4. Realizar la busqueda de caras en todo el cuadro de la imagen y, porcada cara detectada, realizar los siguientes pasos:

a) Dentro del area de la cara detectada, se delimita una region deinteres que cubre poco mas de la mitad superior del area de lacara, para realizar la busqueda de los ojos en ella. En caso dehaber detectado los ojos se pintan en la imagen de salida unosrectangulos que senalizan la ubicacion de estos.

b) Al igual que con los ojos, se delimita una region de interes de apro-ximadamente la mitad y desplazada un poco hacia abajo respectodel centro del cuadro de la cara. En el se aplica la deteccion de lanariz y, de igual manera, se pinta su ubicacion.

5. Se devuelve la ubicacion de las caracterısticas detectadas (si se ha soli-citado), obtenidas de calcular el centro de las areas que cubren los ojosy la nariz.

6. Se pinta por pantalla el resultado y se almacena el frame en el vıdeode salida en caso de haberse solicitado.

En la siguiente porcion de la funcion principal main() se pueden apreciarla declaracion del bucle principal, que itera hasta que el usuario lo interrumpepresionando la tecla o la fuente de vıdeo de entrada finaliza por si sola.

26

int main ( int argc , char∗∗ argv ){// Parse command l i n e arguments and i n i t g l o b a l v a r i a b l e si f ( i n i t ( argc , argv ) != 0)

return 1 ;

Mat frame ; // Frame to read from video source and to draw ins i z e t nFrames = 0 ; // Number o f frames readed on every i t e r a t i o n .i n t64 t0 = cv : : getTickCount ( ) ; // Ticks at the beg in ing o f execu t ioni n t64 process ingTime = 0 ; // Proccesing time used in de t e c t i on// While the v ideo source has frames and the user doesn ’ t h i t ESCwhile ( capture . read ( frame ) && ! ( waitKey (1) == 27/∗ESC∗/ ) ){

// Check frame i n t e g r i t yi f ( frame . empty ( ) ){

c e r r << ”ERROR: :FRAME: :EMPTYFRAMEREADED” << endl ;return 1 ;

}

// Print execu t ion s t a t i s t i c s i f nose/ eyes l o c a t i on i s not requ i rednFrames++;i f ( ! ( noseLoc | | eyesLoc ) && nFrames % 30 == 0)

p r i n tEx e c S t a t i s t i c s ( nFrames , process ingTime , &t0 ) ;

// Measure time used in d e t e c t i n g f a ce s and nosesi n t64 tp0 = getTickCount ( ) ;trackAndDraw ( frame ) ;process ingTime = getTickCount ( ) − tp0 ;

// Write procces s ing time in f i l ei f ( p r o c t im e f i l e . i s open ( ) )

p r o c t im e f i l e <<format ( ” %.4 f ” ,

static cast<double>(process ingTime ) ∗ 1000 .0 f /getTickFrequency ( ) )

<< endl ;

// Write frame on video outputi f ( wr iteVideo )

outputVideo << frame ;// Show frame on window in rea l t imeimshow ( ”OpenCV Facedetec t ion ” , frame ) ;

}

// Release resourcesi f ( p r o c t im e f i l e . i s open ( ) )

p r o c t im e f i l e . c l o s e ( ) ;i f ( capture . isOpened ( ) )

capture . r e l e a s e ( ) ;i f ( outputVideo . isOpened ( ) )

outputVideo . r e l e a s e ( ) ;

return nFrames > 0 ? 0 : 1 ;}

Como se puede ver, en el la propia condicion del while se esta extrayen-do el frame a analizar y se esta comprobando su integridad. Para despues,independientemente de si se muestran o no las estadısticas de la ejecucion,realizar una llamada a la funcion trackAndDraw(frame) quien realiza el fa-cetracking sobre el frame. Para despues pintar por pantalla el resultado y

27

escribir la simbologıa anadida en un vıdeo en caso de haberse especificado.Por otro lado merece la pena mostrar mas atencion al codigo que define

el metodo trackAndDraw(). Donde se realiza el propio tracking como tal(Puntos 2-5).

void trackAndDraw (Mat frame ){// Convert the frame to g ray s ca l eMat grayFrame ;cvtColor ( frame , grayFrame , COLORBGR2GRAY) ;c lahe−>apply ( grayFrame , grayFrame ) ;

// Set the output frame as gray tooi f ( gray )

cvtColor ( grayFrame , frame , COLORGRAY2BGR) ;

// Detect f a c e s on the frame and draw t h e i r l o c a t i onvector<Rect> f a ce s , eyes , noses ;Rect ROINose , ROIEyes ;faceCascade . de t e c tMu l t i S ca l e ( grayFrame , f ace s , 1 . 2 , 2 , 0 , S i z e (100 , 150) ,

S i z e (300 , 4 5 0 ) ) ;for ( s i z e t i = 0 ; i < f a c e s . s i z e ( ) ; i++){

r e c t ang l e ( frame , f a c e s [ i ] , S ca l a r (255 , 0 , 0 ) ) ;

// Use a 3/4 frame s i z e as Region Of I n t e r e s t to search the nosei f ( searchNose ){

ROINose = Rect ( Point ( f a c e s [ i ] . x+f a c e s [ i ] . width ∗0 . 2 ,f a c e s [ i ] . y+f a c e s [ i ] . he ight ∗0 . 35 ) ,S i z e ( f a c e s [ i ] . width ∗0 . 6 , f a c e s [ i ] . he ight ∗ 0 . 5 ) ) ;

r e c t ang l e ( frame , ROINose , Sca l a r (0 , 0 , 2 5 5 ) ) ;Mat frameROI = grayFrame (ROINose ) ;

noseCascade . de t e c tMu l t i S ca l e ( frameROI , noses , 1 . 1 , 2 , 0 ,S i z e (20 , 15) , S i z e (90 , 8 0 ) ) ;

for ( s i z e t j = 0 ; j < noses . s i z e ( ) ; j++){// Use the ROINose as re f e r ence f o r l o c a t i on and dimensionPoint p1 (ROINose . x + noses [ j ] . x , ROINose . y + noses [ j ] . y ) ;Point p2 (ROINose . x + noses [ j ] . x + noses [ j ] . width ,

ROINose . y + noses [ j ] . y + noses [ j ] . he ight ) ;r e c t ang l e ( frame , p1 , p2 , Sca l a r (0 , 255 , 0 ) ) ;

}// fo r}// i f

Al comienzo de esta funcion tenemos la conversion de la imagen recibida aescala de grises y la aplicacion de la Ecualizacion del Histograma Adaptativade Contraste Limitado. Tras eso se inicializan los vectores que almacenaranlas areas (definidas por rectangulos) en la que se ubican los objetos detecta-dos.

La primera busqueda a realizar es la de la cara. Proceso en el que se sepasa la imagen capturada en blanco y negro y preprocesada al metodo de-tectMultiScale. A continuacion, se recorre en un for los distintos rectangulosde las caras detectadas.

El hecho de que se recorran todas ellas (incluso teniendo en cuenta queel sistema deberıa detectar una sola) es por la frecuencia con el que el haar-classifier detecta falsos positivos (o a fantasmas a nuestras espaldas), que en

28

funcion de la imagen puede ser relativamente alta. De hecho, la ecualizaciondel histograma adaptativa puede incrementar la tasa de falsos positivos sila imagen capturada contiene ruido. Aun ası, la tasa de falsos positivos seintenta contrarrestar especificando un mayor numero de vecinos en el cuartoparametro del metodo. Ese valor incrementa la certeza con la que el algo-ritmo valida lo detectado. Descartando las detecciones que no cumplan eserequisito.

Entonces, por cada cara detectada se realiza la busqueda de las carac-terısticas que se hayan senalado. En el codigo mostrado tenemos el condicio-nal searchNose que en caso ser valido (porque se ha especificado su busquedaen la lınea de comandos), se definira una region de interes de dimensionesproporcionales a la cara pero menores a esta, que servira para crear otra ins-tancia Mat que contendra la porcion de la imagen sobre la que se aplicara labusqueda de la nariz. Tras obtener la nariz detectada se realiza el dibujadosobre el frame de salida con el metodo rectangle(), quien recibe por parame-tros los puntos de las esquinas opuestas que forman el rectangulo a pintarsobre el frame y el color.

Figura 9: Esta captura del vıdeo de salida de ejemplo muestra las simbologıasque se dibujan. El cuadro azul representa el area de la cara detectada. Dentrode este estan los marcos marron y rojo, que son las regiones de interes. Losmarcos verdes representan la nariz y el azul claro los ojos.

La misma operacion se realiza para la obtencion de los ojos, utilizandoen ese caso diferentes valores a la hora de definir la region de interes y lasdimensiones mınimas y maximas del objeto a buscar por el detector.

Por ultimo esta funcion realiza la escritura de la ubicacion por la salidaestandar cuando se ha requerido por el usuario.

// Write f e a t u r e s l o c a t i on s to s tdou t i f d e t e c t edi f ( noseLoc | | eyesLoc ){

29

i f ( eyesLoc ){i f ( eyes . s i z e ( ) >= 1){

short x = ( (ROIEyes . x + eyes [ 0 ] . x ) ∗ 2 + eyes [ 0 ] . width ) / 2 ;short y = ( (ROIEyes . y + eyes [ 0 ] . y ) ∗ 2 + eyes [ 0 ] . he ight ) / 2 ;cout << x << ” , ” << y ;i f ( eyes . s i z e ( ) >= 2){

x = ( (ROIEyes . x + eyes [ 1 ] . x )∗2 + eyes [ 1 ] . width ) / 2 ;y = ( (ROIEyes . y + eyes [ 1 ] . y )∗2 + eyes [ 1 ] . he ight ) / 2 ;cout << ” , ” << x << ” , ” << y ;

}} else

cout << ”−1, −1, −1, −1” ;}i f ( noseLoc && eyesLoc )

cout << ” , ” ;i f ( noseLoc ){

i f ( ! noses . empty ( ) ){short x = ( (ROINose . x + noses [ 0 ] . x ) ∗ 2 + noses [ 0 ] . width ) / 2 ;short y = ( (ROINose . y + noses [ 0 ] . y ) ∗ 2 + noses [ 0 ] . he ight ) / 2 ;cout << x << ” , ” << y ;

} elsecout << ”−1, −1” ;

}

cout << endl ;}

}

Basicamente esta porcion de la funcion calcula el centro de las areas de lascaracterısticas detectadas y solicitadas para escribir su resultado por la salidaestandar. Esto nos ofrece la flexibilidad de redireccionar la salida (fichero,consola, otro programa...). El formato de salida son coordenadas del sistemaTopLeft (estandar de referencia para el procesamiento de imagenes) del tipo“x, y”. Cuando alguna de las caracterısticas no se ha llegado a detectar seimprime por salida las coordenadas “-1, -1”.

6.2.6. Resultados

El simple facetracker ha sido sometido a un set de vıdeos de prueba paracomprobar los resultados ante imagenes con distintas condiciones. Los vıdeosde prueba contienen a un usuario en un rango de entre uno y dos metrosde distancia respecto de la camara. Ejecutando giros de cabeceo y guinadacon angulos no superiores a los 30o aproximadamente (angulos superioresdificultan la percepcion de toda la superficie de la pantalla). Tambien seconsideran distintas condiciones en el escenario de captura, partiendo deentornos de captura favorables a menos favorables como se describıa en elapartado 4.2, donde las condiciones de la luz y la postura del usuario respectode la camara varıan.

La reproduccion de los resultados ya denota a simple vista flaquezas enel sistema ante las peores condiciones. Analizando la salida del programa

30

Figura 10: Las imagenes muestran distintas capturas del resultado del face-tracking en algunos vıdeos de prueba. Se puede ver que en algunas e ellas notodas las caracterısticas son detectadas por el sistema debido a las condicio-nes desfavorables.

podemos ver que en las mejores condiciones, como la que se presenta en laprimera imagen de la figura 10, el simple facetracker es capaz de detectartodas las caracterısticas en las distintas posturas que se presenta. En losvıdeos de prueba llevados a cabo, donde el sujeto realiza varias rotaciones,el sistema detecto la ubicacion de las caracterısticas en un 98 % de todoslos frames que componen el vıdeo. En cambio, en casos donde la luz incidıasuperiormente, como la de la segunda imagen de la figura 10, el tracker nodetectaba alguna de las caracterısticas en un 73 % de todos los frames. De135 frames, el sistema detectaba solo uno o ninguno de los ojos en 98 frames.La nariz por otro lado no era detectada en 72 frames de todo el rango. Perohay incluso peores resultados con casos como los de la cuarta imagen de lafigura 10, donde el tracker no detecta alguna de las caracterısticas en un 85 %de todos los frames que componen el vıdeo.

El porcentaje de deteccion de los ojos es en todos los casos mucho menorque el de la nariz. Estos resultados pueden ser causados por la poca precisiondel haarclassifier usado, sobretodo teniendo en cuenta que estaba planteadopara detectar ojos de caras en posicion frontal, no obstante hay que anadirque la principal dificultad para la deteccion de esta caracterıstica reside en elhecho de la anatomıa de este. Pues se tratan de una parte ubicada en zonasmas hundidas de la cara que son mas susceptibles de proyectar una sombrasobre sı al mınimo cambio en la postura.

En definitiva estos resultados demuestran una robustez muy pobre deltracker ante un escenario de captura cuya iluminacion sea mınimamente des-favorable. Dejandolo util bajo unas condiciones mas estrictas que las que seplanteaban en un principio.

Por desgracia, la unica posible mejora al tracker que queda serıa la de en-

31

trenar un haarcascade especıfico para la variedad de imagenes que se esperanen estas condiciones. Desafortunadamente los recursos y el tiempo necesariopara llevarlo a cabo serıan propios para destinarlo a otro proyecto. Por esoel proximo planteamiento llevado a cabo es el estudio de un facetracker queataque al problema de una forma distinta.

6.3. Facetracker de Saragih

El facetracker de estudio sera el que Jason Saragih elaboro en 2012 deno-minado como “non-rigid facetracker”[19].

Este facetracker va mas alla de las pretensiones iniciales de seguir unnumero mınimo de puntos para estimar la postura. Su objetivo, en cambio, esel de seguir un numero alto de caracterısticas faciales que permitan identificarla forma, postura y expresiones de la cara.

Su tracker, parte del uso de unos detectores de caracterısticas facialesbasados en modelos de parches discriminativos para despues, con ayuda delos Modelos de Forma Activa (Active Shape Models), ajustar la forma de lacara detectada con el del modelo entrenado a partir de un dataset.

Su principal caracterıstica, el “Non-rigidity” o no rigidez, “refiere al hechode que las distancias relativas entre las caracterısticas faciales varıa entrelas expresiones faciales y toda la poblacion, y es distinto a la deteccion yel tracking de la cara, quienes solo se centran en buscar la localizacion dela cara en cada frame, en vez de en la configuracion de las caracterısticasfaciales.” - parrafo 1 del capıtulo 4 de Mastering OpenCV 3.

Sin embargo, nuestro problema particular no necesita de un tracker quesea capaz de capturar decenas de puntos que forman la cara. Estas capacida-des son mas practicas para resolver problemas en los que se quiere modelarla forma de la cara en 3D o capturar las expresiones faciales de la persona,entre otras cosas. Pero eso no quita que, si su tracker es capaz de capturardecenas de puntos de la cara de una fuente de vıdeo en tiempo real, no sepueda modificar para que se centre en la captura de unos pocos puntos enpro de la eficiencia.

Por ello, en los apartados de a continuacion, se describira sobre que al-goritmos y metodos se fundamenta este tracker, como esta elaborado y quemodificaciones se pueden llevar a cabo sobre el para centrar su funcionalidada las especificaciones de nuestro problema.

6.3.1. El dataset de entrenamiento

Las tecnicas de facetracking modernas utilizan, casi todas, algoritmos quedependen de la apariencia de las caracterısticas faciales. En este caso, se van

32

a requerir dos tipos de modelos de la cara: uno de defina el aspecto de lascaracterısticas de la cara (forma y tono del area que rodea a las esquinas delos ojos, nariz, cejas...) y otra que defina la estructura geometrica de la cara(distancia de separacion de la esquina de los ojos respecto del puente de lanariz p. ej.). Por ello es importante contar con un buen dataset para que losmodelos desarrollados proporcionen robustez al algoritmo que los utilizara.Dado que estara mas informado del abanico de variedades que pueden exhibirlas caras.

Debido a esto el proyecto ofrece una herramienta de anotacion para elabo-rar el dataset a partir de tus propias fuentes. Aunque por otro lado te permitetambien realizar el entrenamiento sobre un dataset publico con numerosascaracterısticas ya anotadas.

Este trabajo utilizara el dataset publico aconsejado en vez de construiruno propio. Dado que tal practica requiere de una inversion considerable detiempo y paciencia. En su lugar, se va a utilizar el dataset MUCT [24], quecontiene 3755 caras con 76 marcas anotadas, diversas posturas, expresiones,luminosidad, edad y etnia en ella. Ası que no solo permitira saltarse la fasede recoleccion y anotacion, sino que ademas el modelo entrenado contendraun rango considerable de variables a contemplar.

Figura 11: Ejemplo de anotaciones de las caracterısticas faciales de la basede datos MUCT

Por desgracia la herramienta de anotacion viene un poco limitada a lahora de seleccionar que puntos especıficos se quieren utilizar de todos los quecontiene el dataset. Por defecto la herramienta considera la recoleccion detodas las marcas presentes en el dataset de MUCT. Pero mas adelante severa que en casos especıficos podrıa ser mas util utilizar un conjunto menor.Para ello se realizara una modificacion en el codigo fuente de esta herramientapara anadir esa funcionalidad.

33

6.3.2. Detectores de caracterısticas

El objetivo de captura en este tracker son las distintas caracterısticas quecomponen la forma geometrica de la cara. “Dentro del facetracking, la geo-metrıa se define por el conjunto de puntos que corresponde a localizacionesfısicas consistentes en la cara. La seleccion del numero de puntos para repre-sentar esta geometrıa es dependiente de cada aplicacion. [...] Teniendo algunasaplicaciones un conjunto sobre 100 puntos y otras de apenas unas decenas.No obstante, la robustez del Modelo de Forma Activa generalmente mejoracon un mayor numero de puntos, puesto que la medicion de la separacion deestas puede reforzar su dependencia relativa espacial. Ademas, el incrementodel conjunto de puntos para describir la cara conlleva un incremento linealen el coste computacional.” - Parrafo 1 de la seccion Geometrical constrains,capıtulo 4 de Mastering OpenCV 3 [19].

Estos ultimos detalles proporcionan un buen motivo para que en el casopropuesto en este trabajo, se trate de modificar la herramienta de anotacionpara que podamos elaborar un modelo geometrico con un subconjunto menorde todos los puntos que proporciona el dataset MUCT.

En cualquiera de los casos Saragih, considerando que su facetracker puedacapturar caracterısticas del orden de los 100 puntos, se decide por descartartecnicas genericas de deteccion de objetos (como el haarclassifier de Viola yJones por ejemplo) para elaborar una solucion personalizada.

Modelos de parches discriminativos

Para identificar las caracterısticas de la cara se utilizan unos parches quesenalizan las regiones que definen la apariencia de una caracterıstica. Larepresentacion del parche utilizada es una lineal. Una que no es solo muysimple, sino que ademas es de computo ligero. Permitiendo que el detectorpueda gestionar un gran numero de puntos en tiempo real.

Estos modelos de parches, asignados cada uno a cada caracterıstica, si-guen un paradigma de entrenamiento discriminativo. Los metodos discrimi-nativos aprenden una representacion que mejor discrimina una instancia deun objeto de otros objetos que el modelo probablemente encontrara cuandose despliegue.

En este caso particular, el procedimiento de entrenamiento desarrollado esuna que genera parches que, cuando son correlacionados con la regiones de lasimagenes que contienen las caracterısticas faciales, obtienen unas respuestascon un grado de parentesco con las caracterısticas modelo, formada a partirdel dataset de entrenamiento.

34

Figura 12: La figura muestra el resultado de unos modelos de parches dis-criminativos de ejemplo. Figura 11 del capıtulo 4 de Mastering OpenCV 3[19].

El retorno del Viola y Jones

El metodo descrito hasta ahora asume que las caracterısticas faciales estancolocadas en una proximidad aceptable a la estimacion actual. Ese sera elcaso durante la ejecucion del tracking, donde se asume que el movimiento delas caracterısticas entre un frame y otro sera suficientemente bajo para queel detector sea capaz de ubicarse. Pero durante la inicializacion, es necesarioutilizar otro metodo que busque en toda la imagen la posicion de la cara,sobre la que colocar el modelo para que entonces el detector de caracterısticaspueda ubicarse.

Aquı se aplicara el ya conocido detector de objetos de Viola y Jones conun haarcascade entrenado para buscar la ubicacion de la cara. Donde secolocara el modelo geometrico de referencia como se puede observar en lafigura 13. Este modelo geometrico se estudiara en el siguiente apartado, porahora basta con entender que es una plantilla generica de puntos que formanuna cara.

35

Figura 13: Ejemplo del el inicio del tracking. Lo azul representa la caradetectada. Los puntos verdes son el modelo geometrico de referencia. Comose puede observar los puntos del modelo estan lejos de ajustarse a la ubicacionreal de las caracterısticas.

36

Resultados del detector

Este detector de caracterısticas presenta el mismo inconveniente que ya sea visto anteriormente: su precision se ve muy afectada por el ruido de la ima-gen, las posturas y la variedad de las caras. Pero aquı Jason Saragih presentauna solucion inteligente, utilizar los Modelos de Forma Activa para generarun modelo geometrico de la cara. Modelo que se usara para transformar lospuntos detectados con dependencia geometrica.

Figura 14: Las imagenes a la izquierda de cada pareja muestran el imprecisoresultado de solo usar el detector de caracterısticas. Figura 14 del capıtulo 4de Mastering OpenCV 3 [19].

6.3.3. Modelos de Forma Activa

Tim Cootes y Chris Taylor presentaron en 1995 un paper [22] que relata-ba el aprendizaje y aplicacion de modelos parametricos deformables para elreconocimiento y localizacion de objetos deformables en imagenes. Donde unmodelo estadıstico de la variacion global de la forma del objeto es generadoa partir de un conjunto de entrenamiento consistente de imagenes anotadas.Dicho modelo, conocido como Modelo de Distribucion de Puntos, es utilizadopara refinar la precision con la que se delimita el contorno de un objeto. Esdecir, este algoritmo solo permite la deformacion del modelo sobre un objetode una forma consistente con el set de entrenamiento.

Jason Saragih realiza su propia implementacion de este metodo para com-pensar la poca precision del detector de caracterısticas.

6.3.4. Restricciones geometricas

Saragih parametriza la geometrıa facial por la composicion de dos ele-mentos: la transformacion global (rıgida) y la deformacion local (norıgida). La primera especifica la colocacion general de la cara en la imagen.Esto incluye la localizacion (x, y) en la imagen, su rotacion en el plano y la

37

escala. Por el otro lado, las deformaciones locales especifican las diferencias dela forma de la cara entre distintas etnias, expresiones y posturas (rotacionesque no estan en el plano de la imagen como el cabeceo y la guinada).

El Modelo de Distribucion de Puntos, quien nos proporciona el modelogeometrico y su varianza, forma parte del elemento de la deformacion local. ElMDP se obtiene durante el entrenamiento sobre el dataset una vez eliminadoo corregido la tranformacion global de los casos presentados.

Con ese fin, durante el entrenamiento lo primero que se hace con todas lasformas anotadas es utilizar un metodo estadıstico, denominado analisis deProcrustes, para “juntar” en el mismo punto todas las formas y medianteun proceso iterativo de ajuste, colocarlas para que esten lo mas proximasentre sı. Con ello, se obtiene un modelo de la forma canonica y una varianzade sus caracterısticas que serviran para componer el MDP.

Figura 15: Visualizacion de las estapas del analisis de Procrustes. Despuesde normalizar la traslacion, la nube de la estructura de la cara se hace apa-rente. Despues del proceso de normalizacion de la escala y rotacion iterativo,las agrupaciones de las caracterısticas se vuelven mas compactas y su distri-bucion resalta la variedad introducida por la deformacion facial. El ultimopunto representa el resultao final con el mejor ajuste en todo el proceso.Figura 4 del capıtulo 4 de Mastering OpenCV3 [19]

Modelo de Distribucion de Puntos

El Modelo de Distribucion de Puntos utilizado usa una representacionlineal de la geometrıa facial. Aunque existen alternativas mas avanzadas nolineales. Esta, incluso siendo muy simple, ofrece una precisa captura de lasdeformaciones faciales. Ademas proporciona un coste computacional bastantebajo, destacandolo para tareas en tiempo real como la buscada.

Basicamente, se trata de componer un subespacio de menor dimension

38

embebido en el espacio R2n. Espacio cuya base, siendo n es el numero depuntos que forma la cara, es un vector del tipo (x1, y1, ..., xn, yn).

Ese subespacio se obtiene utilizando el Analisis de Componentes Prin-cipales, metodo producto de la combinacion de la estadıstica inferencial yel algebra lineal, sobre las formas del dataset en el que se entrena. Y graciasa ella, cada vez que el detector de caracterıstica nos proporciona una formaimprecisa en el mismo formato que el del ultimo vector descrito. Podremosproyectar esa forma (o punto en el espacio R2n) en el subespacio descrito.Restringiendo la forma geometrica detectada a aquella que sea mas humana.

Figura 16: Modelos de la cara representados como un punto en el espacio 2ndimensional, restringidos por un subespacio (el plano azul) que categoriza lavariedad de las formas de las caras “realistas”. Figura 5 del capıtulo 4 deMastering OpenCV 3 [19].

Y con esto finalmente se completa la descripcion del proceso de entrena-miento del non-rigid facetracker.

6.3.5. El bucle principal

Curiosamente, las secciones anteriores han cubierto las descripciones delos componentes que forman el facetracker en el mismo orden en el que seejecutan durante el tracking. En cambio, el proceso de entrenamiento serealiza al reves: primero se construye el Modelo de Distribucion de Puntos ydespues el modelo de parches (el haarcascade se da por hecho). Pero volviendoal tracking, para recordarlo una vez mas, el algoritmo del facetracker finalrealiza lo siguiente.

39

1. Extraer el frame de la fuente de vıdeo y utilizar el haarcascade paraubicar la posicion de la cara en el plano bidimensional de la imagen.Dando un punto de partida al detector de caracterısticas para que luegocontinue el tracking por sı solo.

2. El detector de caracterısticas parte de los puntos detectados anterior-mente (o la plantilla canonica en caso de venir del punto 1) para buscarlas caracterısticas faciales en las regiones cercanas. Utilizando los par-ches modelo obtenidos en el entrenamiento, el metodo realiza por cadacaracterıstica unas pruebas de correspondencia de varias regiones de laimagen cercana a la caracterıstica con el parche modelo, colocando elpunto en aquella correspondencia que mejor respuesta de.

3. El resultado del detector es proyectado al subespacio de las caras. Refi-nando la definicion de la forma detectada a una mas plausible/precisa.

4. Se imprimen de los puntos obtenidos finales, se extrae el siguiente framey se vuelve al punto 2.

6.3.6. Resultados del facetracker por defecto

Para poner a prueba el tracker por defecto se han realizado unas mıni-mas modificaciones al codigo fuente para actualizar la version de OpenCV.Tras eso se ha procedido a entrenar el sistema utilizando todas las anota-ciones que proporciona la base de datos MUCT. Utilizando los parametrosentrenamiento y ejecucion por defecto.

Lo que se observa en la fila superior de la figura 17 es el resultado que eltracker ofrece sobre el vıdeo test con un entorno favorable. Donde se apreciauna precision notablemente buena en casi todo el set de imagenes a excepcionde la boca y el contorno externo de la cara que va de oreja a oreja. Estaexcepcion tiene un fundamento bastante obvio, y es que resulta que a pesarde las buenas propiedades que ofrece la base de datos de MUCT (108 sujetosdistintos de Sudafrica, poblacion con una gran diversidad etnica). El datasetapenas contiene personas que tengan una barba y bigote notoriamente espeso.Debido a esto, los parches generados del dataset ubican las caracterısticasfaciales relativas a la boca y al perfil de la cara mal. Motivo por el que eltracker senala la posicion de la boca mas arriba de donde esta y el contornomas adentro del real.

Que el detector no sea capaz de seguir bien a los naufragos y hipsterses un inconveniente menor. Sobretodo considerando que se podrıan tomarunicamente los datos de la posicion de los ojos y la nariz. Siendo el restoirrelevante.

40

Figura 17: Facetracker de Saragih por defecto ejecutandose sobre un vıdeoen unas condiciones de captura excepcionales y otro vıdeo en condicionesdesfavorables.

Continuando con el analisis, resulta que en ambas pruebas se hace visiblela perdida de precision ante giros que aceleran mınimamente. Sobretodo encasos como los de la fila inferior, que aunque a priori parezca dar unos buenosresultados (que en comparacion con el simple facetracker lo son), el sistemasigue con dificultad la cara cuando no esta en reposo.

No obstante se podrıa decir que a fin de cuentas el facetracker rindebastante bien incluso en una gran variedad de condiciones. Mas adelante,en el apartado 7 se analizara su precision, eficiencia y se comparara con elsimple facetracker.

6.3.7. Modificaciones

El codigo fuente ha sufrido significativos cambios a lo largo del estudio.El codigo oficial, disponible en un repositorio en github [20] y otro en

la editorial Packt, estaba implementado para utilizar OpenCV 3. Luego laprimera modificacion que se realizo fue la actualizacion a OpenCV 4.

El siguiente cambio aplicado ha sido el mencionado en anteriores aparta-dos: la modificacion de la herramienta de anotacion para poder seleccionarun subconjunto de las marcas anotadas del dataset de MUCT. Con motivo deanalizar el impacto en el rendimiento general de la aplicacion al seleccionarun numero menor de puntos.

Para la inicializacion del detector de caracterısticas. Se sustituyo el meto-do de ecualizacion del histograma por el CLAHE. Metodo cuyas ventajas yase describieron desarrollando el simple facetracker (6.2.3). Tambien se apro-

41

vecho la experiencia adquirida allı para ajustar los parametros del metododetectMultiScale() a mejores valores. Los que venıan por defecto daban de-masiados falsos positivos.

Por ultimo pero no menos importante. Se anadieron funcionalidades extrapara el estudio y analisis del tracker que incluyen:

Escribir el vıdeo resultado con la simbologıa a un fichero.

Medir los tiempos invertidos en el tracking en cada frame.

Escritura por la salida estandar de las posiciones de los ojos y nariz.

Todas las modificaciones pueden encontrarse en el proyecto alojado en elrepositorio GitHub [21].

Modelos personalizados

Ante estas modificaciones, surge la curiosidad de comprobar si se puedesacar provecho de algun cambio para el problema planteado inicialmente: elseguimiento de los ojos y la nariz.

Para ello se ha reentrenado el sistema aprovechando las modificacionesanadidas a la herramienta de anotacion. Donde se han escogido un subcon-junto de 39 puntos de los 76 posibles. El enfoque seguido para la seleccionha de evitar el cumulo de puntos en las mismas partes de la cara (salvo porla nariz). En la boca, como medida para contrarrestar los fallos con los bi-gotes, se ha seleccionado solo los puntos que forman el perfil inferior el labioinferior.

Para compensar la reduccion de puntos y la separacion de estas entre sı,se ha ampliado un poco el tamano de los parches para mejorar la precisiondel detector de caracterısticas.

Los resultados a simple vista se pueden visualizar en la figura 18. Pero suprecision y rendimiento a efectos practicos se expondran en el apartado 7.

42

Figura 18: La primera fila muestra los resultados del facetracker de Saragihmodificado. La fila de abajo es la solucion por defecto que salıa en la figura17

43

7. Comparacion y pruebas

Finalmente se expondran los resultados de toda esta investigacion. Enconcreto, se analizaran los resultados obtenidos de someter a ambos trackerstres vıdeos de prueba. Comprobando la precision y el consumo de recursosdel tracker durante la ejecucion.

7.1. Vıdeos de prueba

Los vıdeos presentaran tres situaciones distintas. Donde todas ellas tendranun punto en comun: el mismo usuario, un varon blanco con barba y pelo lar-go, realizando distintos giros y posturas dentro de los parametros aceptables(angulos de giro menores a 30-40o aproximadamente). La variedad de losvıdeos esta descrita en los siguientes puntos:

Biblioteca: La captura se ha realizado en una biblioteca con una muybuena iluminacion artificial y natural. El usuario guarda una distanciaproxima a la camara de medio metro aproximadamente y mantiene unacorrecta alineacion con el area de captura. Ademas la persona llevapuestas unas gafas.

Sombra parcial: En este escenario el usuario presenta unas condi-ciones similares a la anterior a excepcion de la ausencia de gafas y lailuminacion. Que en este caso la fuente natural incide por un lateraldejando un alto contraste en la superficie de la cara con porcion muyoscura.

Lejano: Aquı el usuario mantiene una distancia de entre 2,5 y 3 metrosde la camara. La fuente de luz es artificial y esta colocada entre mediasde la camara y el sujeto a una altura de 2 metros. El usuario no llevapuesto las gafas.

7.2. Precision

Para evaluar la precision de los trackers se ha procedido a anotar a manolas ubicaciones en cada frame de dos caracterısticas (ojo derecho y nariz)para compararlas con las ubicaciones de los trackers.

En realidad, se ha desarrollado un pequeno script en python (videotra-ze.py), que toma la ubicacion senalada por el usuario con el raton en losframes cada segundo. Luego interpola los puntos en cada uno de los framesintermedios al segundo y los anota en un fichero. El resultado final es un

44

fichero que contiene la ubicacion casi exacta de la caracterıstica seguida porel usuario en cada uno de los frames. Este sera el fichero de referencia que seutilizara para compararlo con el resultado del resto de los trackers.

plot.py, es la herramienta desarrollada para analizar los resultados (basa-da en una realizada con el companero Alejandro Mendez Fernandez con unproposito similar en la asignatura de robotica [25]). Que calcula la distancia,en pıxeles, de la ubicacion de la caracterıstica obtenida por los trackers res-pecto de la referencia anotada a mano. Tambien calcula el error cuadraticomedio de las distancias. Todos estos calculos son desplegados en un graficoque muestra a lo largo de los frames la distancia de cada uno de los trackersrespecto de la ubicacion real.

7.3. Consumo de recursos

Si el facetracker pretende usarse en el mismo equipo que va a ejecutar elresto de componentes que forman el headtracker y encima un videojuego osimulador. Lo ideal serıa que su consumo fuese lo mınimo posible. Por ello,se va a mostrar el impacto de la ejecucion del tracking midiendo el tiempode computo de este en cada una de las iteraciones. Ademas, se proporcionarael tiempo real invertido en ejecutar todos los vıdeos mas el tiempo que elproceso ha permanecido en CPU.

7.4. Resultados

Se va a proceder a exponer los resultados comenzando por la precision. Sevan a mostrar los resultados del error de los trackers respecto de la referenciaen cada uno de los vıdeos y, por ultimo, se hara un resumen general sobre elimpacto de los facetrackers en la CPU.

45

Biblioteca

Figura 19: Los distintos facetrackers vistos siendo sometidos al primer video.

Figura 20: La lınea y el valor en rojo son resultados del simple facetracker(aproximacion por haarcascades). En azul los del facetracker de Saragih pordefecto. En verde los del mismo facetracker con las modificaciones anadidas.

Lo que se muestra en la figura 20 es el grafico que representa, en cada fra-me, la distancia entre la ubicacion del ojo derecho que reporta cada uno de lostrackers y la ubicacion “real”. Como se prometio, el grafico tambien muestrael resultado del error cuadratico medio de cada uno de los facetrackers.

Ahora, comentando los resultados, lo que se puede sacar en claro es que engeneral todos los trackers dan un buen resultado. Si consideramos la distanciadel usuario a la camara (de apenas medio metro), la resolucion de la captura(1280x720 pıxeles). Queda claro que los errores reportados son mınimos.

46

Figura 21: Mismo test pero esta vez siguiendo la nariz.

En el grafico de la figura 21 el resultado cambia considerablemente res-pecto del anterior. El simple facetracker obtiene un error considerablementemenor respecto del de Saragih en sus dos versiones. Esto recuerda que cuandose analizaba el simplefacetracker se veıa que, mientras que los ojos los seguıacon bastante dificultad, con la nariz no ocurrıa lo mismo. Y precisamente locontrario es lo que ocurre con el facetracker de Saragih, donde los ojos soncapturados con una precision excepcional a diferencia de la nariz.

Por otro lado, revisando el tiempo invertido en el tracking, tenemos undiagrama de barras (fig. 22) que muestra el esfuerzo llevado a cabo por cadatracker.

El diagrama 22 muestra otra clara diferencia entre el simple facetrackery las versiones del de Saragih. Los valores del simple facetracker, cuya mediaesta por los 33 milisegundos, triplican los de sus competidores. Ademas estevalor por sı solo lo deja en una posicion comprometida si se pretende ejecutaren tiempo real. Pues si el dispositivo de captura alcanzase los 30 frames porsegundo, el tracker ya se quedarıa corto a la mınima que invirtiese mas tiempode la cuenta (como los 41 milisegundos maximos).

Por otro lado, las versiones del facetracker de Jason Saragih estan muyparejas. Aunque la version modificada se ve que rinde un poco mejor. Luegose aprecia un pequena mejora general, tanto en consumo como en precisionde la version mejorada.

47

Figura 22: Tiempo invertido en aplicar el tracking en un frame.

48

Sombra parcial

Figura 23: Los distintos facetrackers vistos siendo sometidos al segundo video.

Figura 24: Resultados del seguimiento del ojo derecho en un escenario conmala iluminacion.

En la figura 24 se aprecia como la iluminacion pone en un gran aprietoal facetracker simple, que en varias secuencias del vıdeo pierde por completola ubicacion del ojo y genera grandes errores.

Esto demuestra una vez mas la gran robustez que presenta el facetrackercon modelos geometricos y de parches. Incluso en estas adversas condicionesel algoritmo se las arregla para estimar con un error bajo la posicion del ojo.

Con la nariz los resultados tienen un comportamiento muy similar salvoque con un incremento del error general a todos los trackers (figura 25). Estose podrıa deber por los parches de modelo lineal y el caso particular queenfrenta la nariz a estos. El principal problema es que las areas superiores a

49

los orificios, por el puente y en areas proximas, la superficie tiene un tono muyhomogeneo. Esto no favorece en absoluto al detector de caracterısticas porquesin zonas que den un contraste significativo, los parches proporcionan menosprecision y en los casos donde la sombra interfiere mucho, acaban siendotodavıa menos precisos.

Figura 25: Resultados del seguimiento de la nariz en un escenario con malailuminacion.

Antes de terminar con esta prueba tenemos los resultados del tiempode procesamiento que aparece en la figura 26. Cuyos valores comienzan a serproximos entre todos los trackers. Aquı el simple facetracker reduce su tiempode computo al descartar con mas facilidad la busqueda de las caracterısticas.

50

Figura 26: Tiempo de procesamiento invertido en cada frame en el vıdeo conla cara sombreada.

51

Lejano

Figura 27: Los distintos facetrackers vistos siendo sometidos al tercer video.

Figura 28: Resultados del seguimiento del ojo derecho de un usuario lejano.

Los resultados que aparecen en la figura 28 se tienen que tratar con cui-dado. Esta vez el usuario esta ubicado a una distancia lejana. Donde cadapıxel representa una mayor superficie de la cara del usuario. Pero no solo eso,de hecho los datos de las ubicaciones de referencia se tendrıan que tomar conprecaucion, pues entre la interpolacion y el propio error humano, es posibleque haya errores acumulados.

En la figura 30, apenas hay nada nuevo que anadir salvo por un pequenodecremento del tiempo invertido en general. Causa del procesado de las ca-racterısticas faciales en regiones con unas dimensiones en pıxeles menor queen los anteriores casos.

52

Figura 29: Resultados del seguimiento de la nariz de un usuario lejano.

Figura 30: Tiempo de procesado del tracking en el tercer test.

53

Resumen de consumo de recursos

El ultimo dato que falta por dilucidar, que servira para aclara un pocomas la informacion aportada sobre el tiempo de procesamiento, es el consumode la CPU.

Figura 31: Tiempo invertido en la ejecucion de las tres pruebas por cada unode los trackers.

El diagrama de barras de la figura 31, aporta unos resultados que puedenser un poco contradictorios al principio. Observando el tiempo real que hantardado los trackers en analizar los tres vıdeos de prueba, se ve que todosellos han tardado casi lo mismo, y sin embargo, el tiempo de procesamientomedido es muy distinto entre el tracker simple y el de Saragih.

Pero aquı es donde se muestra el rendimiento de un tracker basado enhaarcascades. El clasificador del algoritmo de deteccion evalua inicialmentelas caracterısticas que aclaran si la imagen tiene o no el objeto, luego, si laimagen lo contiene, el algoritmo invierte un tiempo mayor en ubicarlo. Pe-ro este comportamiento discriminador es el que proporciona la eficiencia delalgoritmo. Precisamente por esto tambien los valores mınimos del procesa-miento en algunos frames son muy muy bajos. Porque el algoritmo detectainmediatamente que es muy improbable que la imagen contenga el objetobuscado.

Queda un ultimo asunto por resolver y es el de la paralelizacion de estosprocesos. Por un lado, el facetracker de Saragih es sencillamente secuencial,bueno, algorıtmicamente lo es. Pero casi todas las opreaciones matriciales(aquellas que usan el tipo Mat de OpenCV) estan aceleradas por hardwaregracias a el uso de instrucciones SIMD. Por el otro lado el simple facetrac-ker, que realiza varias llamadas al metodo detector de objetos, si esta mas

54

paralelizado. Puesto que estos metodos para su ejecucion despliegan tantoshilos como haya disponibles en la CPU para realizar la comprobacion de lascaracterısticas paralelamente. De ahı que el tiempo que pasa el proceso enCPU sea mucho mayor que el real.

Esto demuestra el increıble soporte del hardware que tiene OpenCV, quesin necesidad de configurar nada, la librerıa ya hace su labor para exprimiral maximo hardware disponible.

Ahora, en terminos practicos, lo que se busca es el tracker cuyo impactoen los recursos del sistema sea menor y en eso, sin ninguna duda, gana elfacetracker de Saragih. Puesto que su proceso, incluso sin acaparar todos losnucleos disponibles en la CPU, es capaz de dar mejores resultados que el quelo hace.

55

8. Aspectos sociales, eticos y medioambien-

tales

El area en el que se centra este trabajo, la vision artificial, es sin dudauna muy relevante en lo que refiere a los aspectos eticos y sociales. No tantocon el medioambiental a lo mejor. Pero aun ası habra una pequena nota alrespecto. En adelante se hablara sobre las implicaciones y repercusiones deeste trabajo y su area en los siguientes apartados.

8.1. Compromiso social y etico

Cuando los datos que se estan manipulando en un programa son caras deseres humanos, lo mınimo serıa meditar con que proposito se quiere accedera esa informacion. Aquı se despierta mucha controversia. Porque por lo visto,aunque hacer un facetracker para pasartelo mejor en los videojuegos parezcaalgo inofensivo. Podrıa no ser la mejor decision considerando que esos es-fuerzos se podrıan llevar a cabo para facilitar la accesibilidad a los equiposinformaticos para personas con discapacidad motriz.

Por otro lado, ¿Que ocurre cuando un desarrollador independiente preten-de implementar un programa con algoritmos de aprendizaje que requieren dedatasets enormes con caras?, ¿De donde las obtiene alguien cuando no formaparte de una corporacion que maneja millones de fotos en sus redes sociales,que luego usan como quieren con total impunidad? A menudo, plantear elentrenamiento de, por ejemplo, un haarclassifier para resolver un problema,supone un gran coste, en esfuerzo para recolectarlo, y material, en adquirir-lo. Mientras que muchas de las grandes corporaciones tienen el acceso a esosdatos inmediato. E incluso a dıa de hoy puedes descubrir que hay agenciaspseudo-gubernamentales que, rompiendo la separacion de poderes, accede aregistros estatales de la poblacion nacional para mejorar su reconocimien-to facial [28] porque “la seguridad por menos privacidad” merece la pena.Mientras este trabajo a tenido acceso a solo 3755 fotos para montar un face-tracker que hace lo justo. Resulta que no solo existen agencias del gobierno,sino ademas grandes corporaciones tecnologicas, que manejan millones dedatos personales con el objetivo de recrearnos el mundo de George Orwell.Pero bueno, alguna consecuencia tenıa que tener el estar regalando toda lainformacion personal a cambio de utilizar programas convenientes.

Exactamente por el mismo motivo, por el uso de una librerıa conveniente,resulta que el proyecto de FacetrackNoIR se quedo con un facetracker obsoletoe inutil. Por ello se ha estudiado como elaborar una alternativa abierta desdela raız. Para permitir que en cualquier momento y por cualquier persona se

56

pueda estudiar que es lo que hace el facetracker por debajo. Proporcionandoel codigo fuente del programa, no solo proporcionas la oportunidad de quealguien aprenda el como funciona, sino que ademas puedes proporcionarle laseguridad de que el programa elaborado es totalmente legıtimo y no viola suprivacidad y libertad.

Por ultimo mencionar en este apartado la responsabilidad del desarro-llador que trata con rasgos fısicos de las personas. Puesto que generalmentetendra que enfrentarse, o al menos deberıa, con los problemas que conllevahacer un programa funcional para toda la diversidad humana. Ya se ha vistoen este trabajo por ejemplo los fallos que daba el facetracker con barbudos.Que no ha llegado al extremo de inutilizar todo el servicio como lo hacıa elfamoso dispensador de jabon que no dispensaba a manos de piel oscura [29].Pero ha servido como signo del problema anadido que presentan estos casos.

8.2. Compromiso medioambiental

Aunque todo el desarrollo expuesto ha sido principalmente software. Tan-to en el objetivo como en las especificaciones del proyecto se ha tratado deenfocar el problema con un claro peso al desarrollo sostenible. Por eso seha tratado de brindar accesibilidad al area del headtracking y la realidadaumentada en general con el hardware mas accesible disponible (webcam yequipo de gama domestica modesto).

57

9. Conclusion

Tras el exhaustivo estudio sobre el facetracking. Se ha probado a elaborarun facetracker con una aproximacion sencilla. Para despues estudiar unasolucion mas compleja para compararlo con un equivalente mas moderno.

Aunque los resultados han dejado claro que la primera solucion esta muylejos de alcanzar las propiedades del segundo. El facetracker planteado haservido perfectamente para zambullirse en la problematica del area y tomaruna mejor perspectiva del asunto. Por otro lado, el estudio del facetrackerde Jason Saragih ha proporcionado una buena captura de las tecnicas masmodernas utilizadas en el area.

Y todo esto ha servido para avanzar en el objetivo principal: el de cons-truir un headtracker. Con todo lo aprendido en este trabajo se puede decirque el componente del headtracker encargado de la captura, el facetracker,ya esta muy avanzado.

9.1. Posibles mejoras y futuras lıneas de trabajo

Sin embargo, el sistema se puede mejorar todavıa mas. Y tambien quedanvarios componentes a elaborar para construir el headtracker.

9.1.1. Mejoras en el facetracker

Siguiendo con el apartado del facetracking. Los que se han presentadohasta ahora ya son funcionales. No obstante nada impide que se puedanseguir mejorando.

En lo que respecta al simple facetracker, como ya se comento en su mo-mento, la unica mejora posible que quedarıa por investigar es la de construirun haarcascade desde cero. Es decir, elaborar un dataset de imagenes es-pecıficas para resolver el problema. Como idea, se podrıa obtener la fuentede imagenes de vıdeos que contengan videollamadas, puesto que este tipo decontenido es el que mas se ajusta a la problematica.

Con el facetracker de Saragih, en cambio, no hay sugerencias disponiblesen lo que respecta a sus fundamentos. Pero serıa interesante intentar mejorarel dataset de imagenes para incrementar la robustez del sistema.

Hay otra nota importante a anadir aquı, y es que el planteamiento delfacetracker se podrıa llevar a cabo con la perspectiva que mas esta de modahoy en dıa. La del deeplearnig y las redes neuronales, que difiere bastante elutilizado en este trabajo.

58

9.1.2. Futuras lıneas de trabajo

Dando por terminado el facetracker, quedan aun dos componentes princi-pales para terminar el headtracker: el estimador de la postura y la conexioncon el entorno virtual.

Este trabajo ha enfocado la solucion del facetracker a una que luegorecayera sobre un control multivariable como estimador. En principio, unestimador de esta categorıa no serıa la mas practica en el uso pero sı en eldesarrollo dado que son muy sencillos de implementar. Por ejemplo se podrıaimplementar un control multivariable con varios PID o con Fuzzy Logic.Por supuesto, estos controladores presentarıan el inconveniente del constantereajuste de los parametros requeridos para funcionar. De ahı la necesidad debuscar alguna alternativa.

Resulta que una de las personas que elaboraron los Modelos de FormaActiva (Tim Cootes), utilizados luego en el facetracker de Saragih. Realizoposteriormente una mejora con los Modelos de Apariencia Activa [26]. Tecni-ca que elabora el modelo de un objeto con la informacion estadıstica de suforma y textura. Este modelo permite reconstruir el objeto 3D, que luegopuede ser utilizado por el algoritmo POSIT [27] (Pose from Orthography andScaling with Iterations), que realiza la estimacion de la pose del objeto 3D.Esta es la opcion ideal para complementar el facetracker de Saragih.

En lo que respecta a la conexion con el entorno virtual, como ya se vioen el apartado 3.2, bastarıa con que la salida de informacion del estimadorse conectase con alguno de los gestores de trackers disponibles como Open-track o FacetrackNoIR. Estos ofrecen una API a la que conectar los trackers.Luego ellos gestionan el filtrado, parseado y adaptacion de la informacion alprotocolo de comunicaciones del videojuego o simulador de turno.

En cualquiera de los casos, queda bastante claro que la elaboracion delestimador es una tarea que requiere bastante tiempo. Pudiendo incluso serplanteado para otro Proyecto de Fin de Grado.

59

10. Anexos

10.1. Acronimos

1. RV: Realidad Virtual

2. RA: Realidad Aumentada

3. RGB: Red Green Blue (Rojo Verde Azul)

4. API: Application Programming Interface (Interfaz de Programcion deAplicaciones)

5. CLI: Command-Line Interface (Interfaz de Lınea de Comandos)

6. GUI: Graphical User Interface (Interfaz de Usuario Grafica)

7. FPS: Frames Per Seconds (Fotogramas Por Segundo)

8. RAM: Random Access Memory (Memoria de Acceso Aleatorio)

9. GPU: Graphics Processor Unit (Unidad de Procesamiento Grafico)

10. CPU: Central Processor Unit (Unidad Central de Procesamiento)

11. SIMD: Single Instruction Multiple Data (Una Instruccion, MultiplesDatos)

12. CLAHE: Contrasted Limited Adaptative Histogram Equalization (Ecua-lizacion del Histograma Adaptativa de Contraste Limitado)

13. ASM: Active Shape Models (Modelos de Forma Activa)

14. MDP: Modelo de Distribucion de Puntos

15. POSIT: Pose from Orthography and Scaling with Iterations.

60

10.2. Codigo fuente del simple facetracker

/∗∗ Simple f a c e t r a c k e r . Capture face f e a t u r e s in rea l t ime using haarcascades .∗ Copyright (C) 2019 Leonardo Nie l s Pardi∗∗ This program i s f r e e so f tware : you can r e d i s t r i b u t e i t and/or modify∗ i t under the terms o f the GNU General Pub l i c License as pub l i s h ed by∗ the Free Software Foundation , e i t h e r ver s ion 3 o f the License , or∗ ( at your opt ion ) any l a t e r ver s ion .∗∗ This program i s d i s t r i b u t e d in the hope t ha t i t w i l l be use fu l ,∗ but WITHOUT ANY WARRANTY; wi thout even the imp l i ed warranty o f∗ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the∗ GNU General Pub l i c License f o r more d e t a i l s .∗∗ You shou ld have rece i v ed a copy o f the GNU General Pub l i c License∗ along with t h i s program . I f not , see <h t t p s ://www. gnu . org/ l i c e n s e s />.∗/

#include <opencv2/ core . hpp>#include <opencv2/ v id eo i o . hpp>#include <opencv2/ h ighgu i . hpp>#include <opencv2/ imgproc . hpp>#include <opencv2/ ob jde t e c t . hpp>

#include <vector>#include <iostream>#include <fstream>#include <s t r i ng>

using namespace cv ;using namespace std ;

// Parse command l i n e arguments and i n i t i a l i z e programint i n i t ( int argc , char∗∗ argv ) ;// Print execu t ion s t a t i s t i c s through t s t dou tvoid p r i n tEx e c S t a t i s t i c s ( s i z e t nFrames , in t64 process ingTime , in t64 ∗ t0 ) ;// Search fo r f a c e s and/or noses and draw t h e i r l o c a t i onvoid trackAndDraw (Mat frame ) ;

const St r ing keys =”{help h | | Print he lp message}””{camera c | 0 | Camera dev i ce number as v ideo stream input }””{ video v | | Video f i l e as v ideo stream input }””{@face cascade f |/ usr / share /opencv4/ haarcascades / haa r c a s c ad e f r on t a l f a c e ”” d e f a u l t . xml | . xml f i l e }””{ eye s ca s cade e | | t rack eyes us ing cascade f i l e s p e c i f i e d }””{ nose cascade n | | t rack eyes us ing cascade f i l e s p e c i f i e d }””{out o | | Write a video f i l e −o <name>. av i }””{gray g | | Output video in g r ay s c a l e }””{ no s e l o c a t i o n n l | | Writes to stdout the nose l o c a t i o n i f detected , ”” otherwi se \ ’−1 , −1\ ’}””{ e y e s l o c a t i o n e l | | Writes to stdout the eyes l o c a t i o n i f detected , ”” otherwi se \ ’−1 , −1\ ’}””{ proc t ime p | | Write the p ro c e s s i ng time o f d e t e c t i on in a f i l e ”” ( camproctime or <vid>proct ime )} ” ;

const St r ing about =”Easy f a c e d e t e c t i o n v1\n””This program i s a f a c e t r a c k e r concept implemented us ing haarcascades ” ;

61

Ptr<CLAHE> c l ahe = createCLAHE ( 2 . 0 ) ; // Gray range e q u a l i z e rCas c ad eC l a s s i f i e r faceCascade ; // Face h a a r c l a s s i f i e rbool searchEyes = fa l se ; // Track eyesCas c ad eC l a s s i f i e r eyesCascade ; // Eyes h a a r c l a s s i f i e rbool searchNose = fa l se ; // Track noseCas c ad eC l a s s i f i e r noseCascade ; // Nose cascadeVideoCapture capture ; // Video where the face i s t rackedbool writeVideo = fa l se ; // Write output v ideoVideoWriter outputVideo ; // Video output streambool gray = fa l se ; // Output gray v ideo in s t ead o f co louredbool noseLoc = fa l se ; // Output nose l o c a t i onbool eyesLoc = fa l se ; // Output eyes l o c a t i onofstream p r o c t im e f i l e ; // F i l e stream to s t o r e process time

// inve s t ed in t rack ingint main ( int argc , char∗∗ argv ){

// Parse command l i n e arguments and i n i t g l o b a l v a r i a b l e si f ( i n i t ( argc , argv ) != 0)

return 1 ;

Mat frame ; // Frame to read from video source and to draw ins i z e t nFrames = 0 ; // Number o f frames readed on every i t e r a t i o n .i n t64 t0 = cv : : getTickCount ( ) ; // Ticks at the beg in ing o f execu t ioni n t64 process ingTime = 0 ; // Proccesing time used in de t e c t i on// While the v ideo source has frames and the user doesn ’ t h i t ESCwhile ( capture . read ( frame ) && ! ( waitKey (1) == 27/∗ESC∗/ ) ){

// Check frame i n t e g r i t yi f ( frame . empty ( ) ){

c e r r << ”ERROR: :FRAME: :EMPTYFRAMEREADED” << endl ;return 1 ;

}

// Print execu t ion s t a t i s t i c s i f nose/ eyes l o c a t i on i s not requ i rednFrames++;i f ( ! ( noseLoc | | eyesLoc ) && nFrames % 30 == 0)

p r i n tEx e c S t a t i s t i c s ( nFrames , process ingTime , &t0 ) ;

// Measure time used in d e t e c t i n g f a ce s and nosesi n t64 tp0 = getTickCount ( ) ;trackAndDraw ( frame ) ;process ingTime = getTickCount ( ) − tp0 ;

// Write procces s ing time in f i l ei f ( p r o c t im e f i l e . i s open ( ) )

p r o c t im e f i l e <<format ( ” %.4 f ” ,

static cast<double>(process ingTime ) ∗ 1000 .0 f /getTickFrequency ( ) )

<< endl ;

// Write frame on video outputi f ( wr iteVideo )

outputVideo << frame ;// Show frame on window in rea l t imeimshow ( ”OpenCV Facedetec t ion ” , frame ) ;

}

// Release resourcesi f ( p r o c t im e f i l e . i s open ( ) )

p r o c t im e f i l e . c l o s e ( ) ;i f ( capture . isOpened ( ) )

capture . r e l e a s e ( ) ;i f ( outputVideo . isOpened ( ) )

62

outputVideo . r e l e a s e ( ) ;

return nFrames > 0 ? 0 : 1 ;}

// Parse command l i n e arguments and i n i t i a l i z e programint i n i t ( int argc , char∗∗ argv ){

CommandLineParser pa r s e r ( argc , argv , keys ) ;pa r s e r . about ( about ) ;

// Check argumentsi f ( ! pa r s e r . check ( ) ){

par s e r . p r i n tE r r o r s ( ) ;pa r s e r . pr intMessage ( ) ;return 1 ;

}i f ( pa r s e r . has ( ” he lp ” ) ){

par s e r . pr intMessage ( ) ;return 0 ;

}

// Load cascadeSt r ing face cascade name = par s e r . get<Str ing >(0) ;i f ( ! faceCascade . load ( face cascade name ) ){

c e r r << ”ERROR: :CASCADE: : FAILURE LOADING FACE CASCADE FILE” << endl ;return 1 ;

}

// Check eyes cascadeSt r ing eyes cascade name = par s e r . get<Str ing >(” eye s ca s cade ” ) ;i f ( ! eyes cascade name . empty ( ) ){

searchEyes = true ;i f ( ! eyesCascade . load ( eyes cascade name ) ){

c e r r <<”ERROR: :CASCADE: : FAILURE LOADING EYES CASCADE FILE”<< endl ;

}}

// Check nose cascadeSt r ing nose cascade name = par s e r . get<Str ing >(” nose cascade ” ) ;i f ( ! nose cascade name . empty ( ) ){

searchNose = true ;i f ( ! noseCascade . load ( nose cascade name ) ){

c e r r <<”ERROR: :CASCADE: : FAILURE LOADING NOSE CASCADE FILE”<< endl ;return 1 ;

}}

// Open video streamSt r ing camera input = par s e r . get<Str ing >(”camera” ) ;S t r ing v ideo input = par s e r . get<Str ing >(” v ideo ” ) ;i f ( ! v ideo input . empty ( ) ){ // Open video f i l e

const St r ing name = v ideo input ;capture . open (name ) ;

} else i f ( camera input . s i z e ( ) == 1) // Open s p e c i f i c cameracapture . open ( s t o i ( camera input ) ) ;

else // Open d e f a u l t system cameracapture . open ( 0 ) ;

63

i f ( ! capture . isOpened ( ) ){c e r r << ”ERROR: :VIDEO : : FAILURE OPENING VIDEO STREAM INPUT” << endl ;return 1 ;

}

// Open video output streamSt r ing dest = par s e r . get<Str ing >(”out” ) ;i f ( ! des t . empty ( ) ){

writeVideo = true ;const s t r i n g name = dest + ” . av i ” ;int codec = VideoWriter : : f ou r c c ( ’X ’ , ’V ’ , ’ I ’ , ’D ’ ) ; // mp4 encoding// Get input v ideo stream in foint srcFrameWidth , srcFrameHeight , s r c f p s ;srcFrameWidth = static cast<int>( capture . get (CAP PROP FRAMEWIDTH) ) ;srcFrameHeight = static cast<int>( capture . get (CAP PROP FRAME HEIGHT) ) ;s r c f p s = static cast<int>( capture . get (CAP PROP FPS ) ) ;outputVideo . open (name , codec , s r c f p s ,

S i z e ( srcFrameWidth , srcFrameHeight ) , true ) ;i f ( ! outputVideo . isOpened ( ) ){

c e r r <<”ERROR:VIDEO : : FAILURE OPENING VIDEO STREAM OUTPUT”<< endl ;return 1 ;

}}

// FLAGS// Color output formati f ( pa r s e r . has ( ” gray” ) )

gray = true ;// Write nose l o c a t i oni f ( pa r s e r . has ( ” no s e l o c a t i o n ” ) )

noseLoc = true ;// Write eyes l o c a t i oni f ( pa r s e r . has ( ” e y e s l o c a t i o n ” ) )

eyesLoc = true ;// Open output f i l ei f ( pa r s e r . has ( ” proc t ime ” ) ){

i f ( ! v ideo input . empty ( ) ){const s t r i n g name = v ideo input . subs t r (0 , v ideo input . s i z e ()−4)\

+ ”proct ime ” ;p r o c t im e f i l e . open (name , i o s : : t runc ) ;

} elsep r o c t im e f i l e . open ( ”camproctime” , i o s : : t runc ) ;

}

return 0 ;}

// Print execu t ion s t a t i s t i c s through t s t dou tvoid p r i n tEx e c S t a t i s t i c s ( s i z e t nFrames , in t64 process ingTime , in t64 ∗ t0 ){

const int N = 30 ;in t64 t1 = cv : : getTickCount ( ) ;cout << ”Frames captured : ” <<format ( ” %5l l d ” , static cast<long long int>(nFrames ) )<< ” Average FPS : ” <<format ( ” %9.1 f ” ,

static cast<double>(getTickFrequency ( ) ) ∗ N / ( t1 − ∗ t0 ) )<< ” Average time per frame : ” <<format ( ” %9.2 f ms” ,

64

static cast<double>(t1 − ∗ t0 ) ∗ 1000 .0 f / (N∗ getTickFrequency ( ) ) )<< ” Proce s s ing time : ” <<format ( ” %9.2 f ms” ,

static cast<double>(process ingTime ) ∗ 1000 .0 f /getTickFrequency ( ) )

<< endl ;∗ t0 = t1 ;

}

// Search fo r faces , eyes and noses and draw t h e i r l o c a t i onvoid trackAndDraw (Mat frame ){

// Convert the frame to g ray s ca l eMat grayFrame ;cvtColor ( frame , grayFrame , COLORBGR2GRAY) ;c lahe−>apply ( grayFrame , grayFrame ) ;

// Set the output frame as gray tooi f ( gray )

cvtColor ( grayFrame , frame , COLORGRAY2BGR) ;

// Detect f a c e s on the frame and draw t h e i r l o c a t i onvector<Rect> f a ce s , eyes , noses ;Rect ROINose , ROIEyes ;faceCascade . de t e c tMu l t i S ca l e ( grayFrame , f ace s , 1 . 2 , 2 , 0 , S i z e (100 , 150) ,

S i z e (300 , 4 5 0 ) ) ;for ( s i z e t i = 0 ; i < f a c e s . s i z e ( ) ; i++){

r e c t ang l e ( frame , f a c e s [ i ] , S ca l a r (255 , 0 , 0 ) ) ;

// Use a 3/4 frame s i z e as Region Of I n t e r e s t to search the nosei f ( searchNose ){

ROINose = Rect ( Point ( f a c e s [ i ] . x+f a c e s [ i ] . width ∗0 . 2 ,f a c e s [ i ] . y+f a c e s [ i ] . he ight ∗0 . 35 ) ,S i z e ( f a c e s [ i ] . width ∗0 . 6 , f a c e s [ i ] . he ight ∗ 0 . 5 ) ) ;

r e c t ang l e ( frame , ROINose , Sca l a r (0 , 0 , 2 5 5 ) ) ;Mat frameROI = grayFrame (ROINose ) ;

noseCascade . de t e c tMu l t i S ca l e ( frameROI , noses , 1 . 1 , 2 , 0 ,S i z e (20 , 15) , S i z e (90 , 8 0 ) ) ;

for ( s i z e t j = 0 ; j < noses . s i z e ( ) ; j++){// Use the ROINose as re f e r ence f o r l o c a t i on and dimensionPoint p1 (ROINose . x + noses [ j ] . x , ROINose . y + noses [ j ] . y ) ;Point p2 (ROINose . x + noses [ j ] . x + noses [ j ] . width ,

ROINose . y + noses [ j ] . y + noses [ j ] . he ight ) ;r e c t ang l e ( frame , p1 , p2 , Sca l a r (0 , 255 , 0 ) ) ;

}// fo r}// i f

// Same as nose f o r eyesi f ( searchEyes ){

ROIEyes = Rect ( Point ( f a c e s [ i ] . x , f a c e s [ i ] . y ) ,S i z e ( f a c e s [ i ] . width , f a c e s [ i ] . he ight / 1 . 7 ) ) ;

r e c t ang l e ( frame , ROIEyes , Sca l a r (0 , 125 , 1 2 5 ) ) ;Mat frameROI = grayFrame (ROIEyes ) ;

eyesCascade . de t e c tMu l t iS ca l e ( frameROI , eyes , 1 . 075 , 1 , 0 ,S i z e (25 , 10) , S i z e (70 , 5 0 ) ) ;

for ( s i z e t j = 0 ; j < eyes . s i z e ( ) ; j++){Point p1 (ROIEyes . x + eyes [ j ] . x , ROIEyes . y + eyes [ j ] . y ) ;Point p2 (ROIEyes . x + eyes [ j ] . x + eyes [ j ] . width ,

ROIEyes . y + eyes [ j ] . y + eyes [ j ] . he ight ) ;r e c t ang l e ( frame , p1 , p2 , Sca l a r (125 , 125 , 0 ) ) ;

65

}// fo r}// i f

}// fo r

// Write f e a t u r e s l o c a t i on s to s tdou t i f d e t e c t edi f ( noseLoc | | eyesLoc ){

i f ( eyesLoc ){i f ( eyes . s i z e ( ) >= 1){

short x = ( (ROIEyes . x + eyes [ 0 ] . x ) ∗ 2 + eyes [ 0 ] . width ) / 2 ;short y = ( (ROIEyes . y + eyes [ 0 ] . y ) ∗ 2 + eyes [ 0 ] . he ight ) / 2 ;cout << x << ” , ” << y ;i f ( eyes . s i z e ( ) >= 2){

x = ( (ROIEyes . x + eyes [ 1 ] . x )∗2 + eyes [ 1 ] . width ) / 2 ;y = ( (ROIEyes . y + eyes [ 1 ] . y )∗2 + eyes [ 1 ] . he ight ) / 2 ;cout << ” , ” << x << ” , ” << y ;

}} else

cout << ”−1, −1, −1, −1” ;}i f ( noseLoc && eyesLoc )

cout << ” , ” ;i f ( noseLoc ){

i f ( ! noses . empty ( ) ){short x = ( (ROINose . x + noses [ 0 ] . x ) ∗ 2 + noses [ 0 ] . width ) / 2 ;short y = ( (ROINose . y + noses [ 0 ] . y ) ∗ 2 + noses [ 0 ] . he ight ) / 2 ;cout << x << ” , ” << y ;

} elsecout << ”−1, −1” ;

}

cout << endl ;}

}

66

11. Referencias

[1] Global unit sales of video game consoles. Statista. Febrero 2019.www.statista.com/statistics/276768/global-unit-sales-

of-video-game-consoles

[2] AR & VR headset sales to rocket driven by enterprise, finds IDC. TechHQ.Anil Prabha. Abril 2019.www.techhq.com/2019/04/ar-vr-headset-sales-to-rocket-

driven-by-enterprise-finds-idc

[3] Headtracking para simuladores y videojuegos, anteproyecto de trabajo defin de grado. Leonardo Niels Pardi. Marzo de 2019.

[4] Soluciones comerciales disponibles de ejemplo:Trackhat: www.trackhat.org/TrackIR: www.www.naturalpoint.com/trackir/DelanClip: www.delanengineering.com/

[5] Matto Godoy. Head tracker para videojuegos,www.matto.io/head-tracker/

[6] Smartphone headtracking with Opentrack.www.github.com/opentrack/opentrack/wiki/Smartphone-Headtracking

[7] aruco proyecto github. Pablo del Campo. Septiembre de 2012.www.github.com/pablodelcampo/aruco

[8] Opentrack. Community driven open source project.www.github.com/opentrack/opentrack

[9] Freetrack.www.free-track.net/

[10] Opencv library. Julio de 2012.www.opencv.org/

[11] Sitio web FaceTrackNoIR. Proyecto iniciado por v4friend. 24 de Mayode 2010.www.facetracknoir.sourceforge.net

[12] Sitio web FacetrackNoIR, seccion faceAPI.www.facetracknoir.sourceforge.net/Trackers/faceAPI.htm

67

[13] Librerıa ccv. Proyecto iniciado por LiuLiu. Enero de 2010.www.libccv.org

[14] Librerıa dlib. Proyecto iniciado por Davis E. King. Abril de 2008.www.dlib.net

[15] Simple FaceTracker. Aproximacion sencilla por Haarcascades. Reposito-rio GitHub. Leonardo Niels Pardi. Mayo 2019.www.github.com/Leoniels/sft.git

[16] Robust Real-Time Face Detection. Paul Viola y Michael J. Jones. Sep-tiembre de 2001.

[17] An extended set of haar-like features for rapid object detection. RainerLienhart and Jochen Maydt. 2002.

[18] On Real-Time Face Detection in Video Streams. An OpportunisticAprpoach. Modesto Fernando Castrillon Santana. Universidad de Las Pal-mas de Gran Canaria. Julio de 2003.

[19] Mastering OpenCV 3 - Second Edition. Daniel Lelis Baggio, ShervinEmami, David Millan Escriva, Khvedchenia Ievgen, Jason Saragih y RoyShilkrot. Packt Publishing. Abril de 2017.

[20] Mastering OpenCV3 - Second Edition github project. Daniel LelisBaggio, Shervin Emami, David Millan Escriva, Khvedchenia Ievgen,Jason Saragih y Roy Shilkrot. Packt Publishing. Abril de 2017.www.github.com/PacktPublishing/Mastering-OpenCV3-Second-Edition.git

[21] Tweaked Saragih’s Facetracker. Facetracker de Jason Saragih modifica-do. Repositorio GitHub. Leonardo Niels Pardi. Junio 2019.www.github.com/Leoniels/twesaft.git

[22] Active Shape Models - Their Training and Application. T. F. Cootes, C.J. Taylor, G. H. Cooper y J. Graham. Department of Medical Biophysics,University of Manchester. Abril de 1994

[23] Snakes: Active contour models. Michael Kass, Andrew Witkin y DemetriTerzopoulos. International Journal of Computer Vision. 1998.

[24] The MUCT Landmarked Face Database. S. Milborrow, J. Morkel y F.Nicolls. Pattern Recognition Association of South Africa. 2010.www.milbo.org/muct

68

[25] Robot seguidor de lıneas (Comparativa entre P.I.D. y Fuzzy Logic). Bea-triz Asensio de Leon, Alejandro Mendez Fernandez, Pablo Mesas Lafargay Leonardo Niels Pardi. Robotica, en la Escuela Tecnica Superior de In-genierıa de Sistemas Informaticos, Universidad Politecnica de Madrid. Di-ciembre de 2018.

[26] Active Appearance Models. T. Cootes, G. J. Edwards y C. J. Taylor.1998.

[27] POSIT tutorial, pose estimation. Javir Barandiran. OpenCV Githubproject.www.github.com/opencv/opencv/wiki/Posit

[28] FBI, ICE find state driver’s license photos are a gold mine for facial-recognition searches. Drew Harwell. The Washington Post. Julio de 2019www.washingtonpost.com/technology/2019/07/07/fbi-ice

-find-state-drivers-license-photos-are-gold-mine-

facial-recognition-searches/

[29] Why Can’t This Soap Dispenser Identify Dark Skin? Sidnew Fussell.GIZMODOO. Agosto de 2017.www.gizmodo.com/why-cant-this-soap-dispenser-identify-

dark-skin-1797931773

69