Embed Size (px)
Citation preview
FACULTAD DE INFORMATICAUNIVERSIDAD POLITECNICA DE MADRID
TESIS DE MASTER
MASTER UNIVERSITARIO EN INTELIGENCIA ARTIFICIAL
PROTOTIPO DE MOTOR DE REALIDAD AUMENTADATRIDIMENSIONAL PARA DISPOSITIVOS MOVILES
AUTOR: Xoan Iago Suarez CanosaTUTOR: Luis Baumela Molina
Madrid, 19 de julio de 2016
II
Resumen
La Realidad Aumentada es la tecnologıa que nos permite superponer elementos graficos sobre elmundo real. Para que esta pueda funcionar adecuadamente es necesario conocer con precision cuales la posicion de la camara desde la que vemos el mundo y como se conforman las imagenesque nos muestra. En este trabajo mostramos como calcular la posicion de la camara a partir dediferentes marcas tanto naturales como artificiales, vemos cual es la mejor forma de proyectar sobreestas marcas mediante el estudio del error de calibracion, disenamos un modo de obtener la matrizde intrınsecos a partir de los parametros fısicos de la camara (distancia focal y angulos de vision),elaboramos un modelo de proyeccion que permita emplear la matriz de intrınsecos para obtener lamatriz de proyeccion de OpenGL y por ultimo proyectamos una figura en tres dimensiones (3D)sobre el patron. Este patron sera un tipo especial de letreros que detectamos empleando una tecnicade seguimiento en el espacio de color.
III
IV
Agradecimientos
Gracias a todo el laboratorio Percepcion Computacional y Robotica por su constante ayuda,sin ellos este trabajo no habrıa sido posible.
A mi familia y amigos por su carino y apoyo.
“Podemos ver poco del futuro, pero lo suficiente para darnos cuenta de que todavıa queda muchoque hacer”. Alan Turing
V
VI
Indice general
1. Introduccion 1
1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Organizacion del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Trabajos previos 5
2.1. Calibracion de la camara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Localizacion de planos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Metodos basados en texturas . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Metodos basados en caracterısticas . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Metodos basados en marcadores . . . . . . . . . . . . . . . . . . . . . . . 8
3. Estudio de Calibracion 9
3.1. Calibracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Calibracion usando parametros fısicos de la camara del movil . . . . . . . . . . . . 12
3.3. Algoritmo de calibracion para Android . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Obtencion de la Matriz de Proyeccion en OpenGL . . . . . . . . . . . . . . . . . . 15
3.5. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.1. Error de Reproyeccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VII
3.5.2. Visualizacion de la proyeccion de OpenGL . . . . . . . . . . . . . . . . . 18
4. Busqueda de Letreros 23
4.1. Paso a escala de grises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Deteccion de contornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Seleccion de contornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4. Rectificar el letrero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Conclusiones 35
5.1. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A. Consideraciones de Diseno y Arquitectura Software 37
A.1. Seleccion de plataforma y lenguaje de implementacion . . . . . . . . . . . . . . . 37
A.2. Arquitectura Software Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. Organizacion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.2. Aplicacion Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.3. Diseno Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.4. Sobre la elaboracion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Bibliografıa 45
VIII
Indice de figuras
1.1. Ejemplos de aplicaciones de Realidad Aumentada . . . . . . . . . . . . . . . . . . 1
1.2. Esquema de una aplicacion de Realidad Aumentada . . . . . . . . . . . . . . . . . 2
2.1. Flujo de trabajo en los metodos basados en caracterısticas . . . . . . . . . . . . . . 8
2.2. Ejemplos de marcadores de Realidad Aumentada . . . . . . . . . . . . . . . . . . 8
3.1. Modelo de camara Pinhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Parametros proporcionados por la API de Android . . . . . . . . . . . . . . . . . . 13
3.3. Calculos para la obtencion del tamano del sensor . . . . . . . . . . . . . . . . . . 13
3.4. Transformaciones aplicadas por OpenGL . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Transformacion del Frustrum de Opengl a “Clip Coordinates” . . . . . . . . . . . 16
3.6. Esquinas de un tablero de ajedrez reproyectadas con distintas distancias focales . . 19
3.7. Graficas del error de reproyeccion frente a la desviacion en la estimacion de la focal 20
3.8. Proyeccion mediante la matriz P de vision (columna derecha) VS proyeccion deOpenGL (columna izquierda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Ejemplo de letrero estetico a detectar . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Proyeccion es el espacio RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Diferencia en la conversion a escala de grises entre un letrero con colores bienseleccionados y mal seleccionados . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4. Diferentes binarizaciones empleando el filtro de Canny y distintos niveles de um-bralizacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IX
4.5. Seleccion de contornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. Ordenacion de las esquinas segun su angulo con el centro de gravedad del cuadrilatero 30
4.7. Captura de pantalla que muestra el rectificado del letrero . . . . . . . . . . . . . . 31
4.8. Experimentos de la deteccion de letreros . . . . . . . . . . . . . . . . . . . . . . . 33
4.9. Secuencia de vıdeo grabada para los experimentos. Fila 1 y 3 imagenes originales,filas 2 y 4 imagenes en RA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.1. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. Arquitectura de la aplicacion Android . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3. Diseno del paquete ar de la librerıa nativa . . . . . . . . . . . . . . . . . . . . . . 41
A.4. Diseno del paquete calib de la librerıa nativa . . . . . . . . . . . . . . . . . . . . . 42
X
Capıtulo 1
Introduccion
La Realidad Aumentada (RA) es la tecnologıa que permite ver imagenes o vıdeos del mundo realen los que se han insertado objetos graficos generados por ordenador [3]. Al comienzo una delas ventajas de la RA frente a la realidad virtual, que recrea la totalidad del mundo alrededor delusuario, era el menor coste computacional ya que “habıa que pintar menos pıxeles” [3], pero conla experiencia se ha visto que este campo encierra importantes dificultades, siendo las principalesaquellas relacionadas con la Vision por Computador (VC).
La esencia de la RA consiste en pintar objetos graficos sobre la imagen de tal manera que aparezcanintegrados en la escena capturada por la camara, el contenido de la capa virtual puede ser muyvariado, desde las indicaciones para llegar a un lugar determinado hasta animaciones completas entres dimensiones que se muevan y reaccionen como si estuviesen en el mundo real.
Ejemplos de aplicaciones exitosas que empleen realidad aumentada pueden ser por ejemplo laaplicacion de IKEA para ver cual serıa el aspecto de un determinado mueble situado en una habita-cion, la aplicacion de aero3Dpro para ver modelos 3D sobre las paginas de una revista o la recientePokemon Go que convierte el clasico juego en una actividad interactiva en el que el usuario debesalir a la calle para poder capturar Pokemons. El aspecto de estas aplicaciones es el que mostramosen la figura 1.1.
(a) App. Ikea (b) App. aero3Dpro (c) Pokemon GO
Figura 1.1: Ejemplos de aplicaciones de Realidad Aumentada
1
Capıtulo 1
1.1. Objetivo
Nuestro objetivo es desarrollar una aplicacion para realizar Realidad Aumentada en dispositivosmoviles que detecte letreros sobre los que se mostraran diversos modelos 3D y posiblemente algunaanimacion. Esta aplicacion se basara en tecnicas de vision por computador para reconocer la escenaque rodea al dispositivo, en concreto, se detectara un patron en el letrero y en base a el se estimara laposicion del dispositivo. Una vez conocida la posicion del dispositivo la aplicacion debe mostrar losobjetos graficos virtuales de forma que se integren en la escena percibida por la camara. Ilustramoseste proceso en la imagen 1.2.
Figura 1.2: Esquema de una aplicacion de Realidad Aumentada
1.2. Problemas
A la hora de desarrollar este tipo de aplicacion nos encontramos con dos problemas importantes.El primero consiste en que para poder proyectar un objeto tridimensional sobre la imagen de unacamara es necesario conocer las propiedades de este sistema proyectivo. Esto suele resolversemediante un procedimiento de calibracion tedioso para un usuario movil y que puede devolvervalores erroneos si la calibracion no se realiza adecuadamente.
2
Introduccion
Otro problema es la deteccion de objetos sin textura, es decir cuyo color en su superficie esplano ya que los metodos tradicionales que explicaremos en el capıtulo siguiente no son capacesde identificarlos eficientemente.
1.3. Contribuciones
Para solventar el primero de los problemas planteamos un metodo de calibracion automaticaque hace uso de los parametros fısicos de la camara para modelar un sistema proyectivo, con elloseremos capaces de comprender como se muestran los objetos del mundo en las imagenes y portanto podremos proyectar objetos virtuales que no se encuentran en la escena.
Como solucion al segundo problema proponemos un algoritmo de deteccion que es capaz deencontrar los letreros marcados con una lınea (ver figura 4.1) mediante una busqueda en el espaciode color combinada con una seleccion basada en las propiedades geometricas del letrero.
1.4. Organizacion del documento
Este documento se estructura de la siguiente manera: En el capıtulo 2 revisaremos el estado del artey haremos un resumen de las tecnicas mas habituales a la hora de construir sistemas de RealidadAumentada. En el capıtulo 3 describiremos el procedimiento de calibracion automatica a partirde los parametros extrınsecos y proporcionaremos una implementacion para dispositivos Androiden C++. En el capıtulo 4 explicaremos como funciona el metodo de deteccion basada en color ypor ultimo en el capıtulo 5 revisaremos las conclusiones mas importantes de este trabajo ası comodaremos unas indicaciones sobre las lıneas futuras a seguir. En el apendice encontraremos todaslas consideraciones de diseno y arquitectura software que se han tenido en cuenta a la hora deimplementar el sistema.
3
4
Capıtulo 2
Trabajos previos
Desde los anos noventa el interes de la realidad aumentada ha ido incrementandose poco a po-co, pero es a partir del ano 2009, cuando la constante mejora en la capacidad de computo de losdispositivos moviles, la disponibilidad de sistemas de computacion basados en las unidades deprocesamiento grafico y en la nube y, sobre todo, las expectativas comerciales que despierta estatecnologıa hacen que se produzca el gran salto en el mundo de la RA. En 2009 Qualcomm adquieretecnologıa de RA de la universidad de Gratz, que sera el embrion del paquete QCAR lanzado en2011, actualmente conocido como Vuforia. Coincidiendo en el tiempo Microsoft lanza el proyectoNatal, que mas tarde dara lugar a la Kinect. En 2008 Mobilizy y Metaio lanzan tambien sendosproductos comerciales, de los cuales el mas destacado es Wikitude (www.wikitude.com), una apli-cacion que combina datos de la brujula y el GPS del movil con informacion de la Wikipedia paraconstruir un navegador basado en RA. Un ano mas tarde SPX Mobile lanza Layar (www.layar.com)otro producto basado en los mismos sensores que Wikitude, pero con mas capas de informacion.
En el campo de la investigacion los aportes han sido constantes. En las siguientes secciones revi-saremos los trabajos previos en los dos problemas que nos atanen: La calibracion de la camara y ladeteccion de planos.
2.1. Calibracion de la camara
En Vision por Computador, el proceso de conocer como los objetos del mundo se proyectan sobrela imagen se conoce como calibracion, donde los parametros que dependen de las caracterısti-cas fısicas y geometricas de la camara conforman una matriz llamada matriz de intrınsecos y laposicion de la camara expresada como una translacion y rotacion desde el origen, la matriz deextrınsecos[8]. La multiplicacion de estas dos matrices se conoce como la Matriz de Proyeccionya que transforma un punto homogeneo de la escena en un punto homogeneo de la imagen. Elmodelo puede afinarse todavıa mas incluyendo otros parametros como pueden ser las distorsionesprovocadas por la lente[22].
Mientras que los extrınsecos varıan segun la perspectiva desde donde se haya tomado la imagen,los intrınsecos que se mantienen constantes para todas las imagenes de una secuencia tomada con
5
Capıtulo 2
la misma camara, siempre y cuando la camara no cambie los parametros del zoom. El flujo detrabajo a la hora de hacer RA consiste normalmente en obtener en primer lugar los intrınsecos yposteriormente empleando la imagen obtenida se calculan los extrınsecos.
La calibracion se puede realizar partiendo de un patron conocido como un tablero de ajedrez[25][11], partiendo de un patron natural conocido o bien partiendo de una suposicion sobre la estructurade la escena que nos permite hacer una estimacion[5]. Una ultima opcion es crear la matriz decalibracion a partir de otros datos fısicos conocidos de la camara, en nuestro caso emplearemos ladistancia focal y los angulos de vision (horizontal y vertical) porque son datos muy comunes quese pueden obtener por ejemplo del API de Android.
2.2. Localizacion de planos
Para poder hacer RA sobre un patron plano nuestro primer objetivo es el de encontrar ese plano enla imagen. Para esto podemos emplear dos tipos de metodos de deteccion.
Para hacer RA es imprescindible estimar la posicion de la camara en el mundo desde la cualveremos los objetos virtuales, este proceso se llama localizacion. Siendo este un problema abierto,en los ultimos anos se han desarrollado multiples algoritmos que permiten reconocer y estimarla posicion relativa de objetos en una imagen de una forma robusta a cambios de iluminacion,orientacion y en presencia de oclusiones parciales.
Todos ellos parten de que conocemos un patron que se encuentra en la escena y que servira comopunto de referencia de nuestro sistema de coordenadas. Para mayor simplicidad se asume queeste patron es plano y por tanto, el primero paso a realizar para localizar nuestra camara es el deencontrar el patron plano en la imagen proveniente de la camara.
2.2.1. Metodos basados en texturas
Para encontrar en una nueva imagen el patron de referencia que previamente hemos aprendido y enbase al cual queremos situar nuestro objeto virtual, los sistemas mas simples buscan la transforma-cion que alinea ese patron con la imagen percibida[10]. Un metodo ampliamente utilizado es el deLucas–Kanade [15] que estima el flujo optico suponiendo que entre dos imagenes consecutivas lasvecindades de un pıxel no varıan. Con esta restriccion el metodo resuelve las ecuaciones basicasdel flujo optico para todos los pıxeles vecinos por el criterio de mınimos cuadrados. La ventaja deeste enfoque es su bajo coste computacional, haciendo que corran a la perfeccion en tiempo realincluso en dispositivos moviles.
2.2.2. Metodos basados en caracterısticas
Dado que los metodos basados en texturas adolecen de problemas de robustez, veremos los meto-dos basados en caracterısticas que solventan buena parte de estos problemas. En los metodos ba-sados en deteccion de caracterısticas (feature-based) procesamos la imagen para encontrar carac-
6
Trabajos previos
terısticas (elementos invariantes de la imagen) en lugar de utilizar directamente la textura de laescena. El algoritmo clasico consiste en:
1. Deteccion de Caracterısticas: La deteccion de caracterısticas consiste en hallar aquellaspartes mas identificables de la imagen, estas pueden ser regiones, aristas o puntos que suelenestar caracterizadas porque el cambio de color o de nivel de gris en ellos es pronunciado.Para detectarlos se pueden emplear metodos basados en el gradiente con un menor costecomputacional como el detector de esquinas de Harris[7] que usa el operador de Sobel, ladiferencia de gaussianas de SIFT[14] o la comparacion de cada pıxel de la imagen con unanillo de pıxeles a su alrededor que vemos en FAST[19].
2. Descripcion de Caracterısticas: Una vez hallados aquellos puntos que caracterizan unaimagen, debemos describirlos a ellos y a la zona que los rodea de modo que puedan com-pararse con otros puntos caracterısticos midiendo cuan parecido es su aspecto. Para ellopodemos emplear un metodo basado en el histograma de la region [14]. Aunque estos meto-dos son robustos, en terminos de memoria y tiempo de calculo son muy costosos si no seposee una implementacion en GPU[24][9] por lo que de cara a su computo en dispositi-vos moviles suscitan un mayor interes el otro tipo de descriptores, los descriptores binarios.BRIEF[23] propone una codificacion binaria, que se genera comparando directamente paresde puntos en las vecindades del punto caracterıstico. La version original se ha mejorado endiversas ocasiones para hacerlo invariante ante la rotacion, el escalado y en menor medida ala iluminacion y la distorsion perspectiva siendo algunos ejemplo de ello descriptores comoORB[20] o BRISK[13] que consiguen una robustez razonable[9].
3. Emparejamiento de Caracterısticas: Una vez que hemos detectado y descrito todos lospuntos caracterısticos de la imagen que estamos recibiendo de la camara lo que debemoshacer ahora para localizar nuestro patron es comparar los descriptores obtenidos con aque-llos que previamente hallamos calculado y almacenado en nuestra base de datos (BD) depatrones. Para esta tarea se suele emplear una medida de distancia que es caracterıstica decada descriptor. La forma mas basica es comparar cada descriptor detectado con todos losaprendidos del patron, esta es la aproximacion basada en fuerza bruta, que es razonable si tansolo disponemos de uno o dos patrones-imagen pero en caso de tener una BD con multiplespatrones esto es completamente prohibitivo. Por este motivo surgen otras alternativas basa-das en tecnicas de Hashing [16] para los descriptores binarios y en tecnicas de Clustering[17] para los descriptores basados numeros de coma flotante, incluso hay algunos trabajosque muestran como emplear tecnicas de Clustering jerarquico tambien sobre descriptoresbinarios[18].
4. Estimacion robusta del Modelo Proyectivo: Sea cual sea el algoritmo de emparejamientoempleado, el resultado sera una asociacion entre cada caracterıstica de la imagen y la carac-terıstica del patron con menor distancia a la que llamaremos correspondencia, como entrelas caracterısticas emparejadas estan tambien aquellas de la imagen que no forman parte delpatron, tenemos una muestra altamente ruidosa por lo que debemos estimar nuestro modelode forma robusta.
El modelo normalmente utilizado es el de buscar una transformacion que nos permita deter-minar la correspondencia entre el plano de la imagen y el plano de la escena que contiene anuestro patron. En funcion de los grados de libertad que deseemos emplear se puede utilizar
7
Capıtulo 2
una transformacion proyectiva como la homografıa que considera la distorsion provocadapor el cambio de perspectiva, o si el plano de la escena esta suficientemente lejos de la cama-ra, podemos modelar su movimiento con una transformacion afın o de similaridad que tienemenos grados de libertad y por tanto es mas facil de estimar.
Para realizar la estimacion modelo, puede emplearse RANSAC [6], un metodo iterativo queen cada iteracion escoge aleatoriamente unas correspondencias con las que hacer la esti-macion. No obstante, como RANSAC es un metodo puramente aleatorio no aprovecha lainformacion de correspondencia que proporcionan los descriptores. Otros algoritmos comoMLSAC[21] o PROSAC[4] aprovechan esto ordenando la busqueda de correspondenciascomenzando por aquellas que tenıan una menor distancia, esto les permite multiplicar hastapor 100 el rendimiento frente a RANSAC.
Figura 2.1: Flujo de trabajo en los metodos basados en caracterısticas
2.2.3. Metodos basados en marcadores
Otro metodo ampliamente utilizado y alternativo a los metodos basados en caracterısticos es ladeteccion basada en marcas. En este caso el patron tiene una forma muy especıfica como la quepodemos observar en la figura 2.2. Estas formas se detectan mediante el umbralizado de la imageny el conocimiento que se tiene de su forma geometrica, ver [1, Capıtulo 2].
(a) Marca de tipo QR (b) Marca del frame-work ARUCO
(c) Marca empleadaopr el frameworkARToolKit
Figura 2.2: Ejemplos de marcadores de Realidad Aumentada
8
Capıtulo 3
Estudio de Calibracion
En este capıtulo mostraremos como se pueden proyectar modelos tridimensionales superpuestos ala imagen que percibimos de la camara de un dispositivo movil. Esto no es posible simplemente conel uso de las transformaciones que citamos en el capıtulo anterior (homografıa y transformacionafın), ya que solo definen la equivalencia entre los puntos del patron detectado y de la imagen. Estohace que con ellas solo sea posible pintar objetos virtuales que esten contenidos en el propio planodel patron.
El flujo de trabajo para poder llevar la RA a las tres dimensiones es, en primer lugar definir cualsera el sistema de referencia de nuestro mundo virtual 3D. Por ejemplo asignando un punto entres dimensiones a cada una de las cuatro esquinas de nuestro patron (suponiendo que sea uncuadrilatero) donde la coordenada Z de estos puntos sea 0, ya que ası el plano de nuestra etiquetasera el plano Z=0.
En segundo lugar se ha de plantear un modelo de proyeccion como el que explicaremos en laprimera seccion de este capıtulo. En concreto nuestro modelo consta de dos tipos de parametros, losintrınsecos que determinan propiedades fısicas de la camara y los extrınsecos que hacen referenciaa la posicion de la camara en la escena.
Una vez planteado el modelo proyectivo hay que estimar sus parametros. Nosotros estimamos losintrınsecos gracias a la informacion fısica de la camara que nos proveen APIs como la de Android,los extrınsecos los hallaremos a partir del patron detectado en en la imagen percibida. El modo decalcular los extrınsecos a partir del patron es planteando un problema Perspective-n-Point[12] quedebe encontrar la posicion de la camara desde la cual los puntos del patron se proyectarıan sobrelos puntos de la imagen que hemos detectado.
La siguiente accion en el flujo de trabajo es la de definir la proyeccion del sistema grafico virtualde manera equivalente al modelo de poyeccion que hemos estimado. Haciendo esto conseguimosque el modelo 3D virtual se proyecte sobre la imagen como lo harıa si estuviese presente en laescena. En la segunda seccion de este capıtulo mostraremos como hacer esto empleando el sistemagrafico OpenGL.
9
Capıtulo 3
3.1. Calibracion
La calibracion es el proceso mediante el cual se estiman los parametros internos de la camara quedependen de sus propiedades fısicas, los parametros intrınsecos. Este proceso es imprescindiblepara poder hacer realidad Aumentada, ya que sin ellos no podemos despejar los otros parametros(extrınsecos) de nuestro sistema proyectivo.
Este proceso puede ser tedioso y complejo para el usuario de un dispositivo movil, ademas las “Ap-plication Programming Interface” (APIs) de los dispositivos no suelen proveer estos parametros,en Android solo esta disponible para algunos dispositivos a partir de la version 6.0 (Octubre del2015). Por lo que en esta seccion mostraremos un modo automatico de solucionar este problemabasandonos en los parametros fısicos que sı acostumbran a proporcionar estas APIs.
Las camaras observan el mundo tridimensional a su alrededor, proyectando este mundo sobre unaimagen plana. En este trabajo contemplaremos un modelo Pinhole en el que asumimos que elsensor se encuentra situado delante del centro optico de la camara distando de el una distancia quellamaremos distancia focal (f).
Para comprender el modelo de proyeccion comenzaremos por el caso mas sencillo, supongamosque el centro de proyeccion es tambien el centro de coordenadas de un espacio euclıdeo. En elmodelo Pinhole un punto del espacio X = (x, y, z)T se proyectara sobre el punto donde la lıneaque va de X al centro corta el plano imagen. Por la similitud de triangulos de la figura 3.1, podemosve que el punto (x, y, z)T de la escena se proyecta al punto (fx/z, fy/z, z)T que esta contenidoen el plano imagen.
Figura 3.1: Modelo de camara Pinhole
Esta forma de proyectar hace que el punto (0,0) este situado en el centro de la imagen, donde el ejeZ atraviesa el plano imagen. Para generalizar esto a un caso en el que el centro de coordenadas de laimagen no este centrado, se introduce un desplazamiento de modo que ahora el punto (x, y, z)T seproyecta a (fx/z+px, fy/z+py, z)
T , donde (px, py)T son las coordenadas del punto principal (elcentro de la imagen). Esta expresion tambien puede expresarse empleando coordenadas homogenea
10
Estudio de Calibracion
del siguiente modo:
XYZ1
7→ fX + Zpx
fY + ZpyZ
=
f px 0f py 0
1 0
·XYZ1
. (3.1)
Este modelo proyecta un punto de la escena sobre el plano imagen, pero el sistema de referenciaen las que se expresa el punto de la imagen son las mismas coordenadas euclıdeas de la escenacuando lo usual es que la unidades de la imagen sean los pıxeles capturados por el sensor. Para queesto sea ası lo que hemos de hacer es expresar las medidas del sistema proyectivo en pıxeles. Paraello definiremos la focal en pıxeles α = fku y β = fkv donde (1/ku, 1/kv) son las dimensionesdel pıxel en unidades de la escena y el punto principal (i0, j0) tambien en pıxeles. Si obviamos laultima columna de ceros, tenemos la matriz K tambien llamada matriz de intrınsecos[8]:
K =
fku s i00 fkv j00 0 1
=
α s i00 β j00 0 1
(3.2)
La s representara el sesgo de la camara, que usualmente vale 0.
En general los puntos del espacio se representaran en un sistema de coordenadas distinto quellamaremos sistema de coordenadas de la escena o del mundo. Los dos sistemas de coordenadas serelacionan entre sı a traves de una rotacion y una traslacion. De modo que si Xmundo es un vectorcartesiano que representa las coordenadas de un punto en el sistema de referencia del mundo,nosotros podemos calcular su punto equivalente en el sistema de referencia de la camara como:Xcamara = R(Xmundo − C), donde C representa la posicion de la camara en coordenadas de laescena y R es una matriz de rotacion de tamano 3x3 que representa la orientacion de la camararespecto a los ejes de coordenadas del mundo.
Si expresamos esto mediante de coordenadas homogeneas podemos construir un sistema proyecti-vo de la forma:
P3x4 = K3x3[R3x3|t3x1] (3.3)
El parametro t = −RC es decir el centro de la escena expresado en coordenadas de la imagen.A la matriz resultante P se le llama matriz de proyeccion mientras que a [R|t] se la conoce comomatriz de extrınsecos.
11
Capıtulo 3
3.2. Calibracion usando parametros fısicos de la camara del movil
Nosotros deseamos por tanto obtener todos estos parametros para proyectar nuestros modelos 3Dartificiales como si existiesen en el mundo real. Impondremos las siguientes restricciones:
El valor del sesgo es 0.
El punto principal esta centrado en la imagen.
No existe distorsion optica.
Imponiendo estas restricciones vemos que los unicos parametros que quedan por resolver son fkuy fkv que se interpretan como la distancia focal expresada en pıxeles. Para encontrar estos parame-tros y obtener por tanto la matriz deseada vamos a echar mano de tres de las propiedades fısicas dela camara mas conocidas y que suelen estar disponibles en todas las APIs moviles.
La Distancia Focal (f), que se mide en mm.
Angulo de vision horizontal (Θx), medido en grados.
Angulo de vision vertical (Θy), medido en grados.
Ademas de estos parametros fısicos emplearemos tambien el numero de pıxeles de la imagen,donde wpix sera el ancho en pıxeles y width en milımetros, del mismo modo hpix sera el alto enpıxeles y height en milımetros. La representacion grafica de esos valores puede verse en la figura:3.2.
Como la focal de la camara en milımetros podemos obtenerla de forma directa llamando a lasfunciones de las APIs, lo que necesitamos es el tamano del sensor (el plano imagen) para poder ex-presar esta focal en funcion del tamano de cada pıxel. Estas operaciones se realizan en los calculosde la figura 3.3.
De forma analoga a como hemos calculado el ancho del sensor puede calcularse su alto, de modoque ya podemos calcular los parametros de la matriz de intrınsecos como:
f · ku =f
2f ·tan(Θx/2)wpix
=wpix
2 tan(Θx/2); f · kv =
f2f ·tan(Θy/2)
hpix
=hpix
2 tan(Θy/2)
12
Estudio de Calibracion
Figura 3.2: Parametros proporcionados por la API de Android
Figura 3.3: Calculos para la obtencion del tamano del sensor
13
Capıtulo 3
3.3. Algoritmo de calibracion para Android
En el Sistema Operativo (SO) Android, los parametro fısicos (Θx,Θy, f ) que hemos empleadoanteriormente para calcular la matriz de proyeccion pueden obtenerse de modo directo a traves dela clase Camera.Parameters que dispone de las siguientes funciones:
float getFocalLength ()float getVerticalViewAngle ()float getHorizontalViewAngle ()
Como parte de nuestro sistema hemos creado una clase CameraCalibration que recubre a la matrizde intrınsecos y que puede construirse empleando los tres parametros devueltos por el API deAndroid:
Listado 3.1: Codigo C++ para el calculo de la matriz de intrınsecos
C a m e r a C a l i b r a t i o n : : C a m e r a C a l i b r a t i o n (f l o a t f ,f l o a t h o r i z o n t a l A n g l e ,f l o a t v e r t i c a l A n g l e ,cv : : S i z e i m g S i z e ) :
m imgSize ( i m g S i z e ){
/ / m i n t r i n s i c i s a f i e l d o f t y p e cv : Matx33fm i n t r i n s i c = cv : : Matx33f : : z e r o s ( ) ;
f l o a t s e n s o r s i z e x =2 ∗ f ∗ t a n ( t o R a d i a n s ( h o r i z o n t a l A n g l e / 2 ) ) ;
f l o a t s e n s o r s i z e y =2 ∗ f ∗ t a n ( t o R a d i a n s ( v e r t i c a l A n g l e / 2 ) ) ;
f l o a t p i x e l s i z e x = s e n s o r s i z e x / m imgSize . wid th ;f l o a t p i x e l s i z e y = s e n s o r s i z e y / m imgSize . h e i g h t ;
m i n t r i n s i c ( 0 , 0 ) = f / p i x e l s i z e x ;m i n t r i n s i c ( 0 , 2 ) = m imgSize . wid th / 2 ;m i n t r i n s i c ( 1 , 1 ) = f / p i x e l s i z e y ;m i n t r i n s i c ( 1 , 2 ) = m imgSize . h e i g h t / 2 ;m i n t r i n s i c ( 2 , 2 ) = 1 ;
}
14
Estudio de Calibracion
3.4. Obtencion de la Matriz de Proyeccion en OpenGL
OpenGL es el estandar mas extendido para la renderizacion de graficos, siendo soportado en lagran mayorıa de dispositivos tanto moviles como de escritorio. En OpenGL estan basados tambiengran parte de los motores de videojuegos que permiten el desarrollo de animaciones mucho mascomplejas como Unity y Unreal, es por ello que lo escogemos para implementar nuestros sistemasgraficos de modo que en el caso de que sean migrados en un futuro a alguno de estos motores, laadaptacion sea lo mas sencilla posible.
En OpenGL, la proyeccion de las coordenadas del modelo tambien se lleva a cabo mediante el usode una matriz de proyeccion, que, no obstante, tiene algunas diferencias con la matriz de intrınsecosde vision, en la presente seccion veremos esas diferencias y mostraremos como expresar la matrizde intrınsecos en forma de una matriz de proyeccion de OpenGL.
OpenGL emplea una serie de transformaciones geometricas para plasmar los distintos objetos dela escena en la imagen final, estos objetos estan compuestos por una serie de primitivas comolıneas, triangulos y vertices. Las transformaciones que se aplican sobre estos objetos pueden de-finirse como matrices que se acumulan multiplicando por el lado derecho de los vertices (post-multiplicando) a lo largo de proceso de transformacion de OpenGL, que vemos en la figura 3.4. Laprimera matriz en post-multiplicar los puntos es la “ModelView Matrix” cuyo objetivo es transfor-mar de las coordenadas de la escena a las coordenadas de la camara.
Figura 3.4: Transformaciones aplicadas por OpenGL
OpenGL supone que el centro de coordenadas de la escena se encuentra situado en el centro de lacamara y por tanto la escena ha de transformarse con la matriz ModelView que podemos obtenera partir de los extrınsecos de vision, donde R era la matriz de rotacion 3x3 que representa laorientacion de la camara en la escena y t el vector que se puede calcular como t = −RC, siendoC la posicion de la camara en la escena.
ModelV iew4x4 =
(RT
3x3 −t3x1
01x3 1
)
El siguiente paso una vez que ya tenemos los objetos expresados en coordenadas de la camaraes proyectarlos a “Clip Coordinates”, que son coordenadas homogeneas cuyos valores estan enel rango [-1, 1]. Para lo que se emplea la ProjectionMatrix, esta matriz debe seguir la definicionque podemos observar en la ecuacion 3.4, donde cada uno de sus parametros es una delimitaciongeometrica que mostramos en 3.5:
15
Capıtulo 3
Figura 3.5: Transformacion del Frustrum de Opengl a “Clip Coordinates”
ProjectionMatrix =
2nr−l 0 r+l
r−l 0
0 2nt−b
t+bt−b 0
0 0 −(f+n)f−n
−2fnf−n
0 0 −1 0
(3.4)
Si comparamos entre lo definido por OpenGL para el Frustrum y la matriz de proyeccion de vision,podemos ver que hay una serie de equivalencias:
r-l: Representa el ancho de la imagen, en vision width.
r+l: Esta suma simboliza es desplazamiento del punto principal en el eje X respecto delpunto principal ideal (width/2), por lo que r + l⇔ i0 − (width/2).
t-b: Representa el alto de la imagen, en vision height.
t+b: Esta suma simboliza es desplazamiento del punto principal en el eje Y respecto delpunto principal ideal (height/2), por lo que t + b ⇔ −(j0 − (height/2)). Incluimos unsigno negativo porque partimos de un eje de coordenadas en vision que comienza en la partesuperior izquierda de la imagen.
n (p11): El elemento ProjectionMatrix11 = 2nr−l tiene como objetivo proyectar un punto
homogeneo de la escena a un punto homogeneo de la imagen expresado en coordenadasrecortadas, en ingles “Clip Coordinates”, cuyos valores estan en el intervalo [-1, 1].
Dado que n es la distancia del centro al plano “near”, podemos interpretar el 2r−l como la
funcion que hace la conversion de pıxeles de la imagen a coordenadas recortadas.
En vision la proyeccion se apoya en la igualdad de triangulos que podemos ver en la figura3.1, donde la focal de la camara cumple un papel analogo al del plano “near” de OpenGL.Teniendo en cuenta que (r - l) es el ancho de la imagen que vendra expresado en pıxeles,la distancia focal ha de expresarse tambien en funcion del ancho de los pıxeles, por lo quepodemos establecer la equivalencia: 2n
r−l ⇔2fkuwidth
16
Estudio de Calibracion
n (p22): De un modo analogo a lo explicado para el eje X, para el elementoProjectionMatrix22 = 2n
t−b , puede establecerse la equivalencia: 2nt−b ⇔
2fkvheight .
Por lo que podemos emplear nuestros intrınsecos para generar la matriz de proyeccion del siguientemodo:
fku 0 i00 fkv j00 0 1
=⇒
−2fkuwidth 0 i0−(width/2)
width 0
0 2fkvheight
j0−(height/2)height 0
0 0 −(far+near)far−near
−2far·nearfar−near
0 0 −1 0
(3.5)
Una vez hemos definido estas dos matrices, OpenGL se encargara de completar automaticamentelos pasos restantes: Transforma de coordenadas homogeneas a cartesianas en [-1, 1] denominadasNormalized Device Coordinates (NDC) y pasar las coordenadas en NDC a coordenadas de laventana, que seran los pıxeles resultantes.
Resumiendo, en la primera seccion hemos visto como obtener a partir del dispositivo los parame-tros intrınsecos de la camara mientras que en la presente seccion se ha mostrado como pasar deestos intrınsecos a la matriz de proyeccion de OpenGL que nos permitira pintar objetos en 3D, enesencia esto es todo lo necesario para saber como hemos de representar nuestra capa de realidadaumentada. La unica cuestion que queda sin resolver es como obtener los parametros extrınsecos,o lo que es lo mismo, en que parte de la imagen debemos pintar nuestros modelos virtuales. Pararesolver este punto veremos en el capıtulo siguiente un metodo para localizar letreros sobre los quehacer RA, pero primero algunos experimentos que contrasten nuestras hipotesis.
3.5. Experimentos
Para poder verificar el correcto funcionamiento de las dos conversiones de parametros anteriormen-te descritas se han disenado dos experimentos, el primero es un estudio del error de reproyeccionproducido al estimar erroneamente la focal de la camara, el segundo de ellos es una compara-cion visual entre la proyeccion realizada con la matriz de proyeccion de OpenCV y la matriz deproyeccion de OpenGL de modo que se pueda comprobar su equivalencia.
3.5.1. Error de Reproyeccion
El error de reproyeccion es el error que se produce cuando aprendemos un modelo proyectivo comola matriz de proyeccion que podemos ver en la formula 3.6 y lo empleamos posteriormente paraproyectar sobre la imagen esos mismos puntos con los que hemos aprendido el modelo.
17
Capıtulo 3
P =
fku 0 i00 fkv j00 0 1
(R3x3|t3x1) (3.6)
Como la estimacion de la focal puede estar sujeta a errores, emplearemos el error de reproyeccionpara medir cuanto influye sobre la proyeccion el emplear un tamano de focal diferente al correcto(el de la camara con la que fue tomada la imagen o secuencia de imagenes). Para esto hemos em-pleado una secuencia de imagenes en la que se ha grabado un patron de calibracion tipo tablero deajedrez, con el se calibrara la camara obteniendo los parametros intrınsecos reales. Posteriormentese modificaran estos valores para ver como se comporta el error de reproyeccion cuando la focaltoma valores desde un 10 por ciento de su tamano real hasta un 200 por ciento.
Los resultados visuales pueden observarse en la figura 3.6, donde observamos que para una focalpequena el efecto visual que se produce es una perdida de paralelismo entre las lıneas que deberıanser paralelas, mientras que para focales mas grandes de lo normal el efecto es un paralelismo cadavez mayor que redunda en una perdida de perspectiva.
Midiendo la diferencia entre cada esquina del tablero y la posicion en la que se ha reproyectado(en pıxeles) podemos calcular el error total de reproyeccion. Esto se ha hecho para las imagenestomadas por un Huawey U8650 de tamano (2048x1563px) y para las imagenes provenientes de unvıdeo tomado por un Motorola Moto X en resolucion (1920x1080px). El resultado puede obser-varse en las graficas 3.7 donde el eje de las abscisas representa la focal empleada en relacion a lafocal real, siendo 10 % una focal diez veces mas pequena que la real y un 200 % una focal con eldoble de tamano. En el eje de ordenadas tenemos el error de reproyeccion medio entre los puntosdel tablero expresado en pıxeles.
En las graficas se puede ver que una pequena desviacion al estimar la focal no tiene un efectovisualmente muy impactante, mientras que si la desviacion crece este error aumenta, especialmentesi la estimacion de la focal es menor de su valor real. Otro efecto importante a destacar de lasgraficas 3.7 es que el error nunca llega a valer 0px, ni tan siquiera cunado se emplea la focal realque se ha calculado mediante el metodo de calibracion. Esto es ası porque el metodo de calibraciontambien sufre de un pequeno error, que como vemos esta en torno a los 0,25 pıxeles por puntoreproyectado. Esto se debe principalmente a que no modelamos la distorsion no lineal.
Para los dos dispositivos citados anteriormente, se ha calculado su matriz de calibracion empleandoel algoritmo 3.1, y se ha visto que comparando estos valores valores con los obtenidos del procesode calibracion, existe una diferencia de un 2’5 % y un 3 % entre ambas medidas. Por lo que pode-mos concluir que el metodo aquı propuesto es valido para la estimacion de los intrınsecos y ademasproduce un error de reproyeccion de aproximadamente 0.30 px dada la curva de la figura 3.7.
3.5.2. Visualizacion de la proyeccion de OpenGL
En este segundo experimento comparamos la proyeccion que realiza la matriz proyectiva 3.6 em-pleando la librerıa de vision OpenCV con la proyeccion de la escena realizada por OpenGL. El
18
Estudio de Calibracion
(a) Reproyeccion con f: 10 % (b) Reproyeccion con f: 30 %
(c) Reproyeccion con f: 50 % (d) Reproyeccion con f: 80 %
(e) Reproyeccion con f: 100 % (f) Reproyeccion con f: 200 %
Figura 3.6: Esquinas de un tablero de ajedrez reproyectadas con distintas distancias focales
19
Capıtulo 3
Figura 3.7: Graficas del error de reproyeccion frente a la desviacion en la estimacion de la focal
objetivo de este experimento es confirmar que las ecuaciones 3.4 y 3.5 son correctas. Para este ex-perimento se emplea como patron una imagen natural impresa, que se ha escaneado previamente.
En la figura 3.8 podemos ver a la derecha la proyeccion de OpenCV en la que se han dibujado lasesquinas detectadas del patron (en rojo) junto con el eje de coordenadas de la escena. A la izquierdavemos la proyeccion de OpenGL donde hemos dibujado los bordes del patron con una lınea azul ysobre el centro de la escena un cubo.
Para que experimento sea exitoso lo que deberıa ocurrir es que el contorno azul de OpenGL paseexactamente por encima de los puntos rojos de la imagen de OpenCV, y por otra parte que el cubodibujado con OpenGL se encuentre centrado en el eje de coordenadas que nos indica OpenCV.Vemos que en los resultados esto efectivamente se cumple.
Para la deteccion del patron en este caso se ha implementado un sistema que emplea un metodobasado en puntos caracterısticos que explicamos en la seccion 2.2.2, en concreto se ha utilizadoel detector y descriptor de ORB[20], el emparejamiento se ha hecho empleando fuerza bruta, y lahomografıa que nos permite establecer la equivalencia entre el plato del patron y el plano imagense ha estimado de forma robusta gracias a PROSAC[4]. Una vez conocida la homografıa se haempleado esta para calcular las cuatro esquinas del patron y en base a ellas con una aproximacionPnP[12] se ha estimado la translacion y rotacion de la camara (parametros extrınsecos).
20
Estudio de Calibracion
Realidad aumentada Pose estimada
Figura 3.8: Proyeccion mediante la matriz P de vision (columna derecha) VS proyeccion deOpenGL (columna izquierda)
21
22
Capıtulo 4
Busqueda de Letreros
En este capıtulo se tratara un problema mas especıfico que el abordado en el capıtulo anterior¿Como encontrar un letrero en una imagen, si sabemos de antemano que este letrero se encuentrarodeado por una lınea y que tiene unos determinados colores?
En nuestro caso concreto deseamos hallar la respuesta a esta pregunta porque queremos crear unmotor de Realidad Aumentada tridimensional que sera la pieza clave de una aplicacion mas grandede reserva de salas. Las salas estaran marcadas con un letrero como el que vemos en la figura 4.1y nuestro objetivo sera detectarlo en la imagen proveniente de la camara, rectificar la imagen paraque sobre el letrero pueda aplicare un algoritmo de reconocimiento de texto y por ultimo permitirque se puedan dibujar objetos 3D sobre el.
Para esta tarea podrıan emplearse marcadores QR, pero son muy poco esteticos y de imposiblecomprension para un humano. En su lugar usaremos letreros como el de la figura 4.1, que tienenun color de fondo y ademas disponen de una lınea que rodea su contorno. El principal problemade estas marcas es que carecen de una textura bien diferenciada, por lo que las aproximacionesclasicas basadas en deteccion de caracterısticas no son validas.
Figura 4.1: Ejemplo de letrero estetico a detectar
En este capıtulo propondremos un algoritmopara la deteccion de este tipo de letreros. Es-te algoritmo primero transforma la imagen encolor a una imagen en escala de grises don-de el contaste de la lınea que rodea el letreroes maximo, a continuacion empleando meto-dos basados en un umbral dinamico o en la de-teccion de bordes se detectan los posibles con-tornos candidatos. Despues se emplean una se-rie de restricciones para poder detectar cualesde estos contornos conforman la lınea del bor-de y por ultimo se rectifica el letrero o se haceRealidad Aumentada sobre el.
23
Capıtulo 4
4.1. Paso a escala de grises
Cada pıxel de una imagen en color se compone normalmente de tres canales RGB(Red-Green-Blue) que se representan mediante valores entre 0 y 255. Una forma alternativa de ver esta repre-sentacion del color es como un espacio vectorial de tres componentes en el cual cada color es unvector.
Por otra parte, una imagen en escala de grises se compone de una unica componente que tomavalores entre 0 y 255, lo que visto desde la perspectiva del espacio vectorial RGB puede entendersecomo proyectar cada color de la imagen sobre la recta que va desde el (0,0,0) que simboliza el colornegro hasta el (255, 255, 255) que representa al color blanco.
Ya que la transformacion a escala de grises es necesaria para poder aplicar los siguientes pasos delalgoritmo, podemos emplear lo explicado en los parrafos anteriores y nuestro conocimiento sobrelos colores del letrero para encontrar la proyeccion de colores que maximiza el contraste entre elcolor de la lınea y el color del letrero.
La proyeccion de colores que maximiza el contraste entre el color de la linea y el del fondo delletrero es aquella que se hace sobre la recta que pasa por estos dos puntos del espacio RGB, comose puede ver el la figura 4.2. Por lo que para calcular el gris correspondiente a cada color de laimagen, debemos en primer lugar calcular esta recta, luego proyectar todos los colores sobre ella,y por ultimo normalizar estos valores para que se encuentren entre 0 y 255.
Figura 4.2: Proyeccion es el espacio RGB
La ecuacion de esta recta puede calcularse a partir de uno de los dos puntos de color c1 o c2 y delvector direccion que sera ~v = c1−c2, no obstante como lo unico que necesitamos es la proyeccionde los puntos de la imagen sobre esta recta, podemos calcularla como la proyeccion sobre su vectordireccion ~v, para ello emplearemos una proyeccion escalar.
Sea c el color(punto del espacio RGB) del que queremos calcular su proyeccion sobre ~v, esta
24
Busqueda de Letreros
(a) Cartel 1 antes de la con-version
(b) Cartel 1 despues de laconversion
(c) Cartel 2 antes de la con-version
(d) Cartel 2 despues de laconversion
Figura 4.3: Diferencia en la conversion a escala de grises entre un letrero con colores bien selec-cionados y mal seleccionados
proyeccion viene dada por la proyeccion escalar de su vector sobre el vector ~v:
Proy~v ~c =|~c · ~v||~v|
No obstante esta proyeccion puede dar valores que no estaran necesariamente entre 0 y 255, por loque emplearemos una transformacion afın x 7→ Ax + b para colocarla todos los puntos(X) entreestos valores.
x 7→ Ax+ b; A =255
max(X)−min(X); b = − 255 min(X)
max(X)−min(X)
De esta forma de calcular la imagen en escala de grises tambien se puede deducir una recomenda-cion a la hora de seleccionar el color de los letreros, pues para una buena deteccion es favorableque la recta que pasa por los dos colores seleccionados sea ortogonal a la recta de luminosidad (sila recta es de esta forma es menos probable que halla colores que se proyecten sobre ella fueradel segmento delimitado por la proyeccion de los dos colores originales), y que estos colores seanentre si lo mas distantes posible.
Un ejemplo podemos encontrarlo en las figuras 4.3 donde a la derecha vemos un letrero cuyoscolores del fondo del letrero y de la lınea a detectar son practicamente el mismo solo que con elcolor de la lınea un poco mas claro, como consecuencia, se ve que al pasarlo a escala de grises conel metodo propuesto anteriormente el contraste generado no es notorio. A la izquierda sin embargo,tenemos un letrero en el que el color del fondo es azul y la lınea amarilla (color antagonico delazul), por lo que la recta entre los dos colores es ortogonal a la recta luminosidad y vemos que enel paso a escala de grises esto redunda en un mayor contraste.
Este procedimiento es costoso computacionalmente con lo que se ha implementado una solucionparalela que emplea multi-threading para agilizar el calculo especialmente en dispositivo moviles.
25
Capıtulo 4
4.2. Deteccion de contornos
Ahora que ya tenemos la imagen en escala de grises nos interesa detectar en ella todos los posi-bles contornos que sean susceptibles de ser la lınea que rodea nuestro letrero. Los contornos sonaquellos pıxeles que en una imagen binaria (solo contiene unos y ceros) forman una frontera entrelos unos y los ceros. Nuestro objetivo es el de extraer de una imagen todos los bordes en forma decontornos, para poder buscar entre ellos aquellos que conforman el borde del letrero.
Para ello primero debemos binarizar la imagen haciendo que esta imagen binarizada refleje lo masclaramente posible el contorno de la lınea de nuestro letrero. Se pueden emplear dos enfoques, elmas sencillo de ellos consiste en establecer un umbral (Threshold) en el nivel de gris, de modo quetodos los pıxeles de la imagen con un nivel de gris superior pasan a valer 1 y todos aquellos conun nivel inferior 0. Esta alternativa es rapida de computar pero muy sensible a la iluminacion y alruido, puesto que no es facil encontrar ese umbral y aun si lo encontrasemos podrıa darse el casode que una zona clara este mal iluminada y pueda ser interpretada como oscura, si eso sucedieseno serıamos capaces de diferenciar en la imagen binarizada el borde del letrero.
Otro posible enfoque es emplear un filtro de deteccion de bordes basado en el gradiente, como porejemplo en filtro de Canny[2], este filtro emplea el operador de Sobel para calcular el gradiente dela imagen por lo que su evaluacion no es excesivamente costosa siendo mucho mas robusto antecambios de iluminacion y al ruido.
El algoritmo de binarizacion que planteamos aquı emplea ambos enfoques, empleando el filtro deCanny en caso de que no se haya detectado el letrero previamente, y en caso contrario empleandoThresholding.
Data: image, color1, color2, last threshold, last frame contained a squareResult: squares, last frame contained a square, used thresholdblurred img = blur image(image);gray img = convert to grayscale using color projection (blurred img, color1, color2);if last frame contained a square then
squares, used threshold = find squares by threshold levels (gray img, last threshold);last frame contained a square = not squares.empty();
elsethresh img = Canny(gray img);squares = find squares in thesholded image(threshImg);if not squares.empty() then
middle thres = get middle threshold();thres squares, used threshold = find squares by threshold levels (gray img,middle thres);last frame contained a square = not thres squares.empty();
endend
Algorithm 1: Umbralizado de la imagen en blanco y negro
26
Busqueda de Letreros
(a) Escala de grises (b) Contornos Canny (c) Umbral = 100 (Nivel 0)
(d) Umbral = 101 (N. 1 hacia arriba) (e) Umbral = 99 (N. 1 hacia abajo) (f) Umbral = 103 (N. 2 hacia arriba)
Figura 4.4: Diferentes binarizaciones empleando el filtro de Canny y distintos niveles de umbrali-zacion.
Este proceso de binarizacion va a ser ejecutado para cada fotograma que llegue procedente dela camara, es por ello que si en el fotograma anterior hemos utilizado con exito un determinadoumbral para binarizar, es muy probable que el mismo umbral o uno similar nos sirvan a no ser queel letrero ya no este visible. Este comportamiento se muestra en el algoritmo 1, que en caso de en elfotograma anterior se haya detectado un letrero llama a la funcion find squares by threshold levelspasandole la imagen actual y el umbral empleado en la iteracion anterior.
Find squares by threshold levels lo que hace es buscar un letrero en una serie de niveles de um-bralizado, comenzando en el nivel que se le pasa como segundo parametro y si en este no encuentrael letrero itera buscando en los niveles contiguos al anterior, separandose del nivel inicial una dis-tancia que es exponencial en el ındice de la iteracion.
En las imagenes 4.4 vemos en primer lugar (a) la imagen en escala de grises que obtene-mos con el algoritmo 1, en segundo lugar (b) vemos la deteccion de bordes llevada a cabopor el filtro de Canny, que se aplica al comienzo para ver de modo robusto si hay algun le-trero en la imagen. Si Canny tras binarizar la imagen encuentra el letrero mediante la llamadafind squares in thesholded image(threshImg) que explicaremos en el siguiente sub-apartado, en-tonces probaremos tambien el umbralizado.
Esto se hace ası porque si no tenemos conocimiento de que haya o no un letrero presente en laimagen, recorrer todos los posibles niveles de umbralizado en cada fotograma serıa muy costoso,
27
Capıtulo 4
no obstante si ya sabemos que el letrero existe, solo tenemos que buscar en los distintos niveles laprimera vez para encontrar el umbral correcto, en los siguientes fotogramas buscaremos partiendode ese umbral lo cual es mucho mas rapido.
Este primer umbral de busqueda es la proyeccion del punto medio entre los dos colores a escalade grises, en el ejemplo este valor es 100 que puede verse en la sub-figura (c). En esta imagenla claridad de una parte del letrero hace que no se detecte correctamente toda la lınea por lo queen una segunda iteracion buscaremos en los niveles colindantes 101 (d) y 99 (e) donde tampocoencontraremos el cuadrado. Es en la tercera iteracion donde al emplear un umbral de 103 podemosseparar claramente la lınea del fondo del letrero (f), por lo que la deteccion es exitosa. En lasproximos fotogramas el nivel del que partira el algoritmo sera 103 en vez de 100 por lo que labusqueda sera mucho mas veloz.
A partir de esta imagen binarizada extraer los contornos es tan sencillo como seleccionar aque-llos pıxeles negros que tienen algun vecino blanco o viceversa, agrupando en un unico contornoaquellos contiguos entre sı.
4.3. Seleccion de contornos
En la secciones anteriores pudimos ver como pasar de una imagen en color a una imagen en escalade grises y como obtener de esta imagen una serie de contornos, en la presente seccion veremoscomo podemos tratar a estos contornos para averiguar si estos son parte del la lınea que rodeanuestro letrero obteniendo como resultado final la posicion de las cuatro esquinas (ver figura 4.5).
El primer paso que debemos dar es reducir el numero de puntos que definen nuestro contorno, estopuede hacerse empleando el algoritmo de Ramer–Douglas–Peucke, que dada una curva compuestapor segmentos, encuentra una curva similar aproximada con menos puntos. El algoritmo define unadiferencia ε basada en la maxima distancia entre la curva original y la curva simplificada.
Esta diferencia tendra un gran impacto en nuestro problema de deteccion, ya que un ε muy grandehara que que otras figuras puedan ser tomadas como letreros y un ε muy pequeno hara que debidoal ruido los bordes de nuestro letrero puedan ser aproximados con mas de 4 puntos principales (lascuatro esquinas). Para ello definiremos ε en funcion de un parametro del algoritmo epsilonRatio yde la longitud del contorno:
ε = epsilonRatio ∗ longitud
Una vez que hemos simplificado adecuadamente todos los contornos, nos quedaremos con aquellosque tienen tan solo cuatro lados, ası descartaremos todos los bordes de cosas cuya forma no sea uncuadrilatero. Tambien establecemos un area mınima de cara a descartar pequenos contornos comoletras o paredes con azulejos. A continuacion exigiremos que el contorno sea convexo, pues desdecualquier perspectiva un letrero nunca puede ser concavo.
Tras todas estas comprobaciones ya hemos seleccionado los cuadrilateros convexos y de gran ta-mano. Si los pasos previos se han sucedido adecuadamente dos de ellos deberıan formar el bordeinterno y el borde externo de la lınea que rodea nuestro letrero, por lo que para encontrarlos, ge-neraremos todos los posibles pares, y comprobaremos que los centros (para cada cuadrilatero, el
28
Busqueda de Letreros
(a) Total de contornos detectados (b) Contornos una vez aplicado el al-goritmo de Ramer–Douglas–Peucke
(c) Contornos de cuatro lados
(d) Contornos cuyo tamano superan elumbral
(e) Contornos convexos (f) Contorno con menor area de entrelos finales
Figura 4.5: Seleccion de contornos
punto donde se cruzan sus diagonales) de ambos cuadrilateros no disten entre sı mas de maxCen-terDistance pıxeles. Si el par de contornos cumple esta condicion entonces nos quedamos con elelemento dentro del par que tiene menor area, es decir el borde interno.
Por si hubiese varios letreros en escena, el paso final consiste en ordenar los letreros detectadospor su area, devolviendo una lista ordenada en la que los letreros mas granes (los mas proximos)esten al inicio, esto tambien es un modo de seleccionar el letrero frente a otros falsos positivos quehayan podido aparecer.
4.4. Rectificar el letrero
A partir de los pasos vistos en la seccion anterior ya podemos obtener la posicion de las cuatroesquinas, esto es muy importante ya que nos permitira calcular la posicion de la camara en caso deque queramos hacer realidad aumentada.
Un punto de interes en este caso es rectificar el letrero para poder utilizar el contenido que enel aparece, en el caso de la figura 4.1 podrıamos emplear un reconocedor de textos para leer losdıgitos que en el aparecen.
29
Capıtulo 4
Esto puede hacerse mediante el uso de una transformacion proyectiva como la homografıa que nosdefina como mapear la imagen original (la que nos llega a traves de la camara) a la imagen destinodonde deseamos plasmar el letrero rectificado.
Previamente al empleo de una homografıa debemos definir las correspondencias entre los puntosde ambas imagenes origen-destino, para lo cual es imprescindible ordenar previamente las esquinasdel letrero detectado en la imagen. Si suponemos que el letrero estara colgado de una pared, y portanto en posicion vertical, el problema se reduce a identificar correctamente esas cuatro esquinas ymapearlas a las cuatro esquinas de la imagen destino.
Para ordenar las cuatro esquinas almacenadas en un vector es conveniente el empleo de la funcionstd::sort (RandomAccessIterator first, RandomAccessIterator last, Compare comparator), dondeel tercer parametro es una funcion o clase comparadora, que dados dos elementos del vector deter-mina cual de ellos es mayor.
Figura 4.6: Ordenacion de las esquinas segun suangulo con el centro de gravedad del cuadrilatero
Para comparar dos puntos de un mismo cua-drilatero emplearemos como medida el anguloque cada uno de estos puntos forma con el cen-tro de gravedad de la figura. Esto nos dara deforma natural una ordenacion como la que sepuede observar en la figura 4.6.
El angulo entre los puntos debe obtenerse te-niendo en cuenta que el eje Y de la imagen esel inverso del eje y geometrico convencional.El angulo entre el punto p y el centro c puedecalcularse como:
tan(θ) =c.y − p.yp.x− c.x
θ = arctan
(c.y − p.yp.x− c.x
)
Una vez que hemos ordenado adecuadamentelas esquinas del letrero, el siguiente paso cosis-te en definir un vector con las esquinas de laimagen destino donde queremos que se trans-forme el letrero rectificado. Hecho esto, solo tenemos que construir la homografıa correspondientey emplearla para rectificar el letrero. Esto puede verse en el codigo 4.1.
30
Busqueda de Letreros
Listado 4.1: Codigo C++ para el rectificado del letrero
void S q u a r e D e t e c t o r : : wrapSquare (s t d : : v e c t o r<cv : : P o i n t> & squa re ,c o n s t cv : : Mat& s r c ,cv : : Mat& d s t ,cv : : S i z e wrapS ize )
{i n t w = wrapS ize . wid th ;i n t h = wrapS ize . h e i g h t ;
P o i n t 2 f p00 ( 0 , 0 ) , p01 ( 0 , w) , p10 ( h , 0 ) , p11 ( h , w ) ;P o i n t 2 f o u t P o i n t s [ 4 ] = { p00 , p10 , p11 , p01 } ;
P o i n t 2 f i n P o i n t s [ 4 ] ={ s q u a r e [ 0 ] , s q u a r e [ 1 ] , s q u a r e [ 2 ] , s q u a r e [ 3 ] } ;
Mat homography = g e t P e r s p e c t i v e T r a n s f o r m ( i n P o i n t s , o u t P o i n t s ) ;w a r p P e r s p e c t i v e ( s r c , d s t , homography , wrapS ize ) ;
}
Todo ello se ha implementado para correr en dispositivos moviles. El resultado puede observarseen la imagen 4.7:
Figura 4.7: Captura de pantalla que muestra el rectificado del letrero
31
Capıtulo 4
4.5. Experimentos
Para comprobar el correcto funcionamiento del algoritmo se han llevado a cabo experimentos condistintas secuencias de imagenes en las que se somete al algoritmo a diferentes perspectivas, con-diciones de iluminacion, ruido y oclusiones. Tambien se han utilizado varios letreros para probarel comportamiento con diferentes colores de letrero y de lınea. En estas pruebas haremos RealidadAumentada empleando OpenGL para proyectar un cubo sobre el centro de la escena. La correctaproyeccion de este objeto 3D esta avalada por los experimentos realizados en el capıtulo anterior.
Los resultados obtenidos pueden verse en las imagenes de las figuras 4.8 y 4.9, donde las primerascuatro imagenes muestran el comportamiento del algoritmo bajo luz artificial y con un patron decolores contrastados. De izquierda a derecha y de arriba a abajo podemos ver el resultado finaldonde se proyecta un cubo virtual empleando OpenGL, a la derecha el sistema de coordenadas dela escena proyectado mediante las tecnicas de vision con la librerıa OpenCV. Abajo a la izquierdavemos el paso de la imagen a escala de grises empleando la proyeccion en el espacio de color ypor ultimo abajo a la derecha la imagen binaria que resulta del umbralizado.
En el segundo grupo de imagenes podemos ver un patron mas claro sometido a luz natural y vistodesde una distancia y perspectiva diferentes que tambien es detectado con exito.
A la vista de los resultados podemos concluir que el algoritmo se comporta adecuadamente antecambios de perspectiva, iluminacion e incluso el ruido provocado en la imagen por los focos fluo-rescentes. La unica situacion donde se ha observado que el algoritmo tiene problemas es cuando noconsigue observar por completo el perımetro del letrero. Este hecho puede darse si dejamos fuerauna parte del letrero o bien si existe alguna oclusion.
32
Busqueda de Letreros
Figura 4.8: Experimentos de la deteccion de letreros
33
Capıtulo
4
Figura 4.9: Secuencia de vıdeo grabada para los experimentos. Fila 1 y 3 imagenes originales, filas 2 y 4 imagenes en RA
34
Capıtulo 5
Conclusiones
Los sistemas actuales no son validos para hacer realidad aumentada 3D sobre letreros debido prin-cipalmente a lo difıcil que es detectarlos, una complicacion anadida es la tediosa calibracion delos dispositivos moviles que hace inviable muchas aplicaciones practicas. Hemos solucionado elproblema implementando un sistema de RA para dispositivos moviles que se basa en dos contribu-ciones teoricas.
La primera contribucion es un metodo para realizar la calibracion automatica del dispositivobasandonos en parametros fısicos de la camara que son ampliamente conocidos y que podemosobtener de las APIs de la mayorıa de los sistemas operativos moviles. Ademas proporcionamosuna implementacion C++ de este metodo para dispositivos Android.
La segunda contribucion es un algoritmo para deteccion de letreros, que emplea una tecnica se-guimiento en el espacio de color y un descarte de candidatos segundo sus propiedades geometricaspara encontrar el letrero en un determinado fotograma.
Mediante los experimentos realizados hemos estudiado el impacto de una calibracion erronea yapoyandonos en este estudio hemos demostrado que el error cometido por nuestro metodo de cali-bracion automatica es mınimo. Por lo que esta calibracion es idonea para ser empleada en sistemasde Realidad Aumentada. Respecto a los experimentos realizados para la deteccion de letreros, se haprobado que el algoritmo es invariante ante cambios en el tamano y la rotacion del letrero ası comorobusto a variaciones de iluminacion y perspectiva.
5.1. Trabajos Futuros
No obstante, queda todavıa mucho por hacer, algunas tareas pendientes son:
1. La inclusion de tecnicas de tracking que empleen la informacion de donde se encontraba elletrero en el instante anterior para hacer su busqueda en el instante actual mas eficiente.
2. El estudio de las distintas distorsiones opticas, pues las camaras de los dispositivos suelen
35
Capıtulo 5
sufrir fuertes distorsiones que de ser consideradas en un modelo de Realidad Aumentada ledarıan todavıa mas realismo.
3. El uso de los sensores del dispositivo que proveen de informacion sobre la posicion y orien-tacion, ya que si estos datos se combinan daran lugar a una estimacion mas robusta de laposicion de la camara, haciendo la proyeccion mas precisa.
4. El tratamiento de oclusiones ya que con el algoritmo de deteccion actual si alguna de laspartes del letrero se encuentra ocluida por otro objeto su deteccion no sera posible.
5. El empleo de patrones tridimensionales es tambien una vıa de investigacion muy atractivaque dotarıa al sistema de muchas mas aplicaciones.
6. La implementacion en otros sistemas operativos como iOS o Windows phone que permi-tirıa que este motor llegase a un publico mucho mayor.
36
Apendice A
Consideraciones de Diseno yArquitectura Software
Para construir el sistema que permita dar soporte al trabajo de investigacion desarrollado en eltranscurso de este Trabajo Fin de Master se ha desarrollado un sistema de Realidad Aumentadaque se describira en el presente apendice.
A.1. Seleccion de plataforma y lenguaje de implementacion
Existen multiples plataformas y librerıas sobre las que se puede desarrollar un sistema de RA, lasprincipales decisiones a tomar consisten en el motor grafico a emplear y la librerıa de vision aseleccionar.
Respecto al lenguaje de implementacion ademas del requisito de interoperabilidad tenemos tam-bien el de eficiencia, ya que estos algoritmos son tıpicamente muy costosos y las plataformasmoviles muy limitadas en recursos. Teniendo en cuenta esta consideraciones se escoge C++ porsu eficiencia y su amplio soporte multiplataforma, siendo el Native Development Kit (NDK) deAndroid el entorno donde se construira la aplicacion de prueba.
Teniendo en cuenta esta decision a continuacion veremos los motores 3D que se han valorado.Por una lado se han valorado los motores libres y sin copyleft para graficos simples y por otrolado a modo de posibilidades de futuro se han valorado motores privativos de gran potencia. Nose contemplan conocidos motores libres como OpenSceneGraph ya que sus licencias con copyleftpodrıan ser un impedimento a la hora de su uso comercial.
Cocos2d: Cocos2d es un motor libre y de licencia MIT, construido en C++ y integrablecon JavaScript, Java, Lua y Objetive-C. Es compatible con Windows, Linux, OS X, iOS,Android, BlackBerry y Tizen.
LibGDX: LibGDX es otro motor libre de licencia Apache 2.0 construido como una API Java
37
Apendice A
para videojuegos por lo que es ampliamente empleado por la comunidad Android. Compati-ble con GNU/Linux, Windows, Mac OS X, iOS(en dudosas condiciones) y Android.
OGRE3D: Ogre es otro motor libre de licencia MIT, escrito y pensado para C++ soportacompatibilidad con Linux, Windows, OS X, iOS y Android.
Unity 3D: Unity es un conocido motor 3D privativo que destaca por su alta compatibilidadmulti-plataforma, por su usabilidad y por su rendimiento. Funciona como un entorno dedesarrollo propio basado en C#, lo dificulta su uso como librerıa.
Unreal: Unreal es uno de los mejores motores del mercado, escrito en C++ y pensado paraser usado desde C++ genera unos graficos de una altısima calidad y dispone de un sin fin deherramientas de desarrollo grafico.
En nuestro caso, utilizaremos OpenGL en la version de escritorio para correr los experimentos, yaque no necesitamos una gran potencia, tan solo corroborar el buen funcionamiento de la librerıanativa C++. Para la version Android, hemos escogido libGDX al que nuestra aplicacion Androidpasara la posicion de la camara calculada por la librerıa nativa.
En cuanto a la librerıa de vision por computador para hacer RA, existe una amplia gama comoMXRToolkit, FLARToolKit, ALVAR, ArUCO... pero la mayorıa de ellas no soportan el trackingbasado en caracterısticas naturales y solo sirven para reconocer targets. La unica librerıa open-source que hemos encontrado capaz de tratar con estas marcas es ARToolKit, no obstante su codigoC esta muy poco documentado y dado su tamano hemos considerado que es mas factible emplearla conocida librerıa de vision OpenCV partiendo de algunos ejemplos como los que se ofrecen enel libro “Mastering OpenCV with Practical Computer Vision Projects” [1].
A.2. Arquitectura Software Global
La arquitectura global de la aplicacion se plantea como una librerıa C++ compilada estaticamentede modo que englobe aquellos modulos de OpenCV que sean necesarios. Esta librerıa sera llamadapor un programa C++ en caso de que se este ejecutando en un PC, o bien a traves de la parte nativade una aplicacion android en caso de que se utilice este sistema operativo.
La librerıa recibira en un primer instante como entrada los datos fısicos del dispositivo con losque calculara y devolvera la matriz de proyeccion de OpenGL. Durante la ejecucion, la librerıarecibira los fotogramas provenientes de la camara y devolvera la matriz ModelView de OpenGLcon los parametros extrınsecos que indican la posicion de la camara si se usa OpenGL, o si seemplea un motor como libGDX la posicion de la camara y su rotacion en formato de su vectordireccion y vector superior (up).
A.2.1. Organizacion del proyecto
El proyecto se estructura desde un directorio raız que tiene la estructura de la imagen A.1. Enel directorio principal podemos encontrar lo relativo a la version de escritorio, esta version de
38
Consideraciones de Diseno y Arquitectura Software
escritorio es un proyecto Cmake, que generara los ejecutables tanto para la aplicacion de pruebacomo para cada uno de los tests y experimentos.
Figura A.1: Estructura del proyecto
A.2.2. Aplicacion Android
Debido a las limitaciones de tiempo y de recursos en este TFM, solo se contemplara como plata-forma movil Android. La arquitectura de la aplicacion en Android, que puede verse en la figuraA.2, sera la de una aplicacion java & C++.
En la parte java se importara la librerıa de OpenCV Android para usarla en el manejo de la camara,la gestion de threads y la visualizacion de fotogramas. En java tambien se importara el motorgrafico liGDX para el renderizado de la capa virtual.
Nuestra Activity principal estara compuesta por dos capas principales, la primera de ellas sera unaclase que extiende de CameraGLSurfaceView y que enviara mediante OpenGL ES 2.0 la imagenproveniente de la camara directamente a la GPU del dispositivo si es que dispone de ella. Encimade esta capa que muestra las imagenes de la camara se situara la capa virtual que estara formadapor una clase que extiende de com.badlogic.gdx.ApplicationAdapter y que contiene toda la logicanecesaria para mostrar nuestros modelos 3D.
El flujo de trabajo en la aplicacion comienza cuando un nuevo fotograma llega de la camara, enese momento OpenCV Android llama a nuestra aplicacion a traves de un callback pasandole la di-reccion de memoria de esta imagen. A continuacion pasaremos esta imagen a la librerıa de visionnativa a traves de JNI. Nuestra aplicacion nativa escrita en C++ para maximizar la eficiencia apli-cara el algoritmo para deteccion de letreros visto en el capıtulo 4 y en base a ese patron calculara laposicion del dispositivo en la escena.
La posicion calculada es devuelta a la maquina virtual modificando los miembros de la clase
39
Apendice A
MyGdxAR.PatternTrackingInfo. Esta clase se lee cada vez que el motor grafico refresca la pan-talla para actualizar la posicion de la camara, por lo que cuando el motor vuelva a refrescar lapantalla la camara se actualizara de forma coherente con esta nueva posicion y el modelo se ren-derizara como si estuviese presente en la escena, provocando ası el deseado efecto de RealidadAumentada.
Figura A.2: Arquitectura de la aplicacion Android
A.3. Diseno Software
A continuacion se adjunta en la figura A.3 el diseno software del paquete ar, en la figura A.4 eldiseno del paquete calib y del paquete util no se proporcionara su diseno dada su simplicidad.
40
Consideraciones de Diseno y Arquitectura Software
Figura A.3: Diseno del paquete ar de la librerıa nativa
41
Apendice A
Figura A.4: Diseno del paquete calib de la librerıa nativa42
Consideraciones de Diseno y Arquitectura Software
A.4. Sobre la elaboracion del proyecto
El proyecto se ha desarrollado empleando una variacion de la metodologıa agil SCRUM para unsolo desarrollador. En total se han realizado 5 sprints:
Revision del estado del arte e implementacion de un metodo clasico
Estudio de calibracion
Deteccion de letreros
Integracion con un motor grafico
Elaboracion de la memoria
Como herramienta de control de versiones se ha hecho uso de git a traves de github y como herra-mienta de seguimiento de incidencias se ha empleado RedMine.
43
44
Bibliografıa
[1] Daniel Lelis Baggio. Mastering OpenCV with practical computer vision projects. PacktPublishing Ltd, 2012.
[2] John Canny. A computational approach to edge detection. IEEE Transactions on patternanalysis and machine intelligence, (6):679–698, 1986.
[3] Thomas P Caudell and David W Mizell. Augmented reality: An application of heads-up dis-play technology to manual manufacturing processes. In System Sciences, 1992. Proceedingsof the Twenty-Fifth Hawaii International Conference on, volume 2, pages 659–669. IEEE,1992.
[4] Ondrej Chum and Jirı Matas. Matching with prosac-progressive sample consensus. In Com-puter Vision and Pattern Recognition, 2005. CVPR 2005. IEEE Computer Society Conferenceon, volume 1, pages 220–226. IEEE, 2005.
[5] Jakob Engel, Thomas Schops, and Daniel Cremers. Lsd-slam: Large-scale direct monocularslam. In European Conference on Computer Vision, pages 834–849. Springer, 2014.
[6] Martin A Fischler and Robert C Bolles. Random sample consensus: a paradigm for modelfitting with applications to image analysis and automated cartography. Communications ofthe ACM, 24(6):381–395, 1981.
[7] Chris Harris and Mike Stephens. A combined corner and edge detector. In Alvey visionconference, volume 15, page 50. Citeseer, 1988.
[8] Richard Hartley and Andrew Zisserman. Multiple view geometry in computer vision. Cam-bridge university press, 2003.
[9] Jared Heinly, Enrique Dunn, and Jan-Michael Frahm. Comparative evaluation of binary fea-tures. In Computer Vision–ECCV 2012, pages 759–773. Springer, 2012.
[10] Michal Irani and P Anandan. About direct methods. In Vision Algorithms: Theory andPractice, pages 267–277. Springer, 1999.
[11] Lars Kruger and Christian Wohler. Accurate chequerboard corner localisation for cameracalibration. Pattern Recognition Letters, 32(10):1428–1435, 2011.
[12] Vincent Lepetit, Francesc Moreno-Noguer, and Pascal Fua. Epnp: An accurate o (n) solutionto the pnp problem. International journal of computer vision, 81(2):155–166, 2009.
45
[13] Stefan Leutenegger, Margarita Chli, and Roland Y Siegwart. Brisk: Binary robust invariantscalable keypoints. In Computer Vision (ICCV), 2011 IEEE International Conference on,pages 2548–2555. IEEE, 2011.
[14] David G Lowe. Distinctive image features from scale-invariant keypoints. Internationaljournal of computer vision, 60(2):91–110, 2004.
[15] Bruce D Lucas, Takeo Kanade, et al. An iterative image registration technique with an appli-cation to stereo vision. In IJCAI, volume 81, pages 674–679, 1981.
[16] Qin Lv, William Josephson, Zhe Wang, Moses Charikar, and Kai Li. Multi-probe lsh: efficientindexing for high-dimensional similarity search. In Proceedings of the 33rd internationalconference on Very large data bases, pages 950–961. VLDB Endowment, 2007.
[17] Marius Muja and David G Lowe. Fast approximate nearest neighbors with automatic algo-rithm configuration. VISAPP (1), 2:331–340, 2009.
[18] Marius Muja and David G Lowe. Fast matching of binary features. In Computer and RobotVision (CRV), 2012 Ninth Conference on, pages 404–410. IEEE, 2012.
[19] Edward Rosten and Tom Drummond. Machine learning for high-speed corner detection. InComputer Vision–ECCV 2006, pages 430–443. Springer, 2006.
[20] Ethan Rublee, Vincent Rabaud, Kurt Konolige, and Gary Bradski. Orb: an efficient alternativeto sift or surf. In Computer Vision (ICCV), 2011 IEEE International Conference on, pages2564–2571. IEEE, 2011.
[21] Philip HS Torr and Andrew Zisserman. Mlesac: A new robust estimator with applicationto estimating image geometry. Computer Vision and Image Understanding, 78(1):138–156,2000.
[22] Jianhua Wang, Fanhuai Shi, Jing Zhang, and Yuncai Liu. A new calibration model of cameralens distortion. Pattern Recognition, 41(2):607–615, 2008.
[23] Yingjie Wang, Chin-Seng Chua, and Yeong-Khing Ho. Facial feature detection and facerecognition from 2d and 3d images. Pattern Recognition Letters, 23(10):1191–1202, 2002.
[24] Changchang Wu. Siftgpu: A gpu implementation of scale invariant feature transform (sift).2007.
[25] Zhengyou Zhang. A flexible new technique for camera calibration. Pattern Analysis andMachine Intelligence, IEEE Transactions on, 22(11):1330–1334, 2000.
46
