Framework para el Desarrollo deRealidad Aumentada para

Dispositivos Móviles con SistemaOperativo Android

Tesis para obtener el grado de

Maestro en Tecnologías de laInformación y Comunicaciones

Presentado por:

L. S. C. Jorge Stefan Cruz León

Directora de tesis:

M. en C. Jazmín Rodríguez Flores

Co-director:

M. en C. Josué Román Martínez Mireles

Zempoala, Hgo. México Septiembre 2014

Agradecimientos

Le agradezco a mis asesores: M. en C. Jazmín Rodriguez Flores y M. en C. Josúe

Román Martinez Mireles por el constante apoyo y dedicación brindada para concluir

satisfactoriamente la maestría.

A mis sinodales, el Dr. Julio César Salgado Ramirez, M. en C. Marco Antonio Gar-

cía Márquez y M. en C. José Juan Zarate Corona por los consejos y observaciones

otorgadas que sirvieron para desarrollar adecuadamente el proyecto de maestría.

A mis padres y a mi hermano por el constante apoyo y buenos deseos que siempre me

han dado y que se ven recompensados al término de éste ciclo, a Alma por que a pesar

de todos los contratiempos y di�cultades siempre ha estado a mi lado incondicional-

mente, a Rubén y Rodrigo por que son la perfecta inspiración para cumplir todos mis

objetivos en la vida, por entender esas largas ausencias y periodos de estrés y aún así

al �nal del día siempre están ahí con un beso, un abrazo y unas palabras de amor que

siempre me alientan a seguir adelante.

A mis compañeros y amigos de la maestría por compartir momentos inolvidables a

mi lado, a la Universidad Politécnica de Pachuca por brindarme un espacio en sus

instalaciones para continuar con mi formación profesional.

Al Consejo Nacional de Ciencia y Tecnología por brindarme el apoyo de la beca número

338861 con número de registro 275030 sin el cual no hubiera podido realizar el proyecto

de investigación.

Resumen

En el presente documento se describe el desarrollo del proyecto de investigación que

lleva como título �Framework para el Desarrollo de Realidad Aumentada para Dis-

positivos Móviles con Sistema Operativo Android� , el proyecto se estructuró en una

arquitectura constituída por 4 módulos: módulo de aplicación, módulo de procesa-

miento, módulo de almacenamiento de datos y módulo de captura y edición de video.

Para su elaboración se empleó el IDE Eclipse versión 4.2.1 con el plugin ADT versión

22.0.1 para el desarrollo en Android.

Se utilizó el algoritmo SURF que demostró un mejor desempeño en las pruebas de

detección de puntos de interés, detección ante cambios iluminación, rotación y escala

así como en tiempos de ejecución descritas en el análisis de algoritmos de reconoci-

miento de imágenes. El conjunto de pruebas del funcionamiento del algoritmo SURF

hizo posible el reconocimiento de marcadores no convencionales ante las condiciones

descritas. Se validó la correcta integración y funcionamiento del framework dado que

la aplicación de prueba permitió generar la realidad aumentada en un dispositivo móvil

combinando el reconocimiento de marcadores no convencionales y la geolocalización.

Contenido

1. Introducción 1

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.2. Objetivos especí�cos . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Justi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5. Propuesta de solución . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.7. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.8. Estructura general de la tesis . . . . . . . . . . . . . . . . . . . . . 10

2. Marco teórico 11

2.1. Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1. Características de los dispositivos móviles . . . . . . . . . . 12

2.3.2. Sistemas operativos para dispositivos móviles . . . . . . . . 13

2.3.3. Comparativa entre sistemas operativos móviles . . . . . . . . 14

2.4. Realidad aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . 15

i

2.4.1. Tareas de la realidad aumentada . . . . . . . . . . . . . . . 15

2.4.2. Tipos de realidad aumentada . . . . . . . . . . . . . . . . . 16

3. Arquitectura del framework 19

3.1. Arquitectura de referencia . . . . . . . . . . . . . . . . . . . . . . . 19

3.2. Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . . 22

4. Módulo de procesamiento 25

4.1. Algoritmo de procesamiento de imágenes . . . . . . . . . . . . . . . 25

4.1.1. Determinación del algoritmo de procesamiento de imágenes . 26

4.1.2. Implementación del algoritmo SURF . . . . . . . . . . . . . 29

4.1.3. Pruebas y resultados de la implementación del algoritmo SURF 44

4.2. Geolocalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1. Obtención de la lectura de geolocalización . . . . . . . . . . 59

5. Módulo de almacenamiento de datos 61

5.1. Pruebas y resultados del módulo de almacenamiento de datos . . . . 64

6. Módulo de captura y edición de video 67

6.1. Captura de video . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2. Edición de video . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.3. Pruebas y resultados del módulo de captura y edición de video . . . . 70

7. Pruebas y resultados 73

7.1. Pruebas y resultados del framework . . . . . . . . . . . . . . . . . . 74

8. Conclusiones y trabajos futuros 81

8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.2. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

ii

Referencias 85

A. Diagrama de clases de la arquitectura del framework 91

B. Arquitectura de Android 93

C. Guía para la implementación del framework 97

D. Publicación 103

iii

Página intencionalmente en blanco

iv

Índice de �guras

1.1. Metodología para el desarrollo del proyecto de investigación . . . . . 6

2.1. Realidad de Milgram-Virtuality Continuum . . . . . . . . . . . . . . 15

3.1. Arquitectura de referencia propuesta por Brüegge . . . . . . . . . . . 20

3.2. Arquitectura del framework . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Módulo de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Módulo de procesamiento . . . . . . . . . . . . . . . . . . . . . . . 23

3.5. Módulo de almacenamiento de datos . . . . . . . . . . . . . . . . . 24

3.6. Módulo de captura y edición de video . . . . . . . . . . . . . . . . . 24

4.1. Diagrama de �ujo algoritmo SURF . . . . . . . . . . . . . . . . . . 31

4.2. Cálculo de la imagen integral . . . . . . . . . . . . . . . . . . . . . 33

4.3. Aproximación de las derivadas parciales de segundo orden de las gaus-

sianas empleando �ltros de caja. Izquierda: derivadas parciales de segundo

orden de las gaussianas. Derecha: aproximación por �ltros de caja. . . . 34

4.4. Aproximación de las derivadas parciales de segundo orden de las gaus-

sianas mediante imágenes integrales . . . . . . . . . . . . . . . . . . 35

4.5. Asignación de puntos en las sumatorias en Dxx y Dyy . . . . . . . . 35

4.6. Pirámide del �ltro . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.7. Representación grá�ca de la longitud de los �ltros de diferentes octavas 37

4.8. Filtros de Haar empleados en el descriptor SURF (Color negro identi�ca

el valor de -1 y el blanco el valor de +1) . . . . . . . . . . . . . . . 39

v

4.9. Asignación de la orientación . . . . . . . . . . . . . . . . . . . . . . 40

4.10. Componentes del descriptor . . . . . . . . . . . . . . . . . . . . . . 41

4.11. Diagrama de �ujo emparejamiento de puntos de interés . . . . . . . 43

4.12. Comparativa entre dos imágenes con 2 octavas y 3 intervalos con

resolución de 320x240 (imagen izquierda) y 640x480 (imagen derecha) 45

4.13. Curva de la falsa aceptación y el falso rechazo para determinar el

umbral para la detección de puntos de interés . . . . . . . . . . . . 47

4.14. Curva de la falsa aceptación y el falso rechazo para determinar el

umbral de emparejamiento de imágenes . . . . . . . . . . . . . . . . 48

4.15. Curva de la falsa aceptación y el falso rechazo para determinar el

umbral de aceptación del emparejamiento de imágenes . . . . . . . . 49

4.16. Emparejamiento de imágenes con rotación . . . . . . . . . . . . . . 53

4.17. Emparejamiento de imágenes con cambio de escala . . . . . . . . . . 54

4.18. Emparejamiento de imágenes con cambio de iluminación . . . . . . . 55

4.19. Funcionamiento del GPS . . . . . . . . . . . . . . . . . . . . . . . . 57

4.20. Diagrama de �ujo para obtener la información de geolocalización . . 58

4.21. Aplicación de prueba para obtener la geolocalización del dispositivo . 59

5.1. Diagrama de �ujo para guardar un marcador . . . . . . . . . . . . . 63

5.2. Diagrama de �ujo para obtener la información de los marcadores . . 64

5.3. Prueba del módulo de almacenamiento de datos . . . . . . . . . . . 65

6.1. Diagrama de �ujo para la captura de video . . . . . . . . . . . . . . 68

6.2. Diagrama de �ujo para la edición de video . . . . . . . . . . . . . . 69

6.3. Prueba del módulo de captura y edición de video . . . . . . . . . . . 71

6.4. Superposición de información en la visualización de pantalla . . . . . 71

7.1. Pantalla de inicio de la aplicación de prueba . . . . . . . . . . . . . 74

7.2. Pantalla para guardar un marcador en el módulo de almacenamiento . 75

vi

7.3. Acceso a la galería del dispositivo . . . . . . . . . . . . . . . . . . . 77

7.4. Guargar la información del marcador en el módulo de almacenamiento 77

7.5. Ver registro almacenado en el módulo de almacenamiento . . . . . . 77

7.6. Realidad aumentada en el dispositivo móvil marcador 1 . . . . . . . . 78

7.7. Realidad aumentada en el dispositivo móvil marcador 2 . . . . . . . . 79

A.1. Diagrama de clases de la arquitectura del framework . . . . . . . . . 92

B.1. Arquitectura de Android obtenido de [50] . . . . . . . . . . . . . . 93

vii

Página intencionalmente en blanco

viii

Índice de tablas

1.1. Análisis de las principales características de los Frameworks . . . . . 7

2.1. Análisis de los sistemas operativos de los dispositivos móviles . . . . 14

4.1. Extracto de la comparativa de funcionamiento entre el algoritmo SIFT

y SURF expuesto en [41] . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2. Ventajas e inconvenientes de los descriptores analizados en [40] . . . 28

4.3. Costo computacional de los descriptores analizados en [40] . . . . . . 29

4.4. Comparación entre puntos de interés detectados en imágenes con di-

ferente resolución y cambios en octavas e intervalos . . . . . . . . . 44

4.5. Comparativa de tiempos de ejecución del algoritmo entre diversos dis-

positivos (resultados medidos en segundos) . . . . . . . . . . . . . 45

4.6. Sensibilidad y 1-especi�cidad para generar curva ROC para determinar

el umbral para la detección de los puntos de interés . . . . . . . . . 50

4.7. Sensibilidad y 1-especi�cidad para generar curva ROC para determinar

el umbral para el emparejamiento de imágenes . . . . . . . . . . . . 51

4.8. Sensibilidad y 1-especi�cidad para generar curva ROC para determinar

el umbral de aceptación para el emparejamiento de imágenes . . . . . 52

4.9. Cambios de rotación para el emparejamiento de imágenes . . . . . . 53

4.10. Cambios de escala para el emparejamiento de imágenes . . . . . . . 54

4.11. Cambios de iluminación para el emparejamiento de imágenes . . . . . 55

5.1. Tipos de datos permitidos por SQLite . . . . . . . . . . . . . . . . . 61

ix

5.2. Métodos empleados de la clase SQLiteOpenHelper . . . . . . . . . . 62

5.3. Campos empleados en el módulo de almacenamiento de datos . . . 62

6.1. Librerías empleadas para la captura de video . . . . . . . . . . . . . 67

6.2. Librerías empleadas para la edición de video . . . . . . . . . . . . . . 69

7.1. Dispositivos móviles empleados para las pruebas de funcionamiento del

framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

x

Índice de Códigos Fuente

7.1. Pantalla de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

7.2. Guardar un marcador en el módulo de almacenamiento . . . . . . . . 76

7.3. Acceder al módulo de captura y edición de video . . . . . . . . . . . 78

C.1. AndroidManifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

C.2. Inicializar una instancia de la clase Manejador . . . . . . . . . . . . . 98

C.3. Método onClick del botón para tomar una fotografía . . . . . . . . . 98

C.4. Método para tomar fotografía . . . . . . . . . . . . . . . . . . . . . 98

C.5. Método onClick para el bóton buscar imagen . . . . . . . . . . . . . 99

C.6. Método onActivityResult . . . . . . . . . . . . . . . . . . . . . . . . 100

C.7. Método onClick del botón para almacenar un marcador . . . . . . . 100

C.8. Método para guardar una foto . . . . . . . . . . . . . . . . . . . . . 100

C.9. Método onClick del botón para consultar registros . . . . . . . . . . 101

C.10.Método para consultar registros . . . . . . . . . . . . . . . . . . . . 101

C.11. Inicializar una instancia de la clase Salida . . . . . . . . . . . . . . . 102

C.12.Visualizar video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

C.13.Visualizar video procesado . . . . . . . . . . . . . . . . . . . . . . . 102

xi

Página intencionalmente en blanco

xii

Capítulo 1

Introducción

Oliver Bimber de�ne en su libro �Spatial Augmented Reality� expuesto en [1] que los

sistemas de realidad aumentada son aquellos sistemas que mezclan información virtual

de cualquier tipo, desde imágenes 2D, texto o �guras 3D con un escenario físico real.

Para combinar la información virtual con el entorno real se requieren los siguientes

elementos: una cámara que capta las imágenes del mundo real, software que reali-

za el procesamiento de la imagen recibida y genera la realidad aumentada, así como

una pantalla que muestra al usuario la información �nal, además se pueden emplear

otras tecnologías como acelerómetros, GPS, giroscópios, brújulas, etc. Por lo tanto,

es posible generar las aplicaciones de realidad aumentada para dispositivos móviles

ya que cuentan con el hardware y software necesario para llevarlas a cabo, como lo

demuestran Abril y Carmigniani en [2, 3] en donde exponen que debido a la portabi-

lidad de los dispositivos móviles, es posible utilizar la realidad aumentada en diversos

ámbitos, como lo son: publicidad (donde se muestran las características de productos,

ubicaciones de tiendas y servicios más cercanos), educación (mediante aplicaciones en

museos, parques temáticos, exposiciones, tutoriales), medicina (mediante la simula-

ción de procedimientos quirúrgicos) y entretenimiento (como aplicaciones de juegos,

simuladores y geolocalización). Así mismo, para desarrollar aplicaciones de realidad

aumentada que utilicen marcadores no convencionales se requiere el empleo de algo-

ritmos de reconocimiento de imágenes, para lo cual la velocidad del procesamiento de

detección, el tamaño, así como el entorno para funcionar adecuadamente in�uyen en

la elección del mismo para emplearlo en el desarrollo de éste tipo de aplicaciones.

En el presente trabajo de investigación se determinó emplear el algoritmo SURF (por

1

las siglas en inglés de Speeded Up Robust Features) con base en la robustez del

algoritmo, donde destaca la velocidad de cálculo de puntos de interés sin pérdida de

rendimiento, así como la invarianza ante cambios de rotación, traslación, escala y

cambios de iluminación, lo cual es de suma importancia para la implementación en un

dispositivo móvil.

1.1. Antecedentes

Abril, Carmigniani y Loup exponen en [2, 3, 4] que los trabajos realizados en el ámbito

de la realidad aumentada se remontan al año de 1950 cuando el cineasta Morton

Heilig escribió sobre un �Cine de experiencia� en el cual se podría hacer participe al

espectador integrando sus sentidos a lo que estuviera observando en la pantalla, ésto

lo llevó a desarrollar en el año de 1962 un prototipo llamado �Sensorama� el cual

integraba los sentidos del espectador (oido, olfato, vista y tacto) a 5 �lmes que se

reproducian en la pantalla. Más tarde, en 1966 Ivan Sutherland construyó el primer

visor montable en la cabeza (Head Mounted Display), como menciona en [5] permitía

interactuar con la realidad virtual y la realidad aumentada. En 1972 Myron Krueger

crea Videoplace el cual como explica en su publicación expuesta en [6] permitía a los

usuarios relacionarse con objetos virtuales los cuales respondían a sus movimientos y

acciones. Los primeros guantes y lentes de realidad virtual fueron desarrollados a �nales

de los 80 por Jaron Lanier, con lo cual creó la frase de realidad virtual para la tecnología

desarrollada, así mismo, en 1990 Tom Caudell y David Mizell en su artículo mostrado

en [7] de�nen el término de realidad aumentada al superponer tableros virtuales sobre

tableros físicos con lo cual �aumentaba� la información mostrada percibiéndola con

unos anteojos especiales. En 1992 Steven Feiner, Blair MacIntyre y Doree Seligmann

desarrollaron KARMA el cual es el primer prototipo de relevancia con el empleo de

realidad aumentada, como lo muestran en su publicación expuesta en [8].

En cuanto al empleo de información geográ�ca para la realidad aumentada, en 1993

Loomis, Colledge y Klatzky desarrollaron un sistema prototipo que empleaba un GPS

y una brújula electrónica para la movilidad en exteriores de personas con discapacidad

visual y proporcionaba asistencia por medio de una �pantalla acústica virtual� como

lo mencionan en [9].

El desarrollo de realidad aumentada en dispositivos móviles tiene sus inicios en 1995

2

cuando se publica el trabajo �El mundo a través del equipo, interacción aumentada

con entornos del mundo real� desarrollado por Jun Rekimoto y Katashi Nagao en

[10], donde se propone el empleo de un dispositivo móvil para crear entornos grá�cos

aumentados. En el 2000, Bruce H. Thomas en [11] crea ArQuake el cual es el primer

juego de realidad aumentada al aire libre con dispositivos móviles. En el 2008 surge AR

Wikitude Guia, aplicación que trabajaba en un dispositivo móvil con sistema operativo

Android, con el empleo de la cámara permitía obtener información de alguna imagen

enfocada. En el año 2009 la empresa de desarrollo de realidad aumentada Total Im-

mersion crea el logo o�cial de la realidad aumentada para estandarizar la identi�cación

de ésta tecnología en cualquier contenido como lo muestra en [12].

1.2. Planteamiento del problema

De acuerdo con el estudio que realizó iabMéxico mostrado en [13] en el 2014 el 84% de

los habitantes en México cuenta con algún dispositivo móvil, siendo 4 de cada 10 dispo-

sitivos un smartphone. Éstos dispositivos son un nicho de oportunidad para diferentes

aplicaciones, debido a que el 77% de los usuarios descangan aplicaciones diversas,

algunas de ellas involucran técnicas de realidad aumentada con diversos enfoques, de

acuerdo con un estudio que realizó Juniper Research expuesto en [14] actualmente en

el mundo existen 60 millones de usuarios de realidad aumentada en smartphones y

se espera que para el año 2018 la cifra éste cerca de 200 millones de usuarios. Éstas

aplicaciones de realidad aumentada emplean marcadores y otros elementos como la

geolocalización para identi�car el momento en que mostrarán información, la cual de

manera general se encuentra almacenada en servidores externos al dispositivo, ésto

implica que se debe tener conectividad, así mismo los marcadores empleados deben

colocarse en determinada posición y tener características especí�cas lo que limita el

funcionamiento de la aplicación. Si bien se realizan pruebas como las descritas en [15]

donde se genera una aplicación de realidad aumentada mediante la implementación de

histogramas de color para el reconocimiento de imágenes, existen contratiempos para

adaptar la aplicación a entornos diferentes. Todo lo anterior brinda la oportunidad

para el el desarrollo del presente proyecto.

3

1.3. Objetivos

1.3.1. Objetivo general

Desarrollar un Framework de realidad aumentada para dispositivos móviles con sistema

operativo Android que permita combinar las técnicas de geolocalización y reconoci-

miento de marcadores no convencionales.

1.3.2. Objetivos especí�cos

Determinar el algoritmo de procesamiento de imágenes óptimo para el desarro-

llo de realidad aumentada con el empleo de marcadores no convencionales en

dispositivos móviles.

Implementar el algoritmo seleccionado para el desarrollo de realidad aumentada

combinándolo con la información de geolocalización del dispositivo.

Desarrollar los módulos de procesamiento, almacenamiento de datos y captura

y edición de video para el funcionamiento del framework.

Validar el funcionamiento del framework para el desarrollo de realidad aumentada

mediante un caso de prueba en un dispositivo móvil.

1.4. Justi�cación

De acuerdo al estudio OurMobile Planet realizado por Ipsos MediaCT y presentado

por Google México en 2012 expuesto en [16], la penetración de los Smarthphone en

el país es del 20%, sin embargo se estima que para el año 2015 este porcentaje se

incremente al 70%. El estudio que se presenta en [17] realizado por TomiAhonen

Consulting en 2011 indica que el sistema operativo móvil de mayor adquisición en el

mundo es Android con 31%, mientras que comScore en su informe que se denomina

Futuro digital Latinoamérica 2013 mostrado en [18] indica que los sistemas operativos

predominantes en México son iOS con 40.5% y Android con 40% .

El estudio mencionado en [19] sobre realidad aumentada realizado en 2011 a nivel

internacional que realiza la empresa de mercadeo tecnológico Hidden muestra el uso

4

que se le brinda a ésta tecnología: publicidad (folletos 19%, lanzamientos 18%, cam-

pañas en línea y conferencias 16%), comercio (puntos de venta 8%, probadores 7%,

contenido en línea 6%), ocio con un 5%, búsquedas GPS 3% y manuales con el

2%. El estudio también indica que al mes son lanzadas al mercado 35 aplicaciones de

realidad aumentada, de las cuales el 43% son gratuitas. Sin embargo, las caracterís-

ticas con que cuentan los dispositivos móviles no han permitido abarcar otras áreas

de enfoque, como se realiza con la realidad aumentada en equipos de cómputo. Con

las estadísticas mencionadas, contar con un framework de realidad aumentada para

dispositivos móviles permitiría abarcar un nuevo enfoque de mercado.

1.5. Propuesta de solución

Se propone desarrollar un framework para generar aplicaciones de realidad aumentada

en dispositivos móviles con sistema operativo android, que permita el reconocimiento

de marcadores no convencionales combinado con la información de geolocalización

para limitar los rangos de búsqueda de los marcadores almacenados y reducir los

tiempos de ejecución del proceso de reconocimiento de imágenes.

1.6. Metodología

Para desarrollar el proyecto de investigación y cumplir los objetivos planteados se siguió

la metodología que se muestra en la Figura 1.1.

5

Figura 1.1: Metodología para el desarrollo del proyecto de investigación

1.7. Estado del arte

A continuación se mencionan las aplicaciones de realidad aumentada que existen ac-

tualmente, ésto para analizar cuál es la aportación más adecuada que pueda brindar

el framework.

En [20] se expone Layar que es una aplicación comercial de realidad aumentada para

Android, se basa tanto en geolocalización como en marcadores, sin embargo, no mezcla

ambos procesos. Utiliza el GPS, la brújula y otros sensores del teléfono móvil para

proporcionar una visualización de varios puntos de interés ordenados por capas o

niveles, donde cada una maneja un aspecto diferente. Para poder instalarlo se requiere

sistema operativo Android 1.5 o superior o iOs 3.1 o superior, cámara digital, GPS,

brújula, acelerómetro y conexión a internet.

En [21] se presenta Mixare que es un navegador de realidad aumentada gratuito y de

código abierto (bajo la licencia GPLV3) que emplea el GPS, la brújula y la cámara

del dispositivo. Disponible para Android y para iPhone 3GS, muestra en la pantalla

6

la información que se encuentra alrededor del dispositivo, proveniente de Twitter y

wikipedia.

Look! es un software desarrollado como proyecto de �n de carrera de la universidad

Complutense de Madrid durante el curso académico 2010-2011 expuesto en [22]. Sus

autores son Sergio Bellón Alcarazo, Jorge Creixell Rojo y Angel Serrano Laguna. Es

un software libre bajo la licencia GPLV3 que ofrece servicios de localización tanto en

exteriores por medio de GPS así como en interiores utilizando señales WiFi.

En [23] se presenta el desarrollo de AndAR que es un framework desarrollado para fun-

cionar en Android. Se encuentra bajo la licencia GNU, por lo cual es de software libre.

Permite la superposición de objetos tridimensionales sobre un marcador convencional

reconocible por el sistema.

La Tabla 1.1 muestra una comparación entre el funcionamiento de LOOK!, Layar, Mi-

xare, AndAR y el framework propuesto, se indican cuales son las fortalezas y limitantes

de cada uno tomando en cuenta distintos aspectos, lo cual da un punto de partida para

los alcances requeridos por el framework a realizar, se analiza si el framework tiene

integración con la cámara del dispositivo, el empleo de marcadores convencionales,

no convencionales y la localización GPS así como el aumento de información en 2D

o 3D, como se observa en la tabla 1.1 el principal aporte del framework propuesto

es la utilización de marcadores no convencionales ya que ninguno de los frameworks

analizados cuenta con ésta característica.

Tabla 1.1: Análisis de las principales características de los FrameworksAplicación LOOK! LAYAR MIXARE AndAR Framework

Integración con cámara X X X X X

2D X X X X

3D X X X

Localización GPS X X X

Marcadores convencionales X X X

Marcadores no convencionales X

A continuación se presentan los trabajos de investigación relacionados con el desa-

rrollo de aplicaciones o frameworks de realidad aumentada que se analizaron para el

desarrollo del proyecto.

El estudio [24] realizado por Bernd Brügge analiza 18 diferentes sistemas de realidad

aumentada en dispositivos móviles. En este estudio, se compara el funcionamiento

7

de cada sistema, así como la arquitectura empleada para su desarrollo, muestra una

arquitectura de referencia, obtenida de la comparativa realizada. Ésta arquitectura de

referencia se basa en la unión de 6 módulos de información, donde cada uno realiza

una actividad en especí�co de la realidad aumentada.

En el trabajo [25] realizado por Behzadan se realiza un software que se llama UM-AR-

GPS-ROVER. El enfoque es la generación de objetos a través de realidad aumentada

de utilidad para la construcción. Este software utiliza un headmounted display (HMD)

equipado con un receptor GPS y seguidor de orientación, una laptop donde se realizan

los procedimientos y una videocámara. Mediante posicionamiento GPS y la orientación

del dispositivo se calcula la posición en la cual será mostrado el objeto aumentado y

la distancia entre la posición del objeto y del dispositivo GPS, para generar el grá�co

con la posición y tamaño adecuado. A pesar de considerar la arquitectura del proyecto

como móvil, se basa en la conjunción de diversos dispositivos, ligando a cada uno una

actividad en especí�co.

El artículo [26] elaborado por López Pombo explica diversas técnicas de desarrollo de

realidad aumentada en equipos de cómputo, las arquitecturas empleadas para cada

una de ellas, además de las situaciones idóneas en las cuales poder implementarlas. A

modo de ejemplo, desarrolla dos prototipos de sistemas de realidad aumentada para

móviles que emplean marcadores blanco y negro con formas rectangulares mediante el

desarrollo de algoritmos especí�cos, elaborados con base en el análisis de la información

de cada caso de estudio.

Domhan muestra en [23] el desarrollo del Framework de realidad aumentada AndAR,

el cual utiliza la librería ArtToolkit. Este framework permite el uso de marcadores

convencionales. Por último, genera una aplicación con reconocimiento de marcadores

rectangulares en tonos blanco y negro.

Turunen muestra en [27] una propuesta de relación entre redes sociales y la realidad

aumentada en dispositivos móviles al generar una aplicación de prueba denominada

LocTrac. El objetivo principal de la aplicación es permitir al usuario obtener la ubica-

ción de sus contactos pertenecientes a una red social, así como mostrar los contactos

más cercanos a su posición, sin embargo encuentra inconvenientes con las velocidades

de procesamiento y el posicionamiento del dispositivo.

El artículo [28] publicado por Jie Shen, muestra el desarrollo de una aplicación que

8

elimina el problema de la oclusión en torno a la realidad aumentada. Su análisis se basa

en la implementación del algoritmo SIFT y el algoritmo RANSAC. Tomando en cuenta

el contorno de los objetos que inter�eren en la muestra de la imagen aumentada, esta

imagen es generada detrás del objeto que se interpone. En ésta aplicación no es

necesario el uso de marcadores, por lo que los objetos generados pueden ser móviles

o deformables.

David Prochazka realiza en [29] una aplicación de realidad aumentada enfocada al

diseño de vehículos, en la cual el usuario carga la imagen de la parte del vehículo

que desea modi�car. Utiliza un algoritmo de reconocimiento de imágenes mediante la

implementación de un perceptrón multicapa, debido a la complejidad de procesamiento

de la red neuronal, esta es implementada en la nube y es entrenada con información

almacenada en una base de datos remota.

El trabajo [15] realizado por Chen Jing, Guo Junwei y Wang Yongtian muestra un

sistema de reconocimiento de imágenes para un museo mediante realidad aumentada

desarrollado en una ultra móvil PC, además utilizan histogramas HSV para reducir

la base de datos de búsqueda de imágenes y a través de un algoritmo de aprendizaje

supervisado realiza el reconocimiento de la imagen. Al realizar las pruebas necesarias se

tuvo aceptación con el uso de la tecnología y el dispositivo, sin embargo, la velocidad

de procesamiento fue lenta.

El artículo [30] elaborado por Gaip Weng muestra una propuesta de integración de

dos técnicas diferentes, la geolocalización con un algoritmo de reconocimiento de

características de imágenes (SURF) adaptado a dispositivos móviles, comparándolas

con otras, almacenadas en una base de datos. Las operaciones las realiza directamente

en el dispositivo móvil Iphone. Mediante el algoritmo de reconocimiento de imagen,

extrae las características necesarias de la imagen captada, comparándolas con otras

almacenadas en una base de datos local del sistema, si es encontrada, se procede a la

realización de la realidad aumentada.

Santoso realiza en [31] una aplicación mediante el uso de la realidad aumentada móvil

en la enseñanza, genera una aplicación basada en el juego tangram.

Jaegeol Yim muestra en [32] un artículo denominado Implementation of Building Re-

cognition Android App explica el desarrollo de una aplicación de reconocimiento de

9

edi�cios utilizando mapas electrónicos. En una base de datos local se tienen alma-

cenados los datos de localización de determinados edi�cios, mediante el dispositivo

móvil se toma una fotografía del entorno, también se captura la posición del dispo-

sitivo, a través de un algoritmo de reconocimiento de objetos se calcula la distancia

entre el dispositivo y el entorno captura y al comparar con los datos almacenados

en la base se obtiene el edi�cio que es observado y se muestra un video relacionado

con el mismo. La investigación surge de los errores de posicionamiento existentes al

utilizar la geolocalización en los dispositivos móviles, se comprueba que a través de

este procedimiento se evitan esos fallos.

En la actualidad se desarrollan aplicaciones de realidad aumentada empleando diversas

técnicas de reconocimiento de imágenes dependiendo el entorno donde se ejecutará la

aplicación, los principales objetivos de las investigaciones son: reducir los tiempos de

ejecución, reducir las capacidades de procesamiento y adaptarlas al dispositivo sobre

el que se ejecutarán, así como tener un óptimo reconocimiento de los marcadores

empleados y utilizar bases de datos que permitan un rápido acceso a la información.

1.8. Estructura general de la tesis

A continuación se menciona la organización del presente documento. En el capítulo

1 se presenta la introducción al proyecto. En el capítulo 2 se describen los conceptos

generales para el conocimiento de las características principales de los dispositivos

móviles y de la realidad aumentada. En el capítulo 3 se propone la arquitectura global

del framework así como la descripción de cada uno de los módulos que lo componen. En

el capítulo 4 se determina e implementa el algoritmo de reconocimiento de imágenes

y se explica la obtención de la información de geolocalización. En el capítulo 5 se

presenta el módulo de almacenamiento de datos. En el capítulo 6 se describe el módulo

de captura y edición de video. El capítulo 7 contiene las pruebas de funcionamiento y

los resultados obtenidos de la implementación del framework. Finalmente en el capítulo

8 se presentan y describen las conclusiones y trabajos futuros.

10

Capítulo 2

Marco teórico

La creciente demanda de comunicación entre las personas y localización de lugares, así

como la fácil adquisición de dispositivos móviles ha permitido el auge de aplicaciones

novedosas y de gran utilidad para el usuario, las cuales emplean al máximo los recursos

de los dispositivos, entre ellas la realidad aumentada. En este capítulo se muestra la

teoría que fundamenta al proyecto con base en la propuesta de solución.

2.1. Arquitectura de software

De acuerdo con la norma ISO/IEC/IEEE 42010 expuesta en [33] la arquitectura son

los conceptos fundamentales o propiedades de un sistema en un entorno que combina

sus elementos, relaciones y los principios de su diseño y evolución.

2.2. Framework

La de�nición de framework que establece la norma ISO/IECIEEE 42010 en [33] esta-

blece que un framework son las convenciones, principios y prácticas para la descripción

de arquitecturas, establecidos dentro de un dominio especí�co de aplicación o dentro

de un conjunto de elementos similares.

11

2.3. Dispositivos móviles

La tecnología móvil tiene como objetivos desarrollar dispositivos cada vez más peque-

ños y portables, así como incrementar su capacidad y la velocidad de procesamiento.

En [34] se de�ne al dispositivo móvil como un aparato portable, con velocidad de

procesamiento, acceso a redes WiFi, memoria limitada, diseñado especí�camente para

una función, pero que puede llevar a cabo otras funciones generales, la presente in-

vestigación se enfocará en los smartphones y tabletas por ser los dispositivos móviles

que se emplean en la actualidad.

2.3.1. Características de los dispositivos móviles

Algunos elementos utilizados para clasi�car los dispositivos móviles y que son de uti-

lidad para determinar el tipo de dispositivos sobre los que tendrá un mejor funcio-

namiento el framework a realizar, fueron propuestos por Arroyo en [35] y son los

siguientes:

Visualización: Esta característica permite que el usuario visualice el contenido

mediante los siguientes tres aspectos:

a) Profundidad del color: cantidad de bits necesarios para representar el color

de un pixel y se mide en bits por pixel (bpp).

b) Tecnología de la pantalla: in�uye en la comodidad para el manejo del

dispositivo, para facilitar la lectura del contenido o para el desplazamiento

dentro del mismo. Las pantallas táctiles son las mayormente producidas en

la actualidad.

c) Tamaño de la pantalla: oscila entre las 2 pulgadas en los teléfonos móviles

y las casi 10 pulgadas de algunas tabletas, esta característica in�uye en la

forma en que el usuario observará la información y la facilidad con la cual

podrá analizar el contenido presente en alguna aplicación.

12

Interacción: Es la característica que permite la comunicación entre el usuario

y el dispositivo. El teclado que emplean los dispositivos puede ser alfanuméri-

co, Qwerty, de pantalla táctil o teclado virtual. Las pantallas táctiles permiten

interacción directa con el sistema de navegación.

Conectividad: Relacionada principalmente con la conectividad WiFi, presente en

la mayoría de dispositivos móviles en la actualidad. No debe existir falla en la

conectividad para que el sistema de navegación funcione adecuadamente.

2.3.2. Sistemas operativos para dispositivos móviles

Es el software básico de un dispositivo que provee una interfaz entre las aplicaciones

instaladas, hardware y el usuario. Su función principal es administrar los recursos del

dispositivo, coordinando el Hardware y organizando la información. Así el sistema

operativo determina el funcionamiento del dispositivo y la e�ciencia que presenta al

ejecutar alguna aplicación. A continuación se describen los sistemas operativos para

dispositivos móviles de mayor relevancia.

Symbian OS. Producido por la alianza de varias empresas de telefonía móvil, dentro

de las que destaca Nokia, Sony Ericsson, Samsung. En 2001 surge la primera versión

para dispositivos móviles. En [34] se indica su principal virtud como la capacidad que

tiene el sistema para adaptar e integrar todo tipo de aplicaciones. Ofrece las rutinas,

los protocolos de comunicación, el control de archivos y los servicios para el correcto

funcionamiento de estas aplicaciones.

Windows phone. Surge en 2010 como sucesor de la versión Windows Mobile desa-

rrollada por Microsoft. En [34] se expone como un sistema operativo móvil compacto,

se basa en el núcleo del sistema operativo de Windows CE. Está diseñado para ser

similar a las versiones de escritorio de Windows.

Android. Surge en 2008, en [34] se indica que inicialmente se diseñó para dis-

positivos móviles, también es usado para tabletas, se basa en Linux. Su estructura

se compone de aplicaciones que se ejecutan en un framework JAVA de aplicaciones

13

orientadas a objetos sobre el núcleo de las bibliotecas de JAVA en una maquina virtual

Dalvik.

iOS para iPhone. Desarrollado por Apple originalmente para el iPhone en el año

2007. Se utiliza en el iPod Touch e iPad. Derivado de Mac OS X. En 2008 se liberó un

SDK descargable gratuito que permite hacer aplicaciones para iPhone, aunque primero

se requiere pagar una cuota del iPhone Developer Program.

Blackberry OS. Surge en 1999 con los primeros Handheld. Desarrollado por la

empresa canadiense RIM (Research In Motion) para sus dispositivos. En [34] se des-

cribe como un sistema que permite multitarea y tiene soporte para diferentes métodos

exclusivos de RIM (trackwheel, trackball, touchpad y pantallas táctiles).

2.3.3. Comparativa entre sistemas operativos móviles

La Tabla 2.1 muestra una comparativa del Kernel y la conectividad entre los diversos

sistemas operativos móviles listados anteriormente.

Tabla 2.1: Análisis de los sistemas operativos de los dispositivos móvilesSistema Operativo Kernel Conectividad

Android Linux con máquina virtual Dalvik 3G, WiFi, GSM, GPRS

Blackberry OS Propietario 3G, WiFi, GSM, CMDA

iOS de iPhone OS X 3G, WiFi, GSM

Windows Phone Windows CE 3G, WiFi, GSM, CMDA

Symbian Symbian OS 3G, WiFi, GSM

Es importante conocer el kernel del dispositivo debido a que es el núcleo del sistema

operativo y se encarga de gestionar los recursos del sistema. En la Tabla 2.1 se observa

que el kernel de Android se basa en Linux por lo que es un sistema operativo de código

abierto y permite a los desarrolladores generar aplicaciones que combinen servicios y

librerías que la arquitectura de android ofrece (ver Anexo A).

14

2.4. Realidad aumentada

En el año de 1994 Paul Milgram y Fumio Kishino en [36] de�nen la realidad de

Milgram-Virtuality Continuum (Figura 2.1) como un entorno que se observa desde

la parte real hasta la parte virtual de modo continuo, en la parte media del entorno

se encuentra la realidad mixta que es la mezcla entre ambos entornos. La realidad

aumentada es la parte más cercana a la realidad, con ciertos aspectos virtuales como

se observa en la Figura 2.1.

Figura 2.1: Realidad de Milgram-Virtuality Continuum

En 1997, Ronald Azuma establece el punto de partida para las investigaciones de

realidad aumentada al elaborar el primer estudio realizado sobre la realidad aumentada

expuesto en [37] donde describe las 3 principales características con que deben contar

los sistemas que hagan uso de ella: a) Combinación de elementos virtuales y reales,

b) interactividad en tiempo real y c) la superposición de información en 3D.

En el 2005, Oliver Bimber en su trabajo �Spatial augmented reality merging real and

virtual worlds� mencionado en [1] de�ne a los sistemas de realidad aumentada como

aquellos sistemas que mezclan información virtual de cualquier tipo, desde imágenes

2D, texto o �guras 3D con un escenario físico real.

2.4.1. Tareas de la realidad aumentada

De acuerdo con [2] existen cuatro tareas principales que se llevan a cabo al realizar la

realidad aumentada:

a) Captación del entorno: Encargada de capturar el entorno en el cual se super-

pondrá la información virtual. Requiere de un dispositivo que permita reconocer

la escena para después procesarla. En el caso de los dispositivos móviles es la

cámara la encargada de realizar ésta tarea.

15

b) Identi�cación del entorno: Esta tarea se encarga de identi�car qué aspecto del

entorno capturado es el que será aumentado con la información virtual. Este

proceso puede ser realizado mediante reconocimiento de marcadores, estimación

de la posición o por una identi�cación híbrida la cual es una mezcla de ambas.

c) Aumento de la realidad: Es la tarea encargada de superponer la información

virtual (texto, imagen, video o audio) en el entorno real capturado.

d) Visualización: Es el último proceso que se realiza de la realidad aumentada, con-

siste en mostrar el escenario aumentado al usuario por medio de un dispositivo

de visualización.

2.4.2. Tipos de realidad aumentada

Según lo planteado por [26] existen dos tipos principales de realidad aumentada que

pueden llevarse a cabo:

Reconocimiento por marcadores.

Identi�cación por posicionamiento.

a) Reconocimiento por marcadores : Un marcador es una imagen reconocida por el

software de realidad aumentada. Este reconocimiento se realiza por medio de su

geometría, color o ambas características. Un sistema adecuado de reconocimien-

to de marcadores cuenta con un sensor que recoge la imagen del mundo real,

un mecanismo de extracción de características el cual obtiene la información de

utilidad y elimina aquella irrelevante para el procesamiento, por último una etapa

de toma de decisiones para el reconocimiento del marcador y la interpretación

de la escena.

a.1) Reconocimiento de imágenes: Es el proceso que consiste en extraer de una

imagen o un segmento de video la información necesaria del entorno para

identi�car la región a la cual se realizará la superposición de elementos vir-

tuales. Éste proceso se realiza principalmente por medio de visión arti�cial,

en el caso de reconocimiento de escenarios de manera automática o por

medio de marcadores, los cuales ya están preestablecidos en el sistema. Se

16

divide en dos partes principales, la adquisición de la imagen por medio de

cualquier dispositivo especializado y el procesamiento digital de la imagen

capturada, para obtener una imagen con características mejor de�nidas

para su interpretación.

b) Identi�cación por posicionamiento: La identi�cación de entorno mediante este

proceso se realiza gracias a la estimación de la posición y orientación del usua-

rio. Existen sistemas de posicionamiento que brindan la información necesaria

al dispositivo para realizar este tipo de realidad aumentada. El Sistema de Po-

sicionamiento Global (GPS) es un servicio de los EE.UU. que proporciona a los

usuarios información sobre navegación, posicionamiento y cronometría.

17

Página intencionalmente en blanco

18

Capítulo 3

Arquitectura del framework

3.1. Arquitectura de referencia

La arquitectura propuesta por Bernd Brüegge en [24] se basa en el análisis de 16

sistemas de realidad aumentada, con lo que concluye que a pesar de que los sistemas

de realidad aumentada tengan enfoques diferentes comparten una estructura básica

y genera un modelo de referencia con la unión de 6 módulos de información donde

cada uno realiza una actividad especí�ca de la realidad aumentada. Los módulos son

los siguientes:

a) Aplicación: Se encarga de la lógica del sistema, proporciona la funcionalidad del

usuario �nal y es la encargada de la secuencia de arranque del sistema.

b) Tracking: Es uno de los módulos principales de la arquitectura. Por medio de

diversas técnicas como: Rastreo de video, rastreo magnético, GPS, seguimiento

inercial, seguimiento externo del entorno. Puede utilizar el modelo del mundo

para obtener información del entorno. Los resultados se extienden al manejador

del contexto o a la interfaz de salida.

c) Entrada del usuario: Realiza el procesamiento de entrada de la información donde

los datos de entrada se envían a un procesador para después ser transmitidos al

manejador del contexto o al módulo de aplicación.

d) Salida de usuario: Es la interfaz de usuario donde se presentan los resultados ya

sean grá�cos en 3D, texto, voz o sonido.

19

e) Manejador del contexto: Es un sistema abstracto que cuenta con un componente

de gestor de contexto, el cual recoge diferentes tipos de información de contexto

como: las preferencias del usuario, datos de sensores, el tiempo, el seguimiento

de la fecha, información de recursos, dominio del conocimiento o el conocimiento

de la situación actual del usuario.

f) Modelo del mundo: Proporciona información sobre el mundo alrededor del usua-

rio se compone de escenas, colecciones de objetos virtuales, seguidores de in-

formación y representaciones de objetos del mundo real. En la Figura 3.1 se

muestra el modelo de referencia de la arquitectura, se identi�can los módulos

que componen la arquitectura y las relaciones de dependencia que existen entre

ellos, éstas dependencias indican que módulos dependen de los datos y de la

funcionalidad de otro.

Figura 3.1: Arquitectura de referencia propuesta por Brüegge

Para determinar el nivel de abstracción que tiene la arquitectura de referencia propuesta

por Brüegge, se basó en los 4 diferentes signi�cados del término arquitectura de

software identi�cados por Hofmeister en [38], los cuales son los siguientes:

20

a) Arquitectura de software (aplicación): Describe la arquitectura de una aplicación

especí�ca.

b) Arquitectura de línea de productos: Describe una arquitectura para un conjunto

de productos la cual con modi�caciones mínimas puede adaptarse a aplicaciones

similares.

c) Arquitectura de dominio especí�co: Describe la arquitectura de sistemas o sub-

sistemas con un dominio especí�co, puede emplearse como punto de partida

para el desarrollo de aplicaciones del mismo dominio.

d) Arquitectura de estilo: Describe una solución general a nivel de diseño.

Brüegge de�ne a un framework como una arquitectura más una implementación par-

cial, al enfocar ésta de�nición a los términos de arquitectura de software identi�cados

por Hofmeister se tienen los siguientes tipos de frameworks:

a) Framework de dominio de aplicación: Provee componentes y estructuras reuti-

lizables para un conjunto de aplicaciones similares.

b) Framework de dominio de solución: Implementa parte de la arquitectura y pro-

porciona parte de la solución para sistemas con un dominio especí�co.

c) Framework de arquitectura de estilo: Soporta el empleo de estilos de diseño.

En cuanto a la arquitectura de software de aplicación no existe un framework debido a

que una arquitectura para una aplicación especí�ca no puede ser reutilizable. La arqui-

tectura de referencia propuesta por Brüegge se basa en el desarrollo de un framework

de dominio de solución, ya que el dominio especí�co de la arquitectura es la realidad

aumentada.

21

3.2. Arquitectura propuesta

Con base a la arquitectura de referencia y enfocada a los requerimientos del framework,

se generó la arquitectura de la Figura 3.2, la cual mantiene los módulos utilizables.

Figura 3.2: Arquitectura del framework

A continuación se describe cada uno de los módulos que componen la arquitectura

del framework propuesto en el presente trabajo de investigación.

Aplicación La Figura 3.3 muestra la relación del módulo con el framework. Consiste

en el código especí�co de la aplicación, es la forma en que interactúa la aplicación con

el framework. Se encuentra relacionado con el módulo de almacenamiento de datos

debido a que necesita del manejador para poder accesar a la información de los datos

guardados y con el módulo de captura y edición de video para obtener el video y

visualizar la información en pantalla.

22

Figura 3.3: Módulo de aplicación

Procesamiento Puede utilizar el módulo de almacenamiento de datos para obtener

información del entorno por medio del manejador. Los resultados van dirigidos al

módulo de captura y edición de video para visualizar la información resultante de

procesamiento. Está dividido en dos elementos: GPS, obtiene la información de la

geolocalización del dispositivo y de los marcadores cuando se almacenan y SURF el

cual es el encargado de realizar el procesamiento de imágenes ya sea de los marcadores

almacenados o de la captura de video. Su composición y relaciones se muestran en la

Figura 3.4.

Figura 3.4: Módulo de procesamiento

Almacenamiento de datos Este módulo es el encargado de almacenar la infor-

mación del entorno que se obtiene del módulo de procesamiento a través de la clase

Procesamiento, así como permitir el acceso a la información del módulo de captura

y edición de video para mostrarse en la vista de la aplicación por medio de la clase

Salida. Las relaciones entre el módulo y el framework se muestra en la Figura 3.5.

23

Figura 3.5: Módulo de almacenamiento de datos

Captura y edición de video Es el módulo que se encarga de obtener la información

de video para ser procesado por el módulo de procesamiento a través de la clase

Procesamiento y mostrar la información que se obtiene aumentando la información

del módulo de almacenamiento de datos por medio de la clase Manejador, la cual se

visualiza en la pantalla de la aplicación a través de la clase Aplicación. La interacción

del módulo con el framework se muestra en la Figura 3.6.

Figura 3.6: Módulo de captura y edición de video

En el Anexo A se muestra el diagrama de clases de la arquitectura que se generó

al realizar ingeniería inversa al framework desarrollado por medio de la herramienta

Enterprise Architect 6.5 en la versión de evaluación.

24

Capítulo 4

Módulo de procesamiento

El módulo de procesamiento se basa en la combinación de dos técnicas para obtener

las características necesarias para la detección de marcadores: el reconocimiento de

imágenes y la geolocalización.

En el presente capítulo se explica el proceso de implementeción del algoritmo de

procesamiento de imágenes utilizado en el framework y como se obtiene la localización

del dispositivo móvil, así como los resultados obtenidos de las pruebas realizadas para

comprobar el funcionamiento del módulo.

4.1. Algoritmo de procesamiento de imágenes

En el artículo �De�nición y descripción de un pixel� mostrado en [39] se explica que

las imágenes digitales se forman por la unión de pixeles, los cuales son la unidad

mínima en color de las imágenes. El color especí�co de un pixel es la combinación de

tres componentes del espectro de color: rojo, verde y azul, por tal motivo cualquier

algoritmo de procesamiento de imágenes debe trabajar sobre las características de los

pixeles.

En [40], Boullosa de�ne a los descriptores visuales como aquellos que describen las

características visuales de los contenidos de imágenes o videos. Se dividen en dos tipos

principales: a) Descriptores de información general, los cuales proporcionan informa-

ción relacionada con formas, colores o regiones de una imagen y b) los descriptores

25

de información de dominio especí�co los cuales proporcionan información de objetos

que forman una escena.

Los descriptores de información general se dividen de acuerdo al procesamiento que

realizan: a) Descriptores globales, generan un único vector de características de la

imagen y b) los descriptores locales, actúan sobre regiones de interés en especí�co

para generar un vector de características por cada región procesada.

4.1.1. Determinación del algoritmo de procesamiento de

imágenes

Se realizó un análisis de los trabajos de investigación relacionados con el desarrollo e

implementación de algoritmos para el reconocimiento de imágenes para la elección del

algoritmo a implementar.

En [41], Romero y Cazorla muestran una comparativa de detectores de características

visuales y su aplicación al SLAM (Simultaneous Localization and Mapping) el cual

trata de resolver la problemática de estimar la posición de un robot y el mapa de su

entorno. La solución a lo anterior se realiza mediante la implementación de algoritmos

de extracción de caracteres, de los cuales en el presente trabajo de investigación se

realiza una comparativa del funcionamiento de dos de ellos: SIFT (Scale Invariant

Features Transforms) y SURF (Speeded Up Robust Features), también se desarrolla

un algoritmo para el emparejamiento de las imágenes.

La muestra empleada fue de 109 imágenes de un edi�cio, la Tabla 4.1 muestra el resul-

tado de la implementación de los algoritmos en un extracto de las 10 imágenes iniciales.

Las medias obtenidas de los puntos invariantes obtenidos son para SIFT=1292.01 y

SURF=482.69, mientras que la media del tiempo empleado es para SIFT=1646.53ms

y para SURF=485.77ms. De los datos anteriores se observa que el algoritmo SIFT

cuenta con mayor cantidad de puntos invariantes detectados y SURF cuenta con ma-

yor velocidad al realizar el procesamiento. Se concluye que el algoritmo SURF cuenta

con mayor velocidad de ejecución, sin embargo hace un reconocimiento de menos

puntos característicos, mientras que SIFT incrementa casi al doble la velocidad de

procesamiento empleada por SURF y aunque se detectan más puntos característi-

cos existe repetibilidad entre los puntos que se detectan por lo tanto el uso de cada

algoritmo depende de los objetivos de su implementación.

26

Tabla 4.1: Extracto de la comparativa de funcionamiento entre el algoritmo SIFT ySURF expuesto en [41]

Imagen Puntos SIFT Puntos SURF Tiempo SIFT (ms) Tiempo SURF (ms)

imagen1 958 397 1528 420

imagen2 1046 405 1540 430

imagen3 1251 451 1656 466

imagen4 1395 499 1712 543

imagen5 1408 468 1808 463

imagen6 1262 491 1632 453

imagen7 1292 431 1668 450

imagen8 1285 433 1596 405

imagen9 1528 529 1736 476

imagen10 1399 493 1708 476

Con base a los resultados de la investigación se concluyó que si se genera una aplica-

ción donde es primordial minimizar los tiempos de ejecución, se recomienda emplear

el algoritmo SURF, en cambio si se genera una aplicación donde lo primordial sea

la cantidad de puntos de interés detectados sin importar el tiempo que se requiera

entonces se recomienda emplear el algoritmo SIFT.

En [42], Ballesta, Gil, Reinoso y Úbeda realizan un análisis comparativo entre diver-

sos extractores de características (un detector de puntos signi�cativos y un descriptor

local) con la �nalidad de obtener el extractor que tenga mejor rendimiento. Los algo-

ritmos de detección de puntos que se evaluaron son: Harris Corner Detector, Harris

Laplace, SUSAN (Smallest Univalue Segment Assimilating Nucleus), SIFT y SURF.

Los descriptores locales que se evaluaron son: SIFT, SURF, ventana de niveles de

grises, histograma de orientación y momentos de Zernike. Los factores a evaluar en la

comparativa, fueron los siguientes: cambio de ángulo, cambio de iluminación, escena

de movimiento, variación de zoom, escena global. Con respecto a la detección de pun-

tos signi�cativos de acuerdo al análisis que se realizó, el algoritmo que presentó mejor

rendimiento fue el de Harris Corner Detector seguido por Harris Laplace, SIFT, SURF

y SUSAN tanto para imágenes en interiores como en exteriores. En la comparativa

de descriptores locales el resultado en orden descendente en base al rendimiento es el

siguiente: SURF, SIFT, Histogramas, Zernike y ventana de niveles.

En [40], Boullosa realizó una comparativa entre diversos descriptores visuales con

el objetivo de detectar escenas cuasi-duplicadas. El estudio divide a los descriptores

de características como globales (los cuales resumen la imagen en un solo vector de

27

características) y locales (actúan sobre regiones de interés), en ellos se comparó el

comportamiento de 6 diversos descriptores, los cuales son: histogramas HSV (Hue,

Saturation y Value), histogramas RGB (Red, Green y Blue), Color layout, Correlogra-

ma, SIFT y SURF.

La Tabla 4.2 muestra las ventajas e inconvenientes que cada descriptor presenta de

acuerdo a sus propios autores, lo cual sirve de base para analizar los casos de estudio

donde pueden emplearse. Histograma de color, Color layout y Correlograma cuentan

con bajo costo computacional, sin embargo al depender de la distribución de colores en

la imagen son susceptibles ante cambios de iluminación, mientras que los algoritmos

SURF y SIFT presentan invarianza ante cambios de rotación, escala e iluminación y

translación aunque tienen mayor costo computacional.

Tabla 4.2: Ventajas e inconvenientes de los descriptores analizados en [40]Descriptor Ventajas Inconvenientes

Robusto a cambios de escala No incluye información espacial.

Histograma o pequeños movimientos. Dos imágenes distintas pueden tener

de color Invariante a la rotación sobre los ejes. similares histogramas.

Bajo costo computacional. Susceptible a cambios de iluminación.

Color Layout

Rapidez y repetibilidad. Efecto bloque

Poca complejidad del proceso Solo analiza correlacion entre

de comparación. pixeles del mismo bloque.

CorrelogramaIncluye información espacial sobre Costo computacional elevado.

la distribución de los colores.

SIFT

Invarianza respecto a rotación, Costo computacional elevado.

translación, escala y Depende del tamaño de la imagen.

cambios de iluminación.

SURFMayor robustez y velocidad

Depende del tamaño de la imagen.de cálculo que SIFT.

La Tabla 4.3 muestra los resultados de una comparativa entre el costo computacional

de la implementación de los descriptores y los tiempos de ejecución, existe una amplia

diferencia entre los descriptores globales y locales en el aspecto del coste computacional

debido a que los segundos requieren mayor procesamiento debido al procesamiento que

requieren para mantener la invarianza ante cambios de rotación, translación, escala e

iluminación.

28

Tabla 4.3: Costo computacional de los descriptores analizados en [40]

DescriptorTiempo de Tiempo de Tamaño del

creación (ms) comparación (ms) descriptor

Histograma RGB 130 6 384-1536 bytes

Histograma HSV 290 5.4 96-384 bytes

Color Layout 60 2.5 768 bytes

Correlograma 9800 5.5 960 bytes

SIFT 7100 600 470 Kb

SURF 350 125 100 Kb

Como conclusión del estudio los descriptores que obtuvieron mejor rendimiento fueron

SIFT e histograma HSV, SURF, después Histograma RGB y Color layout y por último

Correlograma, cabe mencionar que el autor aclara que los resultados que se obtienen

de los descriptores depende en gran parte del contenido de la base de datos y que la

implementación de los descriptores depende de las necesidades del sistema y de las

capacidades del hardware en que se implemente.

Con base en el análisis de los algoritmos de procesamiento de imágenes anterior se

seleccionó la implementación del algoritmo SURF el cual se basa en la detección de

puntos de interés invariantes ante cambios de iluminación, rotación, escala y trans-

lación, para el procesamiento de imágenes que realizará el framework debido a su

robustez ante la invarianza de cambios de iluminación, rotación y escala, así como

presentar mejor velocidad de procesamiento y detección de puntos de interés en com-

paración a descriptores similares.

4.1.2. Implementación del algoritmo SURF

Lo desarrolló Herbert Bay [43] como un detector de puntos de interés y descriptor de

características robusto. Las características principales que brinda son: invariancia ante

la escala, orientación y distorsión afín así como invariancia parcial a los cambios de

iluminación. De acuerdo al artículo de Evans [44] el algoritmo se encuentra dividido

en 3 etapas principales y el emparejamiento de los puntos de interés localziados en

dos imágenes:

Imágenes integrales: es uno de los principales aportes que utiliza el algoritmo,

debido a que contribuyen a una mejora en el funcionamiento. Dada una imagen

29

de entrada y un pixel de esa imagen, la imagen integral se calcula como la suma

de los pixeles comprendidos entre el punto y el origen.

Detector basado en la matriz Hessiana: se basa en el determinante de la matriz

Hessiana para la localización y escala de los puntos, se emplea por su rendimiento

en la velocidad de cálculo y precisión.

Descriptor: es un vector de características que se calcula sobre una pequeña

región de interés de la imagen, en el caso del descriptor SURF, muestra como

la intensidad de los pixeles se distribuye dentro de una escala dependiente de la

vecindad de cada punto de interés que detectó la Hessiana.

Emparejamiento de puntos de interés: correspondencia de los puntos de interés

identi�cados en dos imágenes.

La Figura 4.1 muestra el diagrama de �ujo del algoritmo SURF, donde la conversión

de la imagen a escala de grises se realiza al momento de calcular la imagen integral, el

detector de puntos de interés se divide en: cálculo del determinante de la matriz hes-

siana, cálculo del espacio-escala, supresión de puntos debajo de un umbral, supresión

de no máximos en un vecindario de 3x3x3 y la interpolación en escala y posición. El

cálculo del descriptor de puntos de interés se divide en la asignación de la orientación

y cálculo de los componentes del descriptor.

30

Figura 4.1: Diagrama de �ujo algoritmo SURF

A continuación se describe el funcionamiento e implementación de las etapas del

algoritmo SURF.

Imágenes integrales: El uso de imágenes integrales lo introduce Paul Viola y Mi-

chael Jones en el artículo [45] de nombre �Rapid Object Detection using a Boos-

ted Cascade of Simple Features�, las cuales permiten una rápida evaluación de

características de una imagen. Son empleadas por que permiten disminuir la

cantidad de operaciones al realizar cálculos en el detector y descriptor SURF.

La imagen integral en el pixel x,y contiene la suma de los pixeles arriba y a la

izquierda del punto, expresado en la ecuación 4.1.

I∑ (x,y) =i<=x

∑i=0

j<=y

∑j=0

I(x,y) (4.1)

31

Donde I(x,y) es la imagen original y I∑(x,y) es la imagen integral. Para el cálculo de

la imagen integral se emplean las operaciones descritas en 4.2 y 4.3.

s(x,y) = s(x,y−1)+ I(x,y) (4.2)

I∑(x,y) = I∑(x−1,y)+ s(x,y) (4.3)

Donde s(x,y) es una suma acumulativa y las funciones cuentan con los valores iniciales

descritos en 4.4 y 4.5.

s(x,−1) = 0 (4.4)

I∑(−1,y) = 0 (4.5)

Implementación de la imagen integral: La imagen integral es un arreglo del

mismo tamaño de la imagen original, en el cual cada posición contiene el valor

de la sumatoria de todos los pixeles arriba y a la izquierda de la imagen original.

Para su implementación se realiza inicialmente un recorrido de la imagen a lo

ancho, inicializando la sumatoria de los elementos en cero, en seguida el recorrido

se realiza a lo alto de la imagen, dentro del cual para cada elemento se obtiene

el valor en escala de gris del pixel a evaluar y se añade a la sumatoria �nal, si el

valor de la columna es mayor a 0 entonces el elemento de la imagen integral es

igual al valor del pixel de la columna anterior más la sumatoria, en otro caso el

elemento de la imagen integral es igual a la sumatoria.

Al implementar la imagen integral se disminuye la cantidad de cálculos que se realizan

en los pasos siguientes del algoritmo, por ejemplo para realizar la sumatoria de un área

rectangular dentro de la imagen, considerando los puntos seleccionados en la Figura

4.2, en vez de sumar cada uno de los elementos, únicamente se tendrán que realizar

las operaciones que se muestran en la ecuación 4.6 lo cual disminuye la cantidad de

cálculos.

∑ = A+D− (B+C) (4.6)

32

Figura 4.2: Cálculo de la imagen integral

Detector basado en la matriz Hessiana: Dado un punto p=(x,y) de la imagen

I, la matriz Hessiana H(p,σ) del punto p que pertenece a la escala σv se de�ne

por 4.7.

H(p,σ) =

[Lxx(p,σ) Lxy(p,σ)

Lxy(p,σ) Lyy(p,σ)

](4.7)

Donde Lxx(p,σ) es la convolución de la derivada parcial de segundo orden de la

Gaussiana en el punto p y escala σ .

Las gaussianas se emplean en el análisis del espacio-escala debido a su desempeño en

la localización de puntos de interés, en el desarrollo del algoritmo SURF se propone

la implementación de �ltros de caja para brindar una aproximación de las derivadas

parciales de segundo orden de las gaussianas para ser evaluadas rápidamente con el

uso de las imágenes integrales.

En la Figura 4.3 se muestra la aproximación propuesta en el algoritmo SURF para las

derivadas parciales de segundo orden de las gaussianas por medio de �ltros de caja,

donde el área en gris representa el valor de 0. Debido a que las áreas se encuentran

de�nidas con valores ya de�nidos en los �ltros de caja, existe un incremento en la

velocidad de cálculo en conjunción al empleo de las imágenes integrales.

33

Figura 4.3: Aproximación de las derivadas parciales de segundo orden de las gaus-sianas empleando �ltros de caja. Izquierda: derivadas parciales de segundo orden de las

gaussianas. Derecha: aproximación por �ltros de caja.

Para el cálculo del determinante de la Hessiana, Bay en [43] propone la ecuación 4.8,

donde se emplea el �ltro de 9 x 9 como �ltro inicial con σ = 1.2 que representa la

mínima escala del mismo. Con relación a la Figura 4.2, se denota Dxx, Dyy y Dxy

como las aproximaciones a utilizar.

det(Haprox) = DxxDyy−w2D2xy (4.8)

donde w=0.9, cuyo valor se utiliza para balancear la expresión del determinante de

la Hessiana, para permitir que la respuesta del �ltro esté normalizada con respecto

al tamaño de la máscara para garantizar una norma de Frobenius constante para

cualquier tamaño de �ltro.

Para el cálculo del determinante de la Hessiana se emplea el proceso propuesto en [46]

por Han, Jia y Wang donde se optimiza el algoritmo SURF, en la Figura 4.4 se asigna

un nombre a cada región en color negro y blanco.

34

Figura 4.4: Aproximación de las derivadas parciales de segundo orden de las gaussianasmediante imágenes integrales

Para el cálculo de Dxx, Dyy de la ecuación 4.8, de acuerdo a la Figura 4.4 y tomando

en cuenta los valores que se asignaron a las aproximaciones en la Figura 4.3, las

operaciones a realizar están descritas en 4.9.

Dxx(oDyy) = Sum1−2xSum2 +Sum3 (4.9)

Y para Dxy descrita en 4.10.

Dxy = Sum1−Sum2−Sum3 +Sum4 (4.10)

Figura 4.5: Asignación de puntos en las sumatorias en Dxx y Dyy

En la Figura 4.5 se observan los puntos que representan los limites de cada sumatoria

y se les asigna un valor en especí�co, se utilizó la Figura 4.2 y la ecuación 4.6 del

cálculo de las imágenes integrales, se obtiene que para el cálculo de las sumatorias se

realizan las siguientes operaciones, desglozando los elementos de la ecuación 4.9 en

4.11, 4.12 y 4.13.

35

Sum1 = A+D− (B+C) (4.11)

Sum2 =C+F− (D+E) (4.12)

Sum3 = E +H− (F +G) (4.13)

Reagrupando 4.11, 4.12 y 4.13 y sustituyéndolas en 4.9 se obtiene la ecuación 4.14.

Dxx(oDyy) =(A−B)+(D−C)+(D−C)+(D−C)+

(E−F)+(E−F)+(E−F)+(H−G)(4.14)

Se de�nen las siguientes variables descritas en 4.15 y 4.16.

X1 = D−C (4.15)

X2 = E−F (4.16)

Se sustituyen 4.15 y 4.16 en 4.14 lo que genera la ecuación descrita en 4.17 que es la

ecuación a implementar en el algoritmo para el cálculo de Dxx o Dyy.

Dxx(oDyy) = (A−B)+X1 +X1 +X1 +X2 +X2 +X2 +(H−G) (4.17)

Para detectar los puntos de interés por medio del determinante de la matriz Hessiana,

se requiere emplear el espacio-escala, el cual comúnmente se representa en forma

piramidal como se observa en la Figura 4.6 donde en el lado izquierdo una imagen

se convoluciona iteradamente con las gaussianas con lo cual se disminuye el tamaño

de la imagen en cada iteración, en el lado derecho se presenta el caso de SURF

donde el tamaño de la imagen se mantiene constante siendo el �ltro el que se escala

repetidamente.

36

Figura 4.6: Pirámide del �ltro

En SURF el espacio-escala se divide en octavas e intervalos, donde una octava re-

presenta una serie de imágenes de respuesta y un intervalo representa la cantidad de

imágenes de respuesta en cada octava. El tamaño del �ltro se calcula mediante la

ecuación 4.18.

Tam f iltro = 3(2oct x int +1) (4.18)

donde, oct=número de octavas e int=número de intervalos para cada octava, con

lo cual se implementa un arreglo bidimensional de estructuras de imagen de tamaño

(octava)*(intervalo). Por ejemplo, para analizar el espacio-escala entre 3 octavas y 4

intervalos, se crea un arreglo de 12 estructuras de imágenes (ver Figura 4.7) el eje

vertical representa las octavas y el eje horizontal la escala a la que se obtiene, el valor

dentro de cada recuadro es el tamaño del �ltro a emplear.

Figura 4.7: Representación grá�ca de la longitud de los �ltros de diferentes octavas

Por último para localizar los puntos de interés en la imagen se eliminan los puntos

que no cumplan con la condición de ser los máximos en un vecindario de 3x3x3. El

máximo determinante de la matriz Hessiana se interpola en escalas e imágenes con el

método propuesto por Brown en [47].

37

Para determinar la invarianza ante la escala y la rotación como paso inicial se eliminan

los puntos que se encuentran por debajo de un umbral establecido, si el punto es mayor

al umbral se hace una supresión de no máximos dentro de un vecindario de 3x3x3,

esto es que dentro de cada octava se compara cada punto calculado en un intervalo

con el punto en un intervalo mayor y uno menor, si el punto es mayor que los puntos

comparados entonces se realiza una interpolación entre las diferentes escalas a través

de la ecuación 4.19 propuesta por Brown en [47].

x =δ 2H−1

δx2δHδx

(4.19)

donde δ 2H−1

δx2 es la matriz de 3x3 descrita en 4.20 y δHδx por un vector de 3x1 descrito

en 4.21.

δ 2H−1

δx2 =

dxx dyx dsx

dxy dyy dsy

dxs dys dss

(4.20)

δHδx

=

dx

dy

ds

(4.21)

donde x e y representan el espacio y s representa la escala a la que fue encontrado el

punto, ésto para encontrar los puntos de interés sobresalientes.

Implementación del detector: Para la detección de los puntos de interés se re-

quiere el cálculo del determinante de la matriz Hessiana, como se mostró en la

explicacón anterior, para ésto se cálcula inicialmente el tamaño del �ltro que

se empleará la ecuación 4.18, a continuación se realiza el cálculo del determi-

nante mediante una multiplicación de �ltros de caja, para acelerar el proceso se

emplea la imagen integral y aplicando las ecuaciones 4.10 y 4.17, para obtener

las componentes en Dxx, Dyy y Dxy y calcular el determinante con la ecuación

4.8. Se realiza la inversa de la matriz 4.20 y se multiplica por el vector 4.21, si

todos los valores del vector resultante son menores a 0.5 entonces el punto es

considerado un punto de interés, ésto con la �nalidad de mantener los puntos

más estables y repetitivos.

38

Descriptor de puntos de interés: La obtención del descriptor se divide en dos

tareas especí�cas, a) primero se realiza la asignación de la orientación de cada

punto de interés y b) se obtienen las componentes del descriptor. A continuación

se describen ambas tareas.

Asignación de la orientación: Ésta tarea permite la invarianza ante la rota-

ción de las imágenes mediante la orientación de cada punto de interés.

Para cada punto de interés obtenido en la etapa anterior se realiza el cálculo de la

respuesta de Haar en las direcciones x e y, expresadas por los �ltros de caja que se

muestran en la Figura 4.8, lo cual se utiliza para detectar inclinaciones en ambas

direcciones.

Figura 4.8: Filtros de Haar empleados en el descriptor SURF (Color negro identi�cael valor de -1 y el blanco el valor de +1)

Lo que se analiza es el área circular comprendida en un radio de 6 veces la escala

a la que el punto de interés se localizó para obtener la orientación del punto de

interés. Así mismo, el valor que tomarán las respuestas de Haar será de 4 veces la

misma escala y se aplican las imágenes integrales para disminuir el procesamiento.

Después de obtener las respuestas Haar, se ponderan con una gaussiana de valor 2.5

veces la escala con centro en el punto de interés, lo cual se emplea para representar

al punto cálculado como un punto en el espacio x e y. Por último para obtener la

orientación dominante que presenta el punto de interés se realiza la sumatoria de

todas las respuestas obtenidas dentro de un ángulo de π/3, el cual se rotará con

incrementos constantes. La orientación �nal será aquella cuyo vector resultante sea

de mayor valor, como se observa en la Figura 4.9.

39

Figura 4.9: Asignación de la orientación

Componentes del descriptor: En esta etapa se trabaja nuevamente sobre

cada punto de interés particularmente. El primer paso es trazar un área cuadrada

de tamaño 20 veces la escala alrededor del punto de interés para mantener la

información espacial del punto, ésta región se divide en 4x4 subregiones del

mismo tamaño, en las cuales se calculan las respuesta de Haar para 25 puntos

de muestra distribuidos regularmente (ver Figura 4.10). Estas respuestas son

ponderadas con una gaussiana de 3.3 veces la escala para una mayor robustez

ante deformaciones geométricas y errores de localización.

El resultado de éste proceso es un vector de características dado por la ecuación 4.22.

V =[∑dx,∑dy,∑ |dx|,∑ |dy|

](4.22)

donde dx y dy representan la respuesta deHaar para x e y. El vector resultante es de

un largo de 4x4x4= 64 valores para cada punto de interés detectado lo cual genera la

invarianza ante la rotación, escala e iluminación.

40

Figura 4.10: Componentes del descriptor

Implementación del descriptor: En la implementación del descriptor únicamente

se trabaja sobre los puntos detectados anteriormente. Para la asignación de la

orientación primero se obtienen las respuestas de Haar para x e y, esto se realiza

tomando en cuenta un área circular de 6 veces la escala (s) del punto de interés,

el tamaño del �ltro para representar la respuesta Haar es de 4*s, en este paso se

utiliza la imagen integral para obtener las sumatorias de las regiones que serán

analizadas con la respuesta de Haar, los valores se multiplican por una gaussiana

de valor 2.5*s y a continuación se calcula el ángulo que tendrá dicha respuesta

empleando 4.23.

θ =

arctan( y

x

)x,y >= 0

π + arctan( y

x

)x,y <= 0

π− arctan(−y

x

)x < 0,y >= 0

2∗π− arctan(−y

x

)x >= 0,y < 0

(4.23)

Una vez obtenidos los ángulos se hace un recorrido de 0 a 3600 de la imagen con

incrementos constantes del ángulo en los cuales se hace una sumatoria de todas las

respuestas dentro de un intervalo de π

3 conservando la sumatoria mayor como el ángulo

del punto de interés.

Para la obtención del descriptor de características se genera un área rectangular de

20 veces la escala con centro en el punto de interés y con orientación determinada

por el ángulo localizado en la etapa anterior, a continuación se segmenta el área en

41

regiones de 4x4 del mismo tamaño, de las cuales se emplean 25 puntos distribuidos

regularmente dentro de cada subregión para calcular las respuestas de Haar en x e y

las cuales se calculan con el empleo de imágenes integrales.

Emparejamiento de puntos de interés: Para el emparejamiento de dos imágenes

I1 e I2, se obtienen para cada punto de la imagen I1 los dos mejores candidatos

de los puntos de interés de la imagen I2 mediante el criterio de máxima similitud,

el cual indica que los mejores candidatos para emparejar el punto de interés p1

de la imagen I1 con vector de características v1 son los puntos de interés p'1

y p'2 de imagen I2 cuyos vectores de características v'1 y v'2 representan las

distancias euclidianas menores d1 y d2 con respecto a v1. Si el cociente de

d1/d2 es menor a un umbral establecido, entonces los puntos de interés p1 y

p'1 son emparejados. La implementación del emparejamienot de los puntos de

interés se realiza como lo muestra el diagrama de �ujo de la Figura 4.11.

42

Figura 4.11: Diagrama de �ujo emparejamiento de puntos de interés

43

4.1.3. Pruebas y resultados de la implementación del algo-

ritmo SURF

Construcción del espacio-escala y resolución de las imágenes Como se

mencionó en la sección 4.1.2, el algoritmo SURF se basa en la detección de puntos de

interés invariantes en las imágenes, para lo que se requiere crear el espacio-escala que

indicará la cantidad de escalas que se aplicarán a los �ltros empleados, así mismo se

probó el algoritmo modi�cando la resolución de las imágenes. Las pruebas realizadas

modi�can la cantidad de octavas e intervalos que se requieren para determinar la escala

de los �ltros implementadas sobre imágenes con una resolución de 320 x 240 y 640

x 480. La Tabla 4.4 muestra los resultados que se obtuvieron al aplicar el algoritmo

SURF en una imagen, se observa que la cantidad de puntos de interés detectados

disminuye en primer instancia en relación a la disminución de las octavas requeridas

por el algoritmo y en segunda instancia por la cantidad de intervalos con que se

relaciona la octava, así mismo la cantidad de puntos de interés es menor al disminuir

la resolución de las imágenes que se emplean.

Tabla 4.4: Comparación entre puntos de interés detectados en imágenes con diferenteresolución y cambios en octavas e intervalos

Relación octava/ intervaloResolución

640 x 480 320 x 2403 octavas 4 intervalos 72 242 octavas 4 intervalos 67 213 octavas 3 intervalos 48 182 octavas 3 intervalos 45 15

La Figura 4.12 muestra el resultado de aplicar el algoritmo SURF sobre una imagen

con una resolución de 320 x 240 a la izquierda y una imagen con una resolución de 640

x 480 con el empleo de 2 octavas y 3 intervalos para la construcción del espacio-escala.

Se observa que aunque la cantidad de puntos es menor al disminuir la resolución de la

imagen, los puntos detectados son en la imagen de menor resolución son constantes

en comparación de la imágen de mayor resolución.

44

Figura 4.12: Comparativa entre dos imágenes con 2 octavas y 3 intervalos con reso-lución de 320x240 (imagen izquierda) y 640x480 (imagen derecha)

La siguiente prueba que se realizó compara los tiempos de ejecución que requiere el

algoritmo en diferentes dispositivos con imágenes de diferentes resoluciones y con di-

ferentes combinaciones de octavas e intervalos. La tabla 4.5 muestra los resultados

que se obtuvieron de la prueba, se muestra que el dispositivo que tuvo mayores tiem-

pos de ejecución es el celular Sony xperia U y el que menores tiempos de ejecución

presentó es la tableta Asus Transformer Pad In�nity, así mismo la combinación que

tuvo el menor tiempo de ejecución es con la tableta Asus Transformer Pad In�nity con

imágenes con resolución de 320 x 240 y 2 octavas con 3 intervalos para la construcción

del espacio-escala.

Tabla 4.5: Comparativa de tiempos de ejecución del algoritmo entre diversos disposi-tivos (resultados medidos en segundos)

Octava- Samsung Galaxy Asus Transformer Sony

intervalo Tab 2 Pad In�nity Xperia U

640 x 480 320 x 240 640 x 480 320 x 240 640 x 480 320 x 240

3 octavas22.84 8.10 17.34 5.48 28.30 9.24

4 intervalos

2 octavas17.85 5.41 13.64 4.46 23.17 6.73

4 intervalos

3 octavas19.56 5.30 15.24 4.78 25.60 7.07

3 intervalos

2 octavas15.30 4.56 12.35 4.12 19.52 6.16

3 intervalos

Con base a los resultados de las pruebas anteriores se propuso utilizar imágenes de

resolución de 320 x 240 y 2 octavas con 3 intervalos para la construcción del espacio-

escala, esto con la �nalidad de disminuir los tiempos de ejecución del algoritmo en

45

el dispositivo móvil, así mismo se propone emplear dispositivos con procesador a 1.9

GHz para contar con una mayor velocidad en la ejecución de las aplicaciones que se

creen con el empleo del framework.

Umbrales El algoritmo SURF implementa 3 umbrales que in�uyen en la cantidad

de puntos de interés detectados, en el emparejamiento de éstos puntos las imágenes y

el porcentaje de aceptación entre las imágenes emparejadas, por lo cual es necesario

ajustar estos umbrales para que se obtengan los mejores resultados en la detección

de los marcadores no convencionales. Las pruebas que se realizaron para obtener los

umbrales adecuados son las siguientes:

Curvas de la falsa aceptación y el falso rechazo: Sorita en su tesis doctoral

�Reconocimiento automático mediante patrones biométricos de huella dactilar�

expuesto en [48] establece que al existir variaciones en las características de

una muestra, las respuestas en los sistemas de reconocimiento automáticos se

basan en un estudio estadístico previo enfocado a la toma de decisión entre si

un elemento muestra es legítimo o impostor tomando en cuenta una tasa de

error. Al enfocar el concepto expuesto por Sorita para determinar los umbrales

empleados por el algoritmo, se presentan 4 escenarios posibles:

a) Si la imagen a analizar es la imagen marcador y es reconocida por el algoritmo,

entonces es una correcta aceptación (VP).

b) Si la imagen a analizar es la imagen marcador pero no es reconocida por el

algoritmo, entonces es un falso rechazo (FP).

c) Si la imagen a analizar no es la imagen marcador pero es reconocida por el

algoritmo, entonces es una falsa aceptación (FN).

d) Si la imagen a analizar no es la imagen marcador y no es reconocida por el

algoritmo, entonces es un correcto rechazo (VN).

Las curvas de la falsa aceptación y el falso rechazo gra�can la probabilidad de que

exista una falsa aceptación y un falso rechazo, el valor del umbral indica la probabilidad

de incrementar o disminuir una correcta aceptación y un correcto rechazo.

46

Para determinar el umbral para la detección de los puntos de interés se realizó una

comparación entre una imagen muestra comparada con 100 imágenes similares a la

imagen muestra y 100 imágenes diferentes a la imagen muestra, se empleó un umbral

de emparejamiento con valor de 0.5 y un umbral de aceptación de 10, los resultados

se observan en la Figura 4.13.

Figura 4.13: Curva de la falsa aceptación y el falso rechazo para determinar el umbralpara la detección de puntos de interés

En la Figura 4.13 se observa que la probabilidad de que exista una falsa aceptación

al emplear los diferentes umbrales para la detección de los puntos de interés es de 0,

mientras que el umbral que disminuye la probabilidad de que exista un falso rechazo

es el de 90, por lo tanto es el umbral a emplear en las siguientes pruebas.

Para determinar el umbral para el emparejamiento de las imágenes se realizó una

comparación entre una imagen muestra comparada con 100 imágenes similares a la

imagen muestra y 100 imágenes diferentes a la imagen muestra, se empleó el umbral

para la detección de puntos de interés con un valor de 90 y el umbral para la aceptación

del emparejamiento se mantiene en 10, los resultados se muestran en la Figura 4.14.

47

Figura 4.14: Curva de la falsa aceptación y el falso rechazo para determinar el umbralde emparejamiento de imágenes

La Figura 4.14 muestra que la probabilidad de que exista un falso rechazo disminuye

al incrementar el umbral para el emparejamiento de las imágenes, mientras que la

probabilidad de que exista una falsa aceptación aumenta al incrementar el umbral.

Con base al resultado obtenido en la prueba que se realizó, se emplea el umbral de

emparejamiento de las imágenes con un valor de 0.7 ya que presenta los mejores

resultados.

A continuación para determinar el umbral de aceptación del emparejamiento de imá-

genes se realizó una comparación entre una imagen muestra comparada con 100 imá-

genes similares a la imagen muestra y 100 imágenes diferentes a la imagen muestra,

se empleó el umbral para la detección de los puntos de interés con un valor de 90 y el

umbral para el emparejamiento de las imágenes con un valor de 0.7, los resultados se

muestran en la Figura 4.15.

48

Figura 4.15: Curva de la falsa aceptación y el falso rechazo para determinar el umbralde aceptación del emparejamiento de imágenes

La Figura 4.15 indica que la probabilidad de que exista un falso rechazo aumenta

al incrementar el umbral de aceptación del emparejamiento de imágenes, mientras

que la probabilidad de que exista una falsa aceptación disminuye al incrementar el

umbral. Con base a los resultados obtenidos, se emplea el umbral de aceptación del

emparejamiento de imágenes con un valor de 10.

Para comprobar los resultados obtenidos por las curvas de la falsa aceptación y el falso

rechazo, se emplearon las curvas ROC (por las siglas en inglés de Receiver Operating

Characteristic) para comparar los resultados generados.

Curvas ROC: Como lo indica Burgueño en su trabajo �Las curvas ROC en la evalua-

ción de las pruebas diagnósticas� expuesto en [49] se emplean para determinar

la relación que existe entre la sensibilidad y la especi�cidad de acuerdo con

diferentes umbrales empleados.

La sensibilidad es la probabilidad de obtener un resultado positivo cuando la imagen

a analizar es similar a la imagen muestra y viene dada por la ecuación 4.24.

sensibilidad =V P

V P+FN(4.24)

donde VP es la cantidad de correctas aceptaciones y FN es la cantidad de falsas

aceptaciones.

49

La especi�cidad es la probabilidad de obtener un resultado negativo cuando la imagen

a analizar es diferente a la imagen muestra y viene dada por la ecuación 4.25.

especi f icidad =V N

V N +FP(4.25)

donde VN es la cantidad de correctos rechazos y FP es la cantidad de falsos rechazos.

En la grá�ca de las curvas ROC se establece la sensibilidad en el eje Y y 1-especi�cidad

en el eje X para representar la probabilidad de falsos rechazos, ambos ejes incluyen

valores de 0 a 1, el umbral que cuenta con mayor aceptación, es el que se encuentre

más cercano al punto (0,1) el cual indica la totalidad de correctas aceptaciones con

ningún falso rechazo.

Para determinar el umbral para la detección de los puntos de interés se realizó una

comparación entre una imagen muestra comparada con 100 imágenes similares a la

imagen muestra y 100 imágenes diferentes a la imagen muestra, se empleó un umbral

de emparejamiento con valor de 0.5 y un umbral de aceptación de 10, se generó la

Tabla 4.6 con los valores de sensibilidad y 1-especi�cidad.

Tabla 4.6: Sensibilidad y 1-especi�cidad para generar curva ROC para determinar elumbral para la detección de los puntos de interés

Umbral VP FN VN FP 1-especi�cidad (eje x) sensibilidad (eje y)

0 8 92 100 0 0 0.08

10 32 68 100 0 0 0.32

20 38 62 100 0 0 0.38

30 36 64 100 0 0 0.36

40 42 58 100 0 0 0.42

50 43 57 100 0 0 0.43

60 42 58 100 0 0 0.42

70 40 60 100 0 0 0.40

80 49 51 100 0 0 0.49

90 58 42 100 0 0 0.58

100 52 48 100 0 0 0.52

Tomando la de�nición de la grá�ca de las curvas ROC, el punto con mejor valoración

es el más cercano a la coordenada (0,1) de acuerdo con la Tabla 4.6 el umbral mas

cercano al punto (0,1) es el 90 por lo que se emplea en las siguientes pruebas.

50

Para determinar el umbral para el emparejamiento de imágenes se realizó una compa-

ración entre una imagen muestra comparada con 100 imágenes similares a la imagen

muestra y 100 imágenes diferentes a la imagen muestra, se empleó un umbral para la

detección de puntos de interés con valor de 90 y un umbral de aceptación de 10, se

generó la Tabla 4.7 con los valores de sensibilidad y 1-especi�cidad.

Tabla 4.7: Sensibilidad y 1-especi�cidad para generar curva ROC para determinar elumbral para el emparejamiento de imágenes

Umbral VP FN VN FP 1-especi�cidad (eje x) sensibilidad (eje y)

0 0 100 100 0 0 0

0.1 0 100 100 0 0 0

0.2 0 100 100 0 0 0

0.3 3 97 100 0 0 0.03

0.4 24 76 100 0 0 0.24

0.5 58 42 100 0 0 0.58

0.6 89 11 100 0 0 0.89

0.7 100 0 100 0 0 1

0.8 100 0 87 13 0.13 1

0.9 100 0 4 96 0.96 1

1 100 0 0 100 1 1

En la Tabla 4.7 se observa que el umbral más cercano al punto (0,1) para el cálculo

de la curva ROC es el 0.7 por lo que es el umbral a emplear en las siguientes pruebas.

Para determinar el umbral para la aceptación del emparejamiento de imágenes se

realizó una comparación entre una imagen muestra comparada con 100 imágenes

similares a la imagen muestra y 100 imágenes diferentes a la imagen muestra, se

empleó un umbral para la detección de puntos de interés con valor de 90 y un umbral

de emparejamiento de imágenes de 0.7, se generó la Tabla 4.8 con los valores de

sensibilidad y 1-especi�cidad.

51

Tabla 4.8: Sensibilidad y 1-especi�cidad para generar curva ROC para determinar elumbral de aceptación para el emparejamiento de imágenes

Umbral VP FN VN FP 1-especi�cidad sensibilidad

0 100 0 0 100 1 1

10 100 0 100 0 0 1

20 70 30 100 0 0 0.70

30 20 80 100 0 0 0.20

40 5 95 100 0 0 0.05

50 1 99 100 0 0 0.01

60 0 100 100 0 0 0

70 0 100 100 0 0 0

80 0 100 100 0 0 0

90 0 100 100 0 0 0

100 0 100 100 0 0 0

En la Tabla 4.8 se observa que el umbral que tuvo mejor valoración en la curva ROC

es el de 10 por lo que es el empleado en la implementación del algoritmo.

Rotación, escala e iluminación Una de las características principales del al-

goritmo SURF es la invariancia ante cambios de escala, rotación e iluminación, sin

embargo para su implementación en dispositivos móviles es necesario conocer en que

condiciones prevalece la invarianza para el emparejamiento de imágenes, para obtener

los valores óptimos para el funcionamiento del framework. Por tal motivo se realiza-

ron pruebas para medir la invarianza ante cambios de escala, rotación e iluminación

implementando el algoritmo en un dispositivo móvil, se emplearon 30 imágenes como

marcadores y se emparejaron con imágenes de los mismos marcadores pero con las

variaciones mencionadas, el objetivo de la prueba era obtener en que condiciones existe

invarianza en el reconocimiento de imágenes por parte del algoritmo SURF y en que

porcentaje se presenta.

La Tabla 4.9 muestra los resultados que se obtuvieron de la comparación de los 30

marcadores con 11 imágenes con cambios en su rotación.

52

Tabla 4.9: Cambios de rotación para el emparejamiento de imágenesRotación Imágenes emparejadas % de aceptación

0° 30 100

45° 30 100

90° 25 83.3

135° 24 80

180° 27 90

225° 25 83.3

270° 24 80

315° 29 96.6

45° al frente 20 66.6

45° atras 19 63.3

45° a la izquierda 22 73.3

45° a la derecha 23 76.6

En la Tabla 4.9 se observa que el algoritmo tiene mejor emparejamiento de imáge-

nes cuando la imágen tiene cambios menores en cuanto al eje perpendicular o ésta

totalmente invertida la imagen, los mejores resultados son: 0°, 45°, 315° y 180° con

un porcentaje de emparejamiento mayor al 90%. Cuando la imagen es rotada hacia

enfrente, atrás, a la izquierda o a la derecha el emparejamiento de las imágenes dis-

minuye considerablemente aunque se encuentra entre el 60% y 80% de aceptación.

La Figura 4.16 muestra el emparejamiento de 1 marcador con la imagen rotada 180°.

Figura 4.16: Emparejamiento de imágenes con rotación

La Tabla 4.10 muestra los resultados que se obtuvieron al comparar 30 imágenes

empleadas como marcadores con las mismas imágenes con cambios en la escala de la

imagen, ésto alejando el dispositivo del objeto al capturar la imagen.

53

Tabla 4.10: Cambios de escala para el emparejamiento de imágenes% de tamaño en relación

Imágenes emparejadas % de aceptaciónal marcador

90 30 10080 30 10070 25 83.360 21 7050 12 4040 6 2030 0 020 0 010 0 0

En la Tabla 4.10 se observa que el emparejamiento de las imágenes se mantiene al

100% cuando el marcador disminuye su tamaño un 90% u 80% y cuando es meñor al

50% del tamaño del marcador original ya no existe emparejamiento entre las imágenes.

La Figura 4.17 muestra el emparejamiento entre 2 imágenes con cambios en la escala

del marcador.

Figura 4.17: Emparejamiento de imágenes con cambio de escala

La Tabla 4.11 muestra los resultados que se obtuvieron al comparar 30 imágenes

empleadas como marcadores con las mismas imágenes con cambios en la iluminación

de las imágenes, ésta prueba fue realizada en interiores con la luz que genera una

lámpara de luz blanca de bajo consumo con un �ujo luminoso de 1560 lúmenes y en

exteriores a diferentes horas del día.

54

Tabla 4.11: Cambios de iluminación para el emparejamiento de imágenesHora Empajejamiento % de Emparejamiento % de

del día Interiores aceptación Exteriores aceptación

7 30 100 30 100

8 30 100 30 100

9 30 100 30 100

10 30 100 30 100

11 30 100 30 100

12 30 100 29 96.6

13 30 100 28 93.3

14 30 100 29 96.6

15 30 100 28 93.3

16 30 100 30 100

17 30 100 30 100

18 30 100 30 100

19 30 100 29 96.6

20 30 100 0 0

21 30 100 0 0

En la Tabla 4.11 se observa que existe emparejamiento en todas las imágenes en

interiores, mientras que en exteriores disminuye el porcentaje de imágenes emparejadas

dependiendo la cantidad de luz ambiental, cuando oscurece y no existe luz arti�cial

que ilumine las imágenes no existe emparejamiento entre ellas. La Figura 4.18 muestra

el emparejamiento de dos imágenes con cambios en la iluminación.

Figura 4.18: Emparejamiento de imágenes con cambio de iluminación

55

4.2. Geolocalización

Daniel Abril en [2] de�ne a la geolocalización como la identi�cación del entorno me-

diante posicionamiento a través de la estimación de la posición del dispositivo. Existen

sistemas de posicionamiento que brindan la información necesaria al dispositivo para

realizar este tipo de realidad aumentada. Android provee dos tecnologías principales

para obtener la posición del dispositvo: Sistema de localización global basado en GPS

(Sistema de posicionamiento Global) y el Sistema de localización basado en la infor-

mación recibida de las torres de telefonía celular y de puntos de acceso WiFi. Debido

a que se propone que el sistema sea independiente al acceso de redes inalámbricas, se

emplea el sistema de localización global basado en GPS para el desarrollo del módulo.

Este sistema de localización fue diseñado inicialmente para uso militar aunque actual-

mente se emplea con �nes civiles. Consta de 3 componentes principales: a) Espacial,

b) control y c) receptor.

a) Espacial: Lo forman 24 satélites que orbitan la tierra a una distancia aproximada

de 20 200 km distribuidos en 6 planos orbitales. Ésta formación satelital se

generó con la �nalidad de que al menos 4 satélites sean visibles encima del

horizonte en cualquier punto de la super�cie terrestre.

b) Control : Está formado por 5 estaciones de rastreo y una estación de control

principal. Las estaciones se encargan de rastrear los satélites, actualizar sus

posiciones y calibrar sus relojes.

c) Receptor: Todos aquellos dispositivos que cuentan con un receptor GPS. Android

integra librerías especializadas para acceder a los recursos de su arquitectura.

En la Figura 4.19 se muestra un ejemplo del funcionamiento del GPS.

56

Figura 4.19: Funcionamiento del GPS

El submódulo de geolocalización es el encargado de obtener las coordenadas de latitud

y longitud del dispositivo al capturar las imágenes empleadas como marcadores no

convencionales en el módulo de almacenamiento de datos y al procesar el video para

acotar el rango de búsqueda para el emparejamiento de los puntos de interés.

En el caso de la localización del dispositivo se dispone de las siguientes clases que

permiten trabajar con la posición geográ�ca del dispositivo Android mediante GPS:

LocationManager: Proporciona acceso a los servicios de localización del sistema,

los cuales permiten recibir actualizaciones periódicas de la posición geográ�ca

del dispositivo.

LocationListener: Ésta clase se emplea para recibir noti�caciones por parte de

LocationManager cuando existe algun cambio en la posición del dispositivo.

Location: Representa la ubicación geográ�ca del dispositivo, la cual está inte-

grada por la información de latitud, longitud, altitud, fecha, hora y velocidad.

El proceso a seguir se muestra en el diagrama de �ujo de la Figura 4.20, donde se

comienza con el acceso al servicio de localización para almacenar la geolocalización

del dispositivo.

57

Figura 4.20: Diagrama de �ujo para obtener la información de geolocalización

El proceso para obtener la información de geolocalización que se muestra en la Figura

4.20 inicia al acceder al servicio de localización del dispositivo y obtener la última

localización conocida, a continuación se obtiene el status del GPS del dispositivo, si

está inhabilitado, se manda un mensaje de alerta, en caso contrario se comprueba que

la localización sea diferente de nulo, si es así seactualiza la localización y se obtiene la

última localización conocida, en caso contrario se solicita nuevamente la localización,

si la última localización es diferente de nulo, se guarda la localización del dispositivo.

58

4.2.1. Obtención de la lectura de geolocalización

Para comprobar obtención de la información de geolocalización se generó una aplica-

ción que obtiene las coordenadas de latitud y longitud del dispositivo, éstas coorde-

nadas se actualizan cada 30 segundos por lo que en pantalla se visualiza las nuevas

coordenadas después de transcurrido el tiempo establecido. La Figura 4.21 muestra el

resultado de ésta aplicación, en la parte superior de la �gura se muestran las coorde-

nadas de latitud y longitud al iniciar la aplicación, en la parte inferior de la �gura se

muestran las coordenadas actualizadas después de transcurrir 30 segundos.

Figura 4.21: Aplicación de prueba para obtener la geolocalización del dispositivo

Las pruebas de geolocalización realizadas permiten conocer las coordenadas de latitud

y longitud del dispositivo al tomar una fotografía para almacenarla como marcador o

al capturar el video de la cámara del dispositivo, ésta información se actualiza cada

30 segundos para tener una geolocalización actualizada del móvil.

59

Página intencionalmente en blanco

60

Capítulo 5

Módulo de almacenamiento de

datos

Para el almacenamiento de datos se utilizó la librería SQLite versión 3.4.0 la cual está

incorporada en la arquitectura de los dispositivos Android (ver Anexo B). Dentro de las

herramientas incluidas en la librería se encuentran aquellas que permite la creación y

gestión de las bases de datos. SQLite es un sistema gestor de base de datos relacional,

requiere memoria limitada en tiempo de ejecución. Una característica importante de

SQLite es que es una librería que se enlaza con la aplicación, esto signi�ca que todas

las operaciones de la base de datos se realizan dentro de la aplicación por medio de

llamadas y funciones contenidas en la librería. Los tipos de datos de�nidos en SQLite

y publicados en la página o�cial se muestran en la Tabla 5.1. SQLite soporta bases

de datos de terabytes de tamaño.

Tabla 5.1: Tipos de datos permitidos por SQLiteTipo de dato Descripción

NULL El valor es un valor NULL

INTEGEREl valor es un entero con signo, almacena en 1,2,3,4,6 u 8

bytes dependiendo de la magnitud del valor.

REALEl valor es un �otante almacenado como un

número de punto �otante de 8-byte IEEE

TEXTEl valor es una cadena de texto almacenado utilizando la

codi�cación de base de datos (UTF-8, UTF-16BE o UTF-16LE)

BLOB El valor es un arreglo de datos almacenado tal cual entra

Para crear el almacenamiento de datos con SQLite no se requiere un proceso de con�-

61

guración, simplemente se tienen que de�nir las instrucciones SQL para crear y actuali-

zar la información. Inicialmente para crear la base de datos y actualizar la información

se crea una clase que herede de SQLiteOpenHelper, la cual es una clase perteneciente

a la librería de SQLite y después modi�car los método de la clase mostrados en la

Tabla 5.2.

Tabla 5.2: Métodos empleados de la clase SQLiteOpenHelperMétodo Descripción

constructorLlama al constructor de la clase padre y

especi�ca el nombre y versión de la base de datos

onCreateDe�ne la estructura de las tablas y carga datos iniciales

Se llama cuando se crea por primera vez la base de datos

onUpgrade Se llama cuando la base de datos se actualiza

El módulo de almacenamiento de datos contiene la información relacionada a las

imágenes que serán empleadas como marcadores no convencionales en el framework.

La Tabla 5.3 muestra los campos que se emplean.

Tabla 5.3: Campos empleados en el módulo de almacenamiento de datosCampo Tipo de dato Descripción

Id INTEGER Identi�cador del marcador almacenado

Can_puntos INTEGERCantidad de puntos de interés

detectados en cada marcador

Latitud REAL Latitud a la que fue localizado el marcador

Longitud REAL Longitud a la que fue localizado el marcador

Descriptor TEXTDescriptor de características de los puntos

de interés detectados en la imagen

Aumento BLOBInformación a aumentar en la

pantalla del dispositivo

Para guardar la información en el módulo de almacenamiento de datos se realiza el

proceso que indica el diagrama de �ujo que se muestra en la Figura 5.1.

62

Figura 5.1: Diagrama de �ujo para guardar un marcador

El proceso que se muestra en la Figura 5.1 para guardar un marcador inicia activando

la cámara del dispositivo para capturar la fotografía del marcador a emplear, si no

se tomo una fotografía se sale del proceso, en caso contrario se toma la fotografía

y se le aplica el algoritmo SURF a la fotografía tomada y se obtiene la información

de geolocalización por parte del módulo de procesamiento, una vez que se procesó

la imagen, se abre el manejador de datos para guardar la información extraída de la

fotografía y se cierra el manejador de datos.

Para obtener la información almacenada para el emparejamiento de imágenes se realiza

el proceso que muestra el diagrama de �ujo de la Figura 5.2.

63

Figura 5.2: Diagrama de �ujo para obtener la información de los marcadores

Para obtener la información de los marcadores almacenados como se muestra en la

Figura 5.2 y poder emparejar su información con la del módulo de captura y edición

de video, inicialmente se abre el manejador de datos, se inicializa un ciclo que recorra

desde el primer marcador hasta el último almacenado y se compara la información

del manejador con la que envía el módulo de captura y edición de video, el proceso

termina cuando se han recorrido todos los marcadores almacenados.

5.1. Pruebas y resultados del módulo de almace-

namiento de datos

La prueba que se realizó para comprobar el funcionamiento del módulo consistió en ge-

nerar una aplicación que almacena directamente en el módulo la información generada

de procesar el algoritmo SURF con la información de geolocalización del dispositivo

al tomar las imágenes. La Figura 5.3 muestra el resultado de ésta prueba.

64

Figura 5.3: Prueba del módulo de almacenamiento de datos

En la Figura 5.3 se observan los datos que se almacenan al procesar una imagen,

se muestra el identi�cador de la imagen, las coordenadas de latitud y longitud, el

descriptor de los puntos de interés de la imagen y la información que se almacena para

el aumento de la realidad, es posible realizar búsquedas de los marcadores almacenados

en el módulo a través de su identi�cador. La información de los descriptores de los

puntos de interés se almacena en un único campo de tipo String, la información a

aumentar se almacena como un tipo de datos blob, debido a que éste tipo de datos

permite almacenar imágenes como un arreglo de bytes, por lo que la imagen debe ser

convertida al almacenar y regresada a su formato al mostrarse en pantalla.

65

Página intencionalmente en blanco

66

Capítulo 6

Módulo de captura y edición de

video

El módulo se encarga de capturar los fotogramas del video que se captura por medio

de la cámara del dispositivo para realizar el procesamiento de imágenes a cada uno de

ellos y mostrar la información que resulta del mismo.

6.1. Captura de video

Para capturar el video que genera el dispositivo Android, se requiere emplear las

librerías hardware y view y se describen en la Tabla 6.1.

Tabla 6.1: Librerías empleadas para la captura de videoLibrería Clases Descripción

Hardwarecamara Establece los parámetros de la cámara

camara.PreviewCallback Obtiene los fotogramas previos

view

SurfaceView Proporciona la super�cie de visualización

SurfaceHolder

Permite controlar las características de

la super�cie y monitorear los

cambios que se realicen

En la Figura 6.1 se muestra el diagrama de �ujo del procedimiento para el desarrollo

del módulo.

67

Figura 6.1: Diagrama de �ujo para la captura de video

Para capturar el video de la cámara del dispositivo como se muestra en la Figura 6.1,

primero se genera la super�cie donde se visualizará el video, se abre la cámara del

dispositivo y se accede a los parámetros de la cámara para especi�car el tamaño de

la imagen a emplear y se actualiza la información de los parámetros, se establece la

super�cie a utilizar para la vista previa de la información y se obtienen los fotogramas

previos del video capturado para enviarse a la clase de edición de video para procesarlos.

6.2. Edición de video

Al obtener los fotogramas por parte de la captura de video se realiza el procesamiento

de los mismos, para lo cual se emplean las librerías de Android que se muestran en la

Tabla 6.2:

68

Tabla 6.2: Librerías empleadas para la edición de videoLibrerías Clases Descripción

view View

Para la construcción de la interfaz de usuario.

Establece el área en la pantalla donde se mostrarán resultados.

Emplea el método OnDraw para renderizar el contenido.

graphicsCanvas Se emplea para dibujar los grá�cos en pantalla

Bitmap Se emplea para trabajar con imágenes de mapa de bits

El procedimiento para desarrollar el módulo es el que se muestra en el diagrama de

�ujo de la Figura 6.2.

Figura 6.2: Diagrama de �ujo para la edición de video

Para la edición de video como se muestra en la Figura 6.2 primero se dibuja la vista

69

donde se va a colocar la imagen procesada, se revisa si se recibió una imagen por parte

de la clase de captura, si no fue recibida �naliza el proceso en caso contrario se manda

al módulo de procesamiento para aplicarle el algoritmo SURF a la imagen y obtener

la información de geolocalización, ésta información que se obtiene de la imagen es

comparada con la información recibida por el módulo de almacenamiento, si la imagen

se encuentra dentro de un rango establecido en su información de geolocalización se

empareja con la imagen almacenada, en caso contrario, se checa la siguiente imagen,

hasta recorrer todos los marcadores almacenados, si no existió emparejamiento de

imágenes entonces se dibuja en pantalla la imagen que se recibió de la clase de captura,

en caso de que exista un emparejamiento, se obtiene la información a aumentar por

parte del manejador de datos, se dibuja la imagen recibida a través de la clase de

captura y se dibuja la información a aumentar en pantalla.

6.3. Pruebas y resultados del módulo de captura

y edición de video

Se realizaron pruebas en el manejo de video en un dispositivo móvil, se generó una

aplicación para trabajar con la cámara del dispositivo, en la cual, se realizan operacio-

nes con los fotogramas que se obtienen por la cámara. En la aplicación se convierte

el video que genera el dispositivo a escala de grises, se emplea el tamaño de imagen

de 320 x 240. El primer paso para realizarlo es establecer los permisos para el uso

de la cámara del dispositivo y abrir la cámara por medio del método camera.open().

El método abstracto onPreviewFrame() es el que permite accesar a los fotogramas

que fueron mostrados por la cámara del dispositivo, al almacenarlos en un arreglo de

byte, es posible modicarlos para realizar el procesamiento que se requiera, en este caso

convertir el video a escala de grises. Antes de poder hacer la conversión, es necesa-

rio convertir el formato YUV que es con el que genera las imágenes el dispositivo,

a formato RGB, con el cual es más sencillo realizar las modicaciones necesarias. El

resultado se observa en la Figura 6.3.

70

Figura 6.3: Prueba del módulo de captura y edición de video

Para comprobar el funcionamiento al superponer información en la visualización de

pantalla, se empleó la librería graphics.Canvas para dibujar texto y una imagen, los

resultados se observan en la Figura 6.4.

Figura 6.4: Superposición de información en la visualización de pantalla

Las librerías que proporciona Android para el manejo de los parámetros de la cá-

mara permiten procesar los fotogramas individualmente y manipular el tamaño de la

imagen que genera la cámara del dispositivo para adaptarlo a los requerimientos así

como implementar la superposición de elementos a la vista con el empleo de clases

pertenecientes al sistema.

71

Página intencionalmente en blanco

72

Capítulo 7

Pruebas y resultados

En el presente capítulo se muestran las pruebas realizadas para analizar el funciona-

miento de los módulos del framework, así como los resultados obtenidos. Se desa-

rrollaron en el IDE Eclipse versión 4.2.1 con el plugin ADT versión 22.0.1 para el

desarrollo en Android. Para realizar las pruebas de los módulos en dispositivos móviles

se emplearon los dispositivos de la Tabla 7.1.

Tabla 7.1: Dispositivos móviles empleados para las pruebas de funcionamiento delframework

Característica

Sony Samsung Samsung Asus

Xperia Galaxy Galaxy Transformer

U Tab 2 Ace Pad Tf300t

Versión del2.3 4.0 2.3 4.2

S. O.

Cámara5 3 5 5

(megapixeles)

Pantalla (pixeles) 854x480 1024x600 320x480 2560x1600

Memoria interna 8 GB hasta 32 GB 158 MB 32 GB

RAM 512 MB 1 GB 278 MB 2 GB

ProcesadorDual Core a Dual Core a Qualcomm a Nvidia Tegra 4

1 GHz 1GHz 800 MHz a 1.9 GHz

CompatibilidadSi Si Si Si

GPS

73

7.1. Pruebas y resultados del framework

Se generó una aplicación de prueba que integra la arquitectura del framework desa-

rrollado, la guía para el empleo del framework se muestra en el Anexo C. La pantalla

de inicio de la aplicación se muestra en la Figura 7.1. La pantalla se compone por 2

botones los cuales dan acceso a las funciones del framework: el botón base es el que

permite guardar un nuevo marcador en el módulo de almacenamiento de datos y el

botón aumento permite accesar a la cámara del dispositivo y mostrar los resultados

del módulo de captura y edición de video.

Figura 7.1: Pantalla de inicio de la aplicación de prueba

El código que implementa ésta pantalla es el que se muestra en el Código 7.1, permite

iniciar la actividad seleccionada al dar click sobre algúno de los dos botones.

p u b l i c vo i d aumento ( View v ) {I n t e n t i = new I n t e n t (Aumento . t h i s , Video . c l a s s ) ;s t a r t A c t i v i t y ( i ) ;

}p u b l i c vo i d base ( View v ) {

I n t e n t i = new I n t e n t (Aumento . t h i s , Base . c l a s s ) ;s t a r t A c t i v i t y ( i ) ;

}

Código 7.1: Pantalla de inicio

La Figura 7.2 muestra la pantalla que permite almacenar un nuevo marcador en el

módulo de almacenamiento. Las opciones que brinda son: a) Tomar foto, permite

74

acceder a la cámara del dispositivo para tomar la fotografía del marcador que se desea

almacenar, b) buscar información, accesa a la galería del dispotivo para seleccionar

la imagen que se desea superponer al marcador cuando sea reconocido, c) guardar,

procesa la imagen y guarda la información en el módulo de almacenamiento de datos

y d) ver registro, permite realizar una búsqueda por identi�cador en el manejador de

datos para ver la información almacenada.

Figura 7.2: Pantalla para guardar un marcador en el módulo de almacenamiento

El Código 7.2 lo implementa la actividad para el funcionamiento de los botones de la

pantalla y el método onActivityResult que permite accesar a la galería del dispositivo

lo cual se observa en la Figura 7.3, una vez que se tomo una fotografía y se seleccionó

la imagen a aumentar, se guarda la información resultante del procesamiento de la

fotografía tomada y se muestra un aviso de que se ha guardado la información como

se observa en la Figura 7.4, por último al seleccionar la opción ver registro, accesa a la

información del módulo de almacenamiento de datos para mostrar los datos guardados

del marcador cuyo identi�cador fue seleccionado como se muestra en la Figura 7.5.

75

impor t com . l i b r e r i a . a lmacenamiento . Manejador ;p u b l i c vo i d toma ( View v ) {

s t a r t A c t i v i t y F o r R e s u l t ( f o t o . tomar_foto ( ) , 1 ) ;}p u b l i c vo i d busca ( View v ){

s t a r t A c t i v i t y F o r R e s u l t ( f o t o . busca r_foto ( ) , 2 ) ;}p r o t e c t e d vo i d o nA c t i v i t y R e s u l t ( i n t requestCode ,i n t r e su l tCode , I n t e n t data ) {

i f ( r eques tCode == 2){Ur i s e l e c t e d Image = data . getData ( ) ;InputSt ream i s ;t r y {

i s =ge tCon t en tRe s o l v e r ( ) .open InputSt ream ( s e l e c t e d Imag e ) ;Bu f f e r ed I npu tS t r eam b i s =new Bu f f e r ed I npu tS t r eam ( i s ) ;Bitmap bitmap = BitmapFactory .decodeStream ( b i s ) ;bitmap1 = Bitmap .c r ea t eSca l edB i tmap ( bitmap , 320 , 240 , t r u e ) ;

} ca tch ( F i l eNotFoundExcep t i on e ) {}}

}p u b l i c vo i d guarda ( View v ){

f o t o . guarda_foto ( bitmap1 ) ;}p u b l i c vo i d v e r ( View v ){

I n t e n t i = new I n t e n t ( g e tApp l i c a t i o nCon t e x t ( ) ,R e g i s t r o . c l a s s ) ;s t a r t A c t i v i t y ( i ) ;

}

Código 7.2: Guardar un marcador en el módulo de almacenamiento

76

Figura 7.3: Acceso a la galería del dispositivo

Figura 7.4: Guargar la información del marcador en el módulo de almacenamiento

Figura 7.5: Ver registro almacenado en el módulo de almacenamiento

77

Al seleccionar la opción de aumento en la pantalla que se muestra en la Figura 7.1 se

accesa al módulo de captura y edición de video para procesar los fotogramas obtenidos

del video, inicialmente compara las coordenadas de latitud y longitud del fotograma

capturado y de los marcadores almacenados, si las coordenadas son cercanas, aplica el

algoritmo SURF al fotograma capturado, si encuentra un marcador entonces superpone

la información relacionada en la pantalla del dispositivo, el código 7.3 se emplea para

accesar al módulo de captura y edición de video y el resultado de la prueba se observa

en las Figuras 7.6 y 7.7.

impor t com . l i b r e r i a . c a p t u r a y e d i c i o n . S a l i d a ;p u b l i c c l a s s Video ex t end s A c t i v i t y {

S a l i d a s a l i d a ;@Over r idep r o t e c t e d vo i d onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) {

supe r . onCreate ( s a v e d I n s t a n c eS t a t e ) ;getWindow ( ) . s e t F l a g s (WindowManager . LayoutParams .FLAG_FULLSCREEN, WindowManager . LayoutParams .FLAG_FULLSCREEN ) ;requestWindowFeature (Window .FEATURE_NO_TITLE) ;s a l i d a=new Sa l i d a ( g e tApp l i c a t i o nCon t e x t ( ) ) ;s e tContentV iew ( s a l i d a . ge tCaptu ra ( ) ) ;addContentView ( s a l i d a . g e tEd i c i o n ( ) ,new LayoutParams ( LayoutParams .WRAP_CONTENT,LayoutParams .WRAP_CONTENT) ) ;

}}

Código 7.3: Acceder al módulo de captura y edición de video

Figura 7.6: Realidad aumentada en el dispositivo móvil marcador 1

78

Figura 7.7: Realidad aumentada en el dispositivo móvil marcador 2

El tamaño de la aplicación generada es de 1.31 MB y el tamaño promedio de cada

marcador almacenado es de 60KB. Con el funcionamiento de la aplicación se validó

la correcta integración del framework.

79

Página intencionalmente en blanco

80

Capítulo 8

Conclusiones y trabajos futuros

8.1. Conclusiones

En el presente proyecto de investigación se diseñó y desarrolló un framework para

el desarrollo de realidad aumentada para dispositivos móviles con sistema operativo

android. El framework se basa en una arquitectura de 4 módulos: módulo de aplicación,

módulo de procesamiento, módulo de almacenamiento de datos y módulo de captura

y edición de video.

El algoritmo que se implementó para el reconocimiento de marcadores no convencio-

nales permite el emparejamiento de imágenes con cambios en: a) Iluminación donde

se presenta invarianza siempre que el marcador sea completamente visible en la ima-

gen, b) rotación en un rango de 45°, 315° y 180°, sin embargo para otros ángulos de

rotación la invarianza es mayor al 60% y c) escala donde la invarianza es mayor ante

la disminución del tamaño del marcador en un 90% y 80%, ésta invarianza va dis-

minuyendo conforme el tamaño del marcador disminuye en las imágenes a comparar,

siendo apartir del 30% cuando no existe emparejamiento de imágenes.

La arquitectura modular del framework permite que el algoritmo SURF puede ser sus-

tituido en el módulo de procesamiento por otro algoritmo basado en la detección de

puntos de interés, siempre y cuando éste algoritmo genere un descriptor de caracte-

rísticas de puntos de interés.

Para la construcción del espacio-escala que requiere el algoritmo SURF se establecieron

los valores de 2 octavas y 3 intervalos con imágenes con resolución de 320 x 240,

81

aunque éstos valores pueden ser módi�cados por el desarrollador que implemente

el framework, sin embargo al incrementar los valores de las octavas, intervalos y la

resolución de las imágenes se incrementa el tiempo de ejecución del algoritmo.

Si el umbral para la detección de puntos de interés se incrementa, entonces la cantidad

de puntos de interés emparejados disminuye lo cual incrementa la probabilidad de falsos

positivos debido a que el incremento del umbral disminuye la cantidad de puntos de

interés detectados como se observa en la Figura 4.13.

Si el umbral para el emparejamiento de imágenes se incrementa, entonces se incre-

menta la probabilidad de tener falsas aceptaciones ésto debido a que incrementa la

cantidad de puntos de interés a emparejar como se observa en la Figura 4.14.

Si el umbral para la aceptación del emparejamiento de imágenes incrementa, se incre-

menta la probabilidad de tener falsos rechazos debido a que aumenta la cantidad de

puntos de interés emparejados como se observa en la Figura 4.15.

El empleo de la información de geolocalización reduce los tiempos en la detección de los

marcadores no convencionales ésto debido a que solo son comparados los marcadores

que se encuentran dentro de un rango de geolocalización y depende de la cantidad de

marcadores que se encuentran dentro del rango.

El espacio que ocupa la aplicación en el dispositivo incrementa en proporción a la can-

tidad de puntos de interés detectados almacenados en el módulo de almacenamiento

de datos, la aplicación inicialmente tiene un tamaño de 1.31 MB y en promedio cada

marcador almacenado tiene un tamaño de 60 KB disminuyendo al detectar menos

puntos de interés por marcador.

Al almacenar el descriptor de características en lugar de las imágenes se reduce la

cantidad de datos que se guardan en el módulo de almacenamiento debido a que solo

se almacena una cadena que contiene al descriptor en lugar de la imagen completa.

El empleo de dispositivos móviles con procesador mayor a 1.9 GHz disminuye los

tiempos de ejecución requeridos para el funcionamiento del framework debido a que

tienen una mayor velocidad de procesamiento.

82

8.2. Publicaciones

Se generó una publicación como resultado del presente proyecto de investigación (ver

anexo D).

Análisis de la realidad aumentada en dispositivos móviles, L. S. C. Jorge

Stefan Cruz León, M. en C. Jazmín Rodríguez Flores, M. en C. Jo-

súe Román Martínez Mireles, Simposio Iberoamericano Multidisciplinario de

Ciencias e Ingenierías, 379-384, Septiembre 2013.

8.3. Trabajos futuros

Con la realización del proesente proyecto de investigación es posible desarrollar apli-

caciones de realidad aumentada con el empleo de marcadores no convencionales y

geolocalización mediante la implementación del framework. Como trabajos futuros se

pueden mencionar los siguientes puntos:

Optimizar el código del framework para disminuir los tiempos de ejecución.

Optimizar el algoritmo SURF para disminuir la cantidad de falsas aceptaciones

y falsos rechazos.

Optimizar el algoritmo SURF para incrementar la invarianza ante cambios de

rotación y escala.

Integrar la interacción del usuario con la información superpuesta en la visuali-

zación en pantalla.

Integrar la superposición de información en 3D.

83

Página intencionalmente en blanco

84

Referencias

[1] R. Bimber, O. y Raskar, Spatial Augmented Reality. A K Peters, 1 ed., 2004.

EUA.

[2] D. Abril, �Realidad aumentada,� Universidad Carlos III, 2010. Madrid, España.

[3] J. Carmigniani, �Augmented reality technologies, systems and applications,� Mul-

timed Tools Appl., no. 51, pp. 341� 377, 2010.

[4] A. Loup, �La realidad aumentada.� Universidad Católica "Nuestra Señora de la

Asunción". 2007. Paraguay.

[5] I. Sutherland, �A head mounted display three dimensional display,� Actas de la

Conferencia Fall Joint Computer, pp. 757�764, 1968.

[6] M. Krueger, �What should you wear to an arti�cial reality?,� in Arti�cial Reality

and Tele-existence, no. 1, pp. 51�62, ICAT, 1991.

[7] D. Caudell, T. y Mizell, �Augmented reality: an application of heads-up dis-

play technology to manual manufacturing processes,� in System Sciences, vol. 2,

pp. 659 � 669, IEEE, 1992.

[8] M. B. y. S. D. Feiner, S., �Knowledge-based augmented reality,� Communications

of the ACM - Special issue on computer augmented environments: back to the

real world, vol. 36, pp. 53�62, Julio 1993.

[9] G. R. y. K. R. Loomis, J., �Personal guidance system for the visually impaired

using gps, gis, and vr technologies,� in Proceedings of Conference on Virtual

Reality and Persons with Disabilities, 1993.

85

[10] K. Rekimoto, J. y Nagao, �The world through the computer: Computer aug-

mented interaction with real world environments,� Proceedings of the 8th annual

ACM symposium on User interface and software technology, pp. 29�36, 1995.

[11] B. Thomas, �Arquake: the outdoor augmented reality gaming system,� Commu-

nications of the ACM - Internet abuse in the workplace and Game engines in

scienti�c research, vol. 45, pp. 36�38, Enero 2002.

[12] T. Immersion, �Introducing ar+,� 2014. http://www.t-immersion.com/ar-logo/

Accesado julio, 2014.

[13] iabMéxico, �Estudio de usos y hábitos de dispositivos móviles,� 2014.

http://iabmexico.com/Infogra�as/. Accesado marzo, 2014.

[14] ComputerWorld, �Habrá 200 millones de usuarios de realidad aumentada en 2018:

estudio,� 2013. http://www.computerworldmexico.mx/. Accesado enero, 2014.

[15] J. G. y. Y. W. Jing, C., �Mobile augmnted reality system for personal museum

tour guide applications,� tech. rep., Laboratorio de Tecnología de imagen foto-

electrónica y Sistema, Ministerio de educación de China, 2011.

[16] IpsosMediaCT, �Google our mobile planet: Mexico,� 2012.

http://www.usmediaconsulting.com. Accesado junio 2013.

[17] TomiAhonenconsulting, �Smartphone penetration rates by country! wehavegood

data,� 2011. http://communitiesdominate.blogs.com/brands. Accesado junio

2013.

[18] A. Fosk, �Futuro digital latinoamérica 2013,� 2013.

http://www.comscore.com/lat/Insights/. Accesado junio 2013.

[19] Hidden, �Augmented reality marketing strategies: The how to guide for marke-

ters,� 2011. http://hiddenltd.com/. Accesado junio, 2013.

[20] Layar, �Home: Layar,� 2013. https://www.layar.com/. Accesado agosto, 2013.

[21] Mixare, �mixare | free open source augmented reality engine,� 2013.

http://www.mixare.org/. Accesado agosto, 2013.

[22] C. J. y. S. A. Bellón, S., �Look! framework para aplicaciones de realidad aumen-

tada en android,� tech. rep., Universidad Complutense de Madrid, 2010.

86

[23] T. Domhan, �Augmented reality on android smartphones.� Universidad de Edu-

cación Cooperativa Baden-Württemberg. 2010. Alemania.

[24] B. Brügge, �Study on software architectures for augmented reality systems.� Uni-

versidad de Munich. 2002. Alemania.

[25] y. K. V. Behzadan, A., �Georeferenced registration of construction graphics in

mobile outdoor augmented reality,� Journal of Computing in Civil Engineering,

pp. 247�258, 2007.

[26] H. López, �Análisis y desarrollo de sistemas de realidad aumentada,� Master's

thesis, Universidad Complutense de Madrid, 2009. Accesado agosto, 2013.

[27] T. Turunen, �Mobile ar requirements for location based social networks,� The

International Journal of virtual Reality, vol. 9, no. 4, pp. 67�78, 2010.

[28] y. Z. X. Jie, L., �Invariant based augmented reality on mobile phones,� Journal

of Multimedia, vol. 5, no. 6, pp. 588�595, 2010.

[29] S. M. P. O. y. S. J. Prochazka, D., �Mobile augmented reality applications.�

Universidad Mendel. 2011. Brno, Rep. Checa.

[30] E. Gaip, �A framework for outdoor mobile augmented reality,� IJCSI International

Journal of Computer science Issues, vol. 9, no. 1, pp. 419�423, 2012.

[31] M. Santoso, �Development of edutainment content for elementary school using

mobile augmented reality,� vol. 39, 4th International Conference on Computer

Research and Development, 2012.

[32] J. Yim, �Implementation of building recognition android app,� International Jour-

nal of Multimedia and Ubiquitous Engineering, vol. 7, no. 2, pp. 37�52, 2012.

[33] ISO/IEC/IEEE, �Systems and software engineering. architecture description

iso/iec/ieee 42010,� 2014. http://www.iso-architecture.org/ieee-1471, Accesado

25 de agosto de 2014.

[34] A. Baz, �Dispositivos móviles.� Universidad de Oviedo. 2009. España.

[35] N. Arroyo, Información en el móvil. 1 ed., diciembre 2011. Barcelona, España.

87

[36] F. Milgram, P y Kishino, �Taxonomy of mixed reality visual displays,� IEICE

Transactions on Information and Systems, vol. E77-D, pp. 1321�1329, Diciembre

1994.

[37] R. Azuma, �A survey of augmented reality,� Massachusetts Institute of Techno-

logy, vol. 6, pp. 355�385, Agosto 1997.

[38] N. R. y. S. D. Hofmeister, C, Applied Software Architecture. Object Technology

Series. Addison-Wesley, 2000.

[39] Microsoft, �De�nición y descripción de un pixel,� Octubre 2013.

http://support.microsoft.com/kb/253680/es. Accesado febrero, 2014.

[40] O. Boullosa, �Estudio comparativo de descriptores visuales para la detección de

escenas cuasi-duplicadas.� Universidad Autónoma de Madrid. 2011. España.

[41] A. y. C. M. Romero, �Comparativa de detectores de característicasticas visuales

y su aplicación al slam,� X workshop de agentes físicos, 2009.

[42] G. A. R. O. y. b. D. Ballesta, M., �Análisis de detectores y descriptores de ca-

racterísticas visuales en slam en entornos interiores y exteriores,� RIAI, vol. 7,

pp. 68�80, Abril 2010.

[43] T. T. y. V. G. L. Bay, H., �Surf: Speeded up robust features,� pp. 404�417,

European Conference on Computer Vision, 2006.

[44] C. Evans, �Notes on the open surf library,� 2009. http://www. chrisevansdev.com.

Accesado agosto, 2013.

[45] M. Viola, P. y Jones, �Rapid object detection using a boosted cascade of simple

features,� IEEE, 2001. Mitsubishi Electr. Res. Labs., Cambridge, MA, USA.

[46] J. X. y. W. Y. Han, B., �Optimized algorithm for gaussian second order derivative

�lters in fast hessian detector,� IEEE, 2010. China.

[47] D. Brown, M. y Lowe, �Invariant features from interest point groups,� pp. 656�

665, British Machine Vision Conference, 2002.

[48] D. Sorita, Reconocimiento automático mediante patrones biométricos de huella

dactilar. PhD thesis, Universidad Politécnica de Madrid, 2003. Accesado julio,

2014.

88

[49] M. J. Burgueño, �Las curvas roc en la evaluación de las pruebas diagnósticas,�

Medicina clínica, vol. 104, no. 17, pp. 661�670, 1995.

[50] I. Google, �What is android?,� 2014. http://developer.android.com. Accesado

junio, 2013.

89

Página intencionalmente en blanco

90

Anexo A

Diagrama de clases de la

arquitectura del framework

La Figura A.1 muestra el diagrama de clases de la arquitectura del framework obtenido

a través de ingeniería inversa con el empleo de la herramienta Enterprise Architect 6.5

versión de prueba.

91

Figura A.1: Diagrama de clases de la arquitectura del framework

92

Anexo B

Arquitectura de Android

El sistema operativo Android se compone por una arquitectura formada por capas para

facilitar la creación de las aplicaciones, así mismo ésta arquitectura permite el acceso

a capas inferiores por medio de librerías para evitar la programación a bajo nivel como

se indica en el sitio o�cial expuesto en [50], la Figura B.1 muestra la arquitectura en

capas de Android.

Figura B.1: Arquitectura de Android obtenido de [50]

93

A continuación se explica cada una de las capas que componen la arquitectura de

Android.

Kernel de Linux El núcleo del sistema operativo de Android se basa en el kernel de

Linux versión 2.6 adaptado a las características del hardware en el que se ejecuta. Actúa

como una capa de abstracción entre el hardware y las demás capas de la arquitectura,

el desarrollador emplea librerías para poder acceder al núcleo del sistema operativo.

El kernel se encarga de gestionar los recursos del dispositivo y del sistema operativo.

Librerías Son las bibliotecas nativas de Android, están escritas en C o C++ y com-

piladas para cada arquitectura especí�ca de los dispositivos. El objetivo de las librerías

es brindar funcionalidad a las aplicaciones en tareas repetitivas evitando codi�carlas

continuamente. Entre las librerías incluidas están: OpenGL (motor grá�co), bibliotecas

multimedia (formato de audio, video e imagen), Webkit (navegador), SSL (cifrado de

comunicaciones), FreeType (fuentes de texto) y SQLite (gestor de base de datos).

Entorno de ejecución No se considera una capa, ya que se forma por librerías.

Su principal componente es la máquina virtual Dalvik. Las aplicaciones se codi�can

en JAVA y son compiladas en un formato en especí�co para la máquina virtual las

ejecute.

Framework de aplicaciones Se forma por las clases y servicios que emplean las

aplicaciones, son librerías que acceden a los recursos de las capas inferiores por medio

de la máquina virtual Dalvik, las librerías que se encuentran en ésta capa son:

Activity Manager: Administra la pila de actividades de la aplicación y el ciclo de

vida de cada una de ellas.

Windows Manager: Organiza lo que se visualizará en pantalla, crea las super�cies

en la pantalla que emplearán las actividades.

Content Provider: Crea una capa que encapsula los datos a compartir entre las

aplicaciones.

Views: Son los elementos que ayudan a construir las interfaces de usuario: bo-

tones, etiquetas, cuadros de texto, entre otros.

94

Noti�cation Manager: Son los servicios que se emplean para noti�car al usuario

al mostrar alertas en la barra de estado.

Package Manager: Permite obtener información sobre los paquetes instalados

en el dispositivo y gestionar la instalación de nuevos paquetes.

Telephony Manager: Se emplea para realizar llamadas o enviar y recibir mensajes

de texto.

Resource Manager: Gestiona los elementos que son parte de las aplicaciones y

que se encuentran fuera del código.

Location Manager: Permite determinar la localización del dispositivo por medio

del GPS o redes disponibles.

Sensor Manager: Permite manejar el hardware del dispositivo, como el aceleró-

metro, brújula, sensor de presión, giroscopio, entre otros.

Cámara: Permite emplear las cámaras del dispositivo para tomar fotografías o

capturar video.

Multimedia: Permite reproducir y visualizar video, audio e imágenes.

Aplicaciones Incluye todas las aplicaciones del dispositivo, ya sea nativas, preins-

taladas o las que el usuario instala.

95

Página intencionalmente en blanco

96

Anexo C

Guía para la implementación del

framework

El framework se desarrolló en el IDE Eclipse con el plugin ADT para el desarrollo

en Android, para su implementación en el desarrollo de realidad aumentada en una

aplicación móvil en Android se requiere emplear 2 módulos del framework.

Almacenamiento de datos, para la gestión de los marcadores.

Captura y edición de video, para Iniciar el video de la cámara del dispositivo y

para visualizar en pantalla la realidad aumentada.

Para generar una aplicación no es necesario accesar al módulo de procesamiento,

debido a que éste módulo lo implementan en su codi�cación los módulos de almace-

namiento de datos y captura y edición de video. Para iniciar el video de realidad au-

mentada se requiere guardar al menos un marcador en el módulo de almacenamiento

de datos. Para implementar el framework se requiere importarlo al explorador de

proyectos y generar una nueva aplicación Android, se accesa a las propiedades de la

aplicación que se generó, en el apartado Android y en la opción Add. . . se selecciona

el framework y se aceptan las modi�caciones. Por último, en el AndroidManifest de

la aplicación se especi�ca que se empleará el framework dentro de la aplicación y los

permisos de usuario necesarios para que el framework accese a los servicios de Android

como se muestra en el Código C.1:

97

<a c t i v i t y and ro i d : name="com . l i b r e r i a . l i b r a r y . L i b r e r i a " ></a c t i v i t y ><uses−p e rm i s s i o n and ro i d : name="and ro i d . p e rm i s s i o n .CAMERA" /><uses−p e rm i s s i o n and ro i d : name="and ro i d . p e rm i s s i o n .ACCESS_FINE_LOCATION" />

Código C.1: AndroidManifest

Almacenamiento de datos Generar un nuevo Activity, la cual se encargará de ges-

tionar el empleo de los marcadores, los métodos que se implementan son: tomar_foto(),

buscar_foto(), guardar_foto() y ver(). Se crea una instancia de la clase Manejador

para poder gestionar el módulo de almacenamiento al guardar un nuevo marcador,

se inicializa en el método onCreate() y se le envía como parámetro el contexto de la

aplicación como se observa en el Código C.2:

Manejador f o t o= new Manejador ( g e tApp l i c a t i o nCon t e x t ( ) ) ;

Código C.2: Inicializar una instancia de la clase Manejador

Tomar una fotografía del marcador

En el activity de la clase se genera un nuevo botón y se especi�ca el método onClick

en el xml de la activity como se muestra en el Código C.3:

and ro i d : o nC l i c k="toma"

Código C.3: Método onClick del botón para tomar una fotografía

El botón al presionarse lanzará un nuevo activity con el objetivo de recibir el resultado.

El resultado del activity que se llamará será el que retorna el método tomar_foto()

de la instancia del manejador. En la clase del activity que se generó para el almace-

namiento de los marcadores se implementa el método del Código C.4:

p u b l i c vo i d toma ( View v ) {s t a r t A c t i v i t y F o r R e s u l t ( f o t o . tomar_foto ( ) , 1 ) ;}

Código C.4: Método para tomar fotografía

98

Debido a que el algoritmo que implementa el framework se basa en la detección de

puntos de interés de las imágenes, el contenido que esté en la fotografía del mar-

cador es el que será analizado, para evitar procesamiento de zonas que no sean de

interés se recomienda que el marcador que se capture en la fotografía esté contenido

completamente en la pantalla de la cámara para obtener un óptimo resultado.

Buscar una imagen para emplear como información a aumentar

El framework está implementado para que la información que se superponga en el

video sea una imagen, así mismo realiza una búsqueda en la galería del dispositivo para

seleccionar la imagen que se empleará, sin embargo, el desarrollador puede modi�car

ésta opción al accesar al método buscar_foto() de la clase Manejador. Para poder

realizar el procedimiento es necesario haber capturado de antemano un marcador. Se

requiere la creación de un botón en el activity de la clase y se especi�ca el método

onClick del botón en el xml de la activity como se muestra en el Código C.5:

and ro i d : o nC l i c k="busca "

Código C.5: Método onClick para el bóton buscar imagen

El botón permitirá lanzar un nuevo activity y obtener su resultado, el cual será el que

retorna el método buscar_foto() de la instancia del Manejador. Este procedimiento

requiere invocar al método onActivityResult en la clase de la aplicación para guardar

la imagen seleccionada del dispositivo como un Bitmap como se observa en el Código

C.6:

99

p u b l i c vo i d busca ( View v ){s t a r t A c t i v i t y F o r R e s u l t ( f o t o . busca r_foto ( ) , 2 ) ; }p r o t e c t e d vo i d o nA c t i v i t y R e s u l t ( i n t requestCode ,i n t r e su l tCode , I n t e n t data ) {

i f ( r eques tCode == 2){Ur i s e l e c t e d Image = data . getData ( ) ;InputSt ream i s ;t r y {

i s = ge tCon t en tRe s o l v e r ( ) .open InputSt ream ( s e l e c t e d Imag e ) ;Bu f f e r ed I npu tS t r eam b i s =new Bu f f e r ed I npu tS t r eam ( i s ) ;Bitmap bitmap =BitmapFactory . decodeStream ( b i s ) ;bitmap1 = Bitmap . c r ea t eSca l edB i tmap( bitmap , 320 , 240 , t r u e ) ;

} ca tch ( F i l eNotFoundExcep t i on e ) {}}

}

Código C.6: Método onActivityResult

Guardar un marcador

Para guardar el marcador en el módulo de almacenamiento se requiere haber capturado

una imagen y la información a aumentar. El Código C.7 se genera en el método onClick

que se inicializa en el xml del activity para almacenar el marcador:

and ro i d : o nC l i c k="guarda "

Código C.7: Método onClick del botón para almacenar un marcador

El botón llamará al método guardar_foto(Bitmap bitmap) de la clase Manejador

enviándole el Bitmap obtenido de la búsqueda en la galería como se muestra en el

Código C.8:

p u b l i c vo i d guarda ( View v ){f o t o . guarda_foto ( bitmap1 ) ;

}

Código C.8: Método para guardar una foto

100

Consulta al módulo de almacenamiento

Para realizar una consulta en el módulo de almacenamiento se requiere generar los

EditText donde se mostrará la información. Se genera un botón que permita llamar al

método ver(String id) de la clase Manejador enviando el identi�cador del marcador a

mostrar, el método devuelve un ArrayList de objetos de tipo Strings que contiene en la

posición 0 la cantidad de puntos de interés encontrados, en la posición 1 la latitud, en

la posición 2 la longitud y en la posición 3 el descriptor de características de los puntos

de interés. Para poder mostrar la información es necesario que esté almacenado al

menos un marcador en el módulo de almacenamiento de datos. En el xml del activity

se generán los EditText que contendrán la información y se de�ne el método onClick

del botón que iniciará el proceso como se muestra en el Código C.9:

and ro i d : o nC l i c k="c on s u l t a "

Código C.9: Método onClick del botón para consultar registros

Se inicializan los EditText en el método onCreate() de la clase del activity y se imple-

menta el método del Código C.10:

p u b l i c vo i d c o n s u l t a ( View v ){S t r i n g i d = t1 . getText ( ) . t o S t r i n g ( ) ;A r r a yL i s t <St r i ng> v a l=uno . v e r ( i d ) ;t2 . s e tTex t ( v a l . ge t ( 0 ) ) ;t3 . s e tTex t ( v a l . ge t ( 1 ) ) ;t4 . s e tTex t ( v a l . ge t ( 2 ) ) ;t5 . s e tTex t ( v a l . ge t ( 3 ) ) ;

}

Código C.10: Método para consultar registros

Captura y edición de video Para iniciar el video para mostrar la realidad au-

mentada se requiere que esté guardado al menos un marcador en el módulo de al-

macenamiento. Para generar el video se requiere crear una nueva activity en la cual

se creará una instancia de la clase Salida y en el método onCreate() de la clase de

la activity se inicializa la instancia enviándole el contexto de la aplicación como se

muestra en el Código C.11:

101

S a l i d a s a l i d a=new Sa l i d a ( g e tApp l i c a t i o nCon t e x t ( ) ) ;

Código C.11: Inicializar una instancia de la clase Salida

Para mostrar el video en la pantalla del dispositivo se requiere llamar al método

SetContentView() al cual se le envía el método getCaptura() de la clase Salida para

visualizar en la pantalla la información de la cámara del dispositivo como se observa

en el Código C.12:

se tContentV iew ( s a l i d a . ge tCaptu ra ( ) ) ;

Código C.12: Visualizar video

Para mostrar la información que se genera del procesamiento de la información se

genera el Código C.13 donde se llama al método addContentView() al cual en la

opción del View se le envía al método getEdición() de la clase Salida.

addContentView ( s a l i d a . g e tEd i c i o n ( ) , new LayoutParams ( LayoutParams .WRAP_CONTENT, LayoutParams .WRAP_CONTENT) ) ;

Código C.13: Visualizar video procesado

El framework permite que el desarrollador modi�que los módulos requeridos para

generar las aplicaciones así como sustituirlos por módulos que requiera emplear, siem-

pre y cuando las entradas y salidas de cada método utilicen los mismos formatos

requeridos como se muestra en la arquitectura del framework en el Capítulo 3 del

documento de tesis. Para un óptimo emparejamiento de las imágenes del video con

los marcadores se requiere que la imagen capturada por el video contenga únicamente

al marcador visible por la cámara del dispositivo para evitar el procesamiento de datos

no necesarios para el emparejamiento de las imágenes. El algoritmo que implementa

el framework permite el reconocimiento del marcador ante cambios de rotación, escala

e iluminación especi�cados en el Capítulo 4 del documento de tesis.

102

Anexo D

Publicación

A continuación se presenta la publicación generada con base al presente trabajo de

investigación.

103

Análisis de la Realidad Aumentada en Dispositivos Móviles

J. Cruz-León1, J. Rodríguez-Flores

2, J. Martínez-Mireles

3

1Maestria en Tecnologías de la Información/ CA-Cibernética y Cómputo Aplicado,Universidad Politécnica de Pachuca,

Zempoala, Hidalgo, México. CP. 43830. Tel. 7715477510, ext.2223, e-mail: jorge_scl@hotmail.com

Resumen (TIF)

La realidad aumentada es una tecnología que le brinda al usuario la posibilidad de adquirir información adicional sobre

el entorno que lo rodea. Debido a ésta función, en la actualidad se incrementó el desarrollo de aplicaciones que hacen

uso de ella. El presente artículo muestra una comparativa entre los principales sistemas operativos para dispositivos

móviles. Se mencionan las definiciones y características generales de la realidad aumentada, así como el desglose de

cada una. Además se realizó un análisis del estado del arte de ésta en los dispositivos móviles y los resultados que se

obtuvieron.

Palabras clave: Dispositivos Móviles, Geolocalización, Realidad Aumentada, Reconocimiento de Patrones.

Abstract (TIF)

Augmented reality is a technology that gives to the user the ability to acquire complementary information about the

surrounding environment, because of this feature, now increased the development of applications that make use of it.

This paper shows a comparison between the major mobile operating systems. This work mentions the definitions and

general characteristics of augmented reality, as well as a breakdown of each one. We also carried out an analysis of this

state of the art in mobile devices and present the results obtained.

Keywords: Augmented reality, geo localization, mobile devices, patterns recognition.

1. Introducción

La realidad aumentada es una tecnología que permite

superponer cualquier tipo de contenido virtual (audio,

video, imágenes o texto) sobre el entorno real, con el

objetivo de brindar mayor información de lo que se está

observando. Lo anterior se consigue al utilizar un

dispositivo que cuente con los elementos que se

requieren o mediante la combinación de diversos

dispositivos que permiten ésta interacción, como: una

cámara que capta las imágenes del mundo real, una

computadora que realiza el procesamiento de la imagen

recibida y genera la realidad aumentada y una pantalla

que muestra al usuario la información final. Debido a los

resultados que se obtienen con ésta tecnología, se

desarrollan aplicaciones que se utilizan en diferentes

campos de acción, como en medicina, arquitectura,

diseño, ciencias educativas, entre otras. Sin embargo, el

procesamiento que se requiere para realizar dichas

aplicaciones, dificulta explotarla en los dispositivos

móviles, puesto que cuentan con capacidades de

procesamiento limitadas.

2. Antecedentes

El desarrollo de tecnologías móviles que permiten la

comunicación entre las personas y localización de

lugares, así como la fácil adquisición de dispositivos

móviles (Smartphones, tabletas) favorece el auge de

aplicaciones novedosas y de gran utilidad para el usuario,

las cuales emplean los recursos que brindan los

dispositivos, entre ellas la realidad aumentada, como se

observa en [1].

2.1 Dispositivos móviles

Un dispositivo móvil es un aparato portable, con

velocidad de procesamiento, acceso a redes WiFi,

memoria limitada, para ejecutar aplicaciones generales

[2].

Sistemas operativos para dispositivos móviles

El sistema operativo es el software básico de un

dispositivo que provee una interfaz entre las aplicaciones

instaladas, el hardware y el usuario [2]. Existen

diferentes plataformas como: Symbian OS, Windows

Phone, Android, iOS y Blackberry OS. A continuación se

describe cada una.

Symbian OS

Lo desarrolló Nokia, Sony Ericsson y Samsung entre

otras empresas en el año de 1998. Adapta e integra todo

tipo de aplicaciones y proporciona las rutinas, los

protocolos de comunicación, el control de archivos y los

servicios para su funcionamiento. Está escrito en C++

[3].

Windows Phone

Se desarrolló en 2010 como sucesor de la versión

Windows Mobile que genera Microsoft. Es un sistema

operativo móvil compacto que se basa en el núcleo del

sistema operativo de Windows NT. Su diseño es similar

a las versiones de escritorio de Windows. El lenguaje de

desarrollo de aplicaciones que utiliza es C# [4].

Android

Se desarrolló en 2008, su núcleo se basa en Linux,

aunque su diseño inicial fue para funcionar en

dispositivos móviles en la actualidad también es utilizado

en tabletas y PC. Su estructura se compone de

aplicaciones que se ejecutan en un framework JAVA de

aplicaciones orientadas a objetos sobre el núcleo de las

bibliotecas de JAVA en una maquina virtual Dalvik [5].

iOS para iPhone

Se desarrolló en 2007 por Apple, originalmente para el

iPhone, siendo también se utiliza en el iPod Touch e

iPad, se deriva de Mac OS X. En 2008 se liberó un SDK

gratuito el cual permite hacer aplicaciones para iPhone

con el lenguaje de programación Objetive-C [6].

Blackberry OS

Se desarrolló en 1999 por la empresa canadiense RIM

(por las siglas en inglés de Research In Motion) para sus

dispositivos. El sistema permite aplicaciones multitarea y

tiene soporte para diferentes métodos exclusivos de RIM

(trackwheel, trackball, touchpad y pantallas táctiles). El

lenguaje de desarrollo de aplicaciones que utiliza es

JAVA [7].

Comparativa de Sistemas Operativos Móviles

Debido a que el kernel es el núcleo del sistema operativo,

gestiona los recursos del sistema, por esto se debe

conocer cuál es el kernel que maneja cada sistema

operativo (ver tabla 1).

Tabla 1. Comparativa de sistemas operativos Sistema

operativo

Kernel Desarrollador Lenguaje de

desarrollo

Android Linux con

maquina

virtual Dalvik

Google JAVA

Blackberry

OS

QNX RIM JAVA

iOS de iPhone Mac OS X Apple Objetive-C

Windows

phone 8

Windows NT Microsoft C#

Symbian OS EKA 2 Nokia C++

Android no es un sistema operativo propietario, esto

significa que la empresa que lo fabrica no es la dueña del

sistema operativo, lo que pueda ser instalado en diversos

dispositivos, así mismo, por ser de código abierto

permite el libre desarrollo de aplicaciones para la

plataforma.

.

2.3 Realidad Aumentada

La realidad aumentada es una tecnología que tiene sus

orígenes a mediados del siglo XX [8]. En 1968,

Sutherland [9] desarrolló “La espada de Damocles” que

era un display de cabeza para generar la primera realidad

virtual y realidad aumentada en un dispositivo de este

tipo.

En el año de 1994 Paul Milgram y Fumio Kishino [10],

definen la realidad de Milgram-Virtuality Continuum

como un entorno que se observa desde la parte real, hasta

la parte virtual, de modo continuo, en la parte media de

dicho entorno se encuentra la realidad mixta, que es la

mezcla entre ambos entornos. La realidad aumentada es

la parte más cercana a la realidad, con ciertos aspectos

virtuales (ver fig. 1).

Fig. 1. Realidad de Milgram-Virtuality Continuum

En 1997, Ronald Azuma [11] propone la definición más

aceptada de la realidad aumentada, establece a la realidad

aumentada como la unión de tres aspectos principales,

expuestos de la siguiente manera:

a) Combinar elementos reales, con elementos virtuales,

b) La relación de a) se da estrictamente en tiempo real y

c) La información que se muestra debe estar registrada en

3 dimensiones.

Tareas en la Realidad Aumentada

Existen cuatro tareas principales que se llevan a cabo al

implementar la realidad aumentada [8]:

Captación del entorno

Captura el entorno al cual se le superpondrá la

información virtual. Requiere de un dispositivo que

permita reconocer la escena para después procesarla. En

el caso de los dispositivos móviles es la cámara la que

realiza la tarea.

Identificación del entorno

Se encarga de analizar el entorno que se capturó, éste

proceso pude realizarse mediante el reconocimiento de

marcadores, estimación de la posición o por una

identificación híbrida la cual es una mezcla de ambas.

Aumento de la realidad

Es la tarea que superpone la información virtual (texto,

imagen, video, audio) en el entorno real que se capturó.

Realidad mixta

Entorno real

Realidad

aumentada

Virtualidad

aumentada Entorno virtual

Visualización

Es el último proceso que se realiza de la realidad

aumentada, consiste en mostrar el escenario aumentado

al usuario por medio de un dispositivo de visualización.

Arquitectura de Referencia de sistemas de realidad

aumentada

En 2002, Brügge [12] realiza un estudio entre 18

arquitecturas diferentes de realidad aumentada,

generando una arquitectura de referencia, la cual está

presente en todas ellas (ver Fig. 2). A continuación se

describe esta arquitectura:

Descripción de los paquetes de la arquitectura

Aplicación: Este paquete se encarga de la lógica del

sistema.

Tracking: Determina la posición y orientación de los

usuarios y objetos.

Control: Procesamiento de la información de entrada.

Presentación: Representación gráfica de la información.

Contexto: Recoge información del contexto.

Modelo del Mundo: Almacena información relacionada

con los objetos virtuales y reales.

Requerimientos de la Realidad Aumentada Móvil

Los requerimientos tecnológicos necesarios para generar

la realidad aumentada son [13]:

Procesador móvil: Se utiliza para procesar la

información de entrada y ejecutar la aplicación.

Hardware gráfico: Unidad de procesamiento gráfico

(GPU) para generar las imágenes virtuales.

Cámara: dispositivo que se utiliza para capturar las

imágenes de video del entorno en tiempo real.

Display: Para mostrar la vista de la realidad aumentada,

la superposición de las imágenes virtuales.

Acceso de redes: para permitir la conexión a accesos

remotos.

Sensores: GPS, magnetómetro, acelerómetro, para

especificar la posición y orientación del dispositivo.

Tipos de realidad aumentada

De acuerdo con Abril [8], existen dos tipos principales de

realidad aumentada que pueden llevarse a cabo:

Reconocimiento por marcadores.

Reconocimiento sin marcadores.

Reconocimiento por marcadores

Un marcador es una imagen reconocida por el software

de realidad aumentada. Este reconocimiento se realiza

por medio de su geometría, color o ambas características.

Un sistema adecuado de reconocimiento de patrones,

cuenta con un sensor que recoge la imagen del mundo

real, un mecanismo de extracción de características el

cual obtiene la información de utilidad y elimina aquella

irrelevante para el procesamiento, por último una etapa

de toma de decisiones para el reconocimiento del

marcador y la interpretación de la escena.

Reconocimiento sin marcadores

Puede llevarse a cabo mediante identificación por

posicionamiento o reconocimiento de imágenes.

Identificación por posicionamiento

La identificación de entorno mediante este proceso se

realiza debido a la estimación de la posición y

orientación del usuario. Existen sistemas de

posicionamiento que brindan la información necesaria al

dispositivo para realizar este tipo de realidad aumentada.

El Sistema de Posicionamiento Global (por las siglas en

inglés de GPS) es un servicio de los EE.UU. que

proporciona a los usuarios información sobre

navegación, posicionamiento y cronometría.

Reconocimiento de imágenes

Es el proceso que consiste en extraer, de una imagen o un

segmento de video, la información necesaria del entorno

para identificar la región a la cual se realizará la

superposición de elementos virtuales. El proceso se

realiza principalmente por medio de visión artificial, en

el caso de reconocimiento de escenarios de manera

automática, o por medio de marcadores, los cuales ya

están preestablecidos en el sistema. Se divide en dos

partes principales, la adquisición de la imagen, por medio

de cualquier dispositivo especializado y el procesamiento

digital de la imagen que se capturó, para obtener una

imagen con características mejor definidas para su

interpretación.

Fig. 2 Arquitectura de referencia

3. Estado del arte de realidad aumentada en

dispositivos móviles

A continuación se enlistan los frameworks de realidad

aumentada que existen actualmente, así como las

investigaciones académicas relacionadas con el análisis,

diseño y desarrollo de la tecnología.

3.1 Frameworks

Layar

Es una aplicación comercial de realidad aumentada para

Android, se basa tanto en geolocalización como en

marcadores, en específico códigos QR, sin embargo, no

mezcla ambos procesos. Utiliza el GPS, la brújula y otros

sensores del teléfono móvil para proporcionar una

visualización de varios puntos de interés ordenados por

capas o niveles, donde cada una maneja un aspecto

diferente. Para poder instalarlo se requiere sistema

operativo Android 1.5 o superior o iOs 3.1 o superior,

cámara digital, GPS, brújula, acelerómetro y conexión a

internet [14].

Mixare

Es un navegador de realidad aumentada de código

abierto (licencia GPLV3). Disponible para Android y para

iPhone 3GS. Muestra en la pantalla la información que se

encuentra alrededor del dispositivo, proveniente de

Twitter y wikipedia [15].

Look!

Es un software que se desarrolló como proyecto de fin de

carrera de la universidad Complutense de Madrid durante

el curso académico 2010-2011 [16]. Sus autores son

Sergio Bellón Alcarazo, Jorge Creixell Rojo y Angel

Serrano Laguna. Es un software libre bajo la licencia

GPLV3. El Software ofrece servicios de localización tanto

en exteriores por medio de GPS así como en interiores

utilizando señales WiFi.

AndAR

Es un framework que funciona en Android [17]. Se

encuentra bajo la licencia GNU, por lo cual es de

software libre. Permite la superposición de objetos

tridimensionales sobre un marcador convencional

reconocible por el sistema.

A continuación se muestra una comparativa entre los

frameworks que se citaron anteriormente (ver tabla 2). La

tabla indica cuales son las fortalezas y limitantes de cada

uno tomando en cuenta distintos aspectos que influyen en

su funcionalidad y alcances.

Tabla 2. Comparativa de Frameworks de realidad

aumentada.

3.2 Proyectos académicos

El trabajo de López Pombo [18], explica diversas

técnicas de desarrollo de realidad aumentada en equipos

de cómputo, las arquitecturas que se emplearon para cada

una de ellas, así como las situaciones idóneas para

implementarlas. A modo de ejemplo, desarrolla dos

prototipos de sistemas de realidad aumentada para

móviles, utiliza marcadores blanco y negro con formas

rectangulares mediante el desarrollo de algoritmos

específicos que se elaboraron con base al análisis de la

información que se maneja en cada uno de los casos de

estudio.

Domhan [17], muestra el desarrollo del Framework de

realidad aumentada AndAR, utiliza como base

ArtToolkit. Dicho framework permite el uso de

marcadores convencionales. Por último, genera una

aplicación con reconocimiento de marcadores

rectangulares en tonos blanco y negro.

El trabajo de Gaip Weng [19], desarrolla una propuesta

de integración de dos técnicas diferentes de realidad

aumentada, la geolocalización con un algoritmo de

reconocimiento de características de imágenes de nombre

SURF (por las siglas en inglés de Speeded Up Robust

Feature), comparándolas con otras, almacenadas en una

base de datos. Las operaciones las realiza directamente

en el dispositivo móvil iPhone. Mediante el algoritmo de

reconocimiento de imagen, extrae las características

necesarias de la imagen que se capta, las compara con

otras almacenadas en una base de datos local del sistema,

si se encuentra, se procede a la realización de la realidad

aumentada.

El trabajo de Turunen [20], genera una propuesta de

relación entre redes sociales y la realidad aumentada en

dispositivos móviles. El objetivo principal de la

aplicación, es permitir al usuario obtener la ubicación de

los contactos que pertenecen a una red social y los más

cercanos a su posición. Genera una aplicación de prueba

denominada LocTrac. Sin embargo encuentra

inconvenientes con las velocidades de procesamiento y el

posicionamiento del dispositivo.

Aplicación Look! Layar Mixare AndAR

Integración

con cámara

X X X X

2D X X X

3D X X X

Localización

GPS

X X

Marcadores

convencionales

X X X

El trabajo de Santoso [21], muestra el uso de la realidad

aumentada móvil en la enseñanza al generar una

aplicación que se basa en el juego tangram, utiliza las

características ofrecidas por los dispositivos móviles.

Jaegeol Yim en su artículo Implementation of Building

Recognition Android App [22], explica el desarrollo de

una aplicación de reconocimiento de edificios que utiliza

mapas electrónicos. En una base de datos local, se

almacenan los datos de localización de determinados

edificios, mediante el dispositivo móvil se toma una

fotografía del entorno, así mismo se captura la posición

del dispositivo, mediante un algoritmo de reconocimiento

de objetos, se calcula la distancia entre el dispositivo y el

entorno captura, se compara con los datos almacenados

en la base, se obtiene el edificio que se observa y se

muestra un video en la ubicación indicada. La

investigación surge de los errores de posicionamiento

existentes al utilizar la geolocalización en los

dispositivos móviles, se comprueba que a través de este

procedimiento se evitan esos fallos.

El trabajo de Chen Jing, Guo Junwei y Wang Yongtian

[23] muestra un sistema de reconocimiento de imágenes

para un museo mediante realidad aumentada, utilizando

una ultra móvil PC. Se utilizan histogramas HSV (Hue

Saturation Value) para reducir la base de datos de

búsqueda de imágenes y a través de un algoritmo de

aprendizaje supervisado realiza el reconocimiento de la

imagen. Al realizar las pruebas necesarios, tuvieron

aceptación con el uso de la tecnología y el dispositivo,

sin embargo, la velocidad de procesamiento fue lenta.

En el trabajo de Behzadan y Kamat [24], se realiza un

software que se llama UM-AR-GPS-ROVER. Su

enfoque es la generación de objetos a través de realidad

aumentada de utilidad para la construcción. Este software

utiliza un HMD (por las siglas en inglés de head-

mounted display) con un recibidor GPS y seguidor de

orientación, una laptop donde se realizan los

procedimientos y una videocámara. Mediante

posicionamiento GPS y orientación 3 DOF (por las siglas

en inglés de Degrees of Freedom), calcula la posición en

la cual se mostrará el objeto que se aumenta y se calcula

la distancia entre la posición del objeto y la del

dispositivo GPS, con ello, se genera el gráfico con la

posición y tamaño adecuado. A pesar de considerar la

arquitectura del proyecto como móvil, se basa en la

conjunción de diversos dispositivos, ligando a cada uno

una actividad en específico.

El artículo de Jie y Shen [25], muestra el desarrollo de

una aplicación que elimina el problema de la oclusión

(interferencia de objetos) en la realidad aumentada. Su

análisis se basa en la implementación del algoritmo SIFT

(por las siglas en inglés de Scale Invariant Feature

Transformation) y el algoritmo RANSAC (por las siglas

en inglés de RANdom SAmple Conesenus). Utiliza el

contorno de los objetos que interfieren en la muestra de

la imagen aumentada, esta imagen se genera detrás del

objeto que se interpone. En la aplicación no es necesario

el uso de marcadores, por lo que los objetos que se

generan pueden ser móviles o deformables.

David Prochazka [26], realiza una aplicación de realidad

aumentada, la cual se enfoca en el diseño de vehículos, el

usuario carga la imagen de la parte del vehículo que

desea modificar. Utiliza un algoritmo de reconocimiento

de imágenes, implementa redes neuronales, en específico

un perceptrón multicapa, debido a la complejidad de

procesamiento de la red neuronal, esta se implementa en

la nube y se entrena con información que se almacena en

una base de datos remota.

Tabla 3.Comparativa del estado del arte. Artículo Característica

[17] Reconocimiento de marcadores utilizando ArTool

Kit

[18] Análisis de procedimientos de reconocimiento de

imágenes

[19] Implementación del algoritmo SURF y una base de

datos local

[20] Geolocalización y redes sociales

[21] Uso de marcadores rectangulares y en blanco y negro

[22] Mapas electrónicos y algoritmo de reconocimiento

[23] Histogramas HSV y algoritmo de aprendizaje

supervisado

[24] Posicionamiento GPS y orientación 3 DOF

[25] Algoritmo SIFT y RANSAC

[26] Procesamiento y bases de datos en la nube

4. Conclusiones

Las aplicaciones para dispositivos móviles que utilizan

geolocalización utilizan una base de datos con las

características de posicionamiento de los elementos a

aumentar y realizan una comparativa con los datos

obtenidos del dispositivo, esto disminuye los fallos

ocasionados por los cambios de posición del propio

dispositivo.

Una de las técnicas más utilizadas de realidad aumentada

en dispositivos móviles es el uso de códigos QR debido a

que no utiliza procesamiento tan complejo para

desarrollar e incrustar información en él.

Con relación al procesamiento y el almacenamiento de la

información, se realiza en servidores remotos o

procesamiento en la nube para que la aplicación no

utilice los ya escaso recursos del dispositivo.

Se implementan diversos algoritmos de reconocimiento

de imágenes enfocados a disminuir la complejidad del

procesamiento de la información, dependiendo el entorno

analizar.

Con base al análisis que se realizó en el presente artículo,

se propone generar un framework de desarrollo de

realidad aumentada para dispositivos móviles con la

utilización de algoritmos de reconocimiento de imágenes

como SURF y SIFT. Para el almacenamiento de la

información se propone el manejo de bases de datos

locales con claves de latitud y longitud que se obtienen

por medio de geolocalización.

5. Referencias

[1] Arroyo, N. Información en el móvil. 2011. UOC.

Barcelona, España.

[2] Baz Alonso, A; Ferreira Artime, I; Álvarez

Rodriguez, M; García Baniello R. “Dispositivos

móviles”. 2009.

[3] Obando, C. 2010 (26 de agosto de 2013).

http://symbianparamoviles.blogspot.com/

[4] Moreno, F. 2013 (26 de agosto de 2013).

http://blog.techdencias.net/blog/2013/03/17/introdu

ccion-al-desarrollo-de-aplicaciones-en-windows-

phone-8/

[5] Vilchez, A. 2009 (26 de agosto de 2013).

http://www.configurarequipos.com/doc1107.html

[6] Bitelia. 2011 (26 de agosto de 2013).

http://www.poderpda.com/plataformas/apple/ios-

su-nacimiento-desarrollo-e-historia/

[7] Umiastowski, C. 2013 (26 de agosto de 2013).

http://crackberry.com/history-qnx-and-

it%E2%80%99s-implementation-blackberry-10

[8] Abril Redondo, D. “Realidad Aumentada”. 2010.

[9] Sutherland, I. “The ultímate display”. IFIP

Congress. 1965. Pp.506-508.

[10] Milgram, P. y Kishino, F. "Taxonomy of Mixed

Reality Visual Displays". 1994. Pp. 1321-1329.

[11] Azuma, R. “A survey of Augmented Reality”.

Teleoperators and Virtual Environments. 1997. Pp.

355-385.

[12] Brügge, B. “Study on Software Arquitectures for

Augmented Reality Systems”. ARVIKA

consortium. 2002.

[13] Billinghurst, M. “Mobile Collaborative Augmented

Reality”. Recent Trends of Mobile Collaborative

Augmented Reality Systems. 2011. Pp. 1-21.

[14] Layar. 2013 (16 de junio de 2013).

https://www.layar.com/

[15] Mixare. 2013 (16 de junio de 2013).

http://www.mixare.org/

[16] Bellón, S., Creixell, J., y Serrano, A. “Look!

Framework para aplicaciones de realidad

aumentada en Android”. 2010.

[17] Domhan, T. “Augmented Reality on Android

Smartphones”. 2010.

[18] López Pompo, H. “Análisis y Desarrollo de

Sistemas de Realidad Aumentada”. Universidad

Complutense de Madrid. 2009.

[19] Gaip Weng, E. N. “A Framework for Outdoor

Mobile Augmented Reality”. International Journal

of Computer Science Issues, Vol. 9. 2012. Pp. 419-

423.

[20] Turunen, T. “Mobile AR Requirements for Location

Based Social Networks”. The International Journal

of Virtual Reality. 2010. Pp. 67-78.

[21] Santoso, M. “Development of Edutainment Content

for Elementary School using Mobile Augmented

Reality”. 4th International Conference on Computer

Research and Development IPCSIT Vol. 39. 2012.

[22] Yim, J. “Implementation of Building Recognition

Android App”. International Journal of Multimedia

and Ubiquitous Engineering, 7 (2). 2012. Pp. 37-52.

[23] Jing, C.; Junwei, G. y Yongtian, W. “Mobile

Augmnted Reality System for Personal Museum

Tour Guide Applications”. 2011.

[24] Behzadan, A., y Kamat, V. “Georeferenced

Registration of Construction Graphics in Mobile

Outdoor Augmented Reality”. Journal of

Computing in Civil Engineering. 2007. Pp. 247-

258.

[25] Jie, L., y Zheng, X. “Invariant Based Augmented

Reality on Mobile Phones”. Journal of Multimedia.

5 (6). 2010. Pp. 588-595.

[26] Prochazka, D.; Stencl, M.; Popelka, O.; y Stastny, J.

“Mobile Augmented Reality Applications”.

Universidad Mendel, Brno, Rep. Checa. 2011.

Realidad Aumentada

Reconocimiento con marcadores Reconocimiento sin marcadores

Identificación por posicionamiento

Reconocimiento de imágenes

Análisis de la Realidad Aumentada

en Dispositivos Móviles J. Cruz León, J. Rodríguez Flores, J. Martínez Mireles

Laboratorio CA-Cibernética y Cómputo Aplicado, Universidad Politécnica de Pachuca. Zempoala, Hidalgo, México. CP. 42083, Tel. (52)7715477510, e-mail: jorge_scl@hotmail.com

Dirección de Ingeniería de Software/Laboratorio CA-Cibernética y Cómputo Aplicado, Universidad Politécnica de Pachuca. Zempoala, Hidalgo, México. CP. 42083

Introducción

La realidad aumentada es una tecnología que permite superponer cualquier

tipo de contenido virtual (audio, video, imágenes o texto) sobre el entorno

real, con el objetivo de brindar mayor información de lo que se observa.

Debido a los resultados que se obtienen con ésta tecnología, se desarrollan

aplicaciones que se utilizan en diferentes campos de acción, como en

medicina, arquitectura, diseño, ciencias educativas, entre otras. Sin

embargo, el procesamiento que se requiere para realizar dichas

aplicaciones, dificulta explotarla en los dispositivos móviles, puesto que

cuentan con capacidades limitadas.

Un dispositivo móvil es un aparato portable, con velocidad de

procesamiento y memoria limitadas para ejecutar aplicaciones generales

[1]. Para realizar la interacción entre el dispositivo y el hardware se utiliza el

SO (Sistema Operativo), del cual existen diversas plataformas, donde las

más importantes son: Symbian OS, Windows Phone, Android, iOS y

Blackberry OS. A continuación se mencionan las características principales

de cada uno:

Estado del Arte

Sistema operativo Desarrollador Kernel Lenguaje de

desarrollo

Android Google Linux (maquina virtual Dalvik) JAVA

Blackberry OS RIM QNX JAVA

iOS de iPhone Apple Mac OS X Objetive-C

Windows phone 8 Microsoft Windows NT C#

Symbian OS Nokia EKA 2 C++

Aplicación Look! Layar Mixare AndAR

Integración con cámara X X X X

2D X X X

3D X X X

Localización GPS X X

Marcadores convencionales X X X

Artículo Característica

[4] Reconocimiento de marcadores utilizando ArTool Kit

[5] Análisis de procedimientos de reconocimiento de imágenes

[6] Implementación del algoritmo SURF y una base de datos local

[7] Geolocalización y redes sociales

[8] Uso de marcadores rectangulares y en blanco y negro

[9] Mapas electrónicos y algoritmo de reconocimiento

[10] Histogramas HSV y algoritmo de aprendizaje supervisado

[11] Posicionamiento GPS y orientación 3 DOF

[12] Algoritmo SIFT y RANSAC

[13] Procesamiento y bases de datos en la nube

Conclusiones

Referencias

Tabla 1. Características de sistemas operativos.

Tabla 2. Comparativa de Frameworks de realidad aumentada.

Tabla 3.Enfoque de los trabajos de investigación sobre realidad aumentada.

Realidad mixta

Entorno real Realidad

aumentada

Virtualidad

aumentada Entorno virtual

Fig. 1. Realidad de Milgram-Virtuality Continuum

De acuerdo al proceso de identificación de entorno, la realidad aumentada

puede ser de 2 tipos [3], como se muestra en la siguiente figura.

Realidad Aumentada

En el año de 1994 Paul Milgram y Fumio Kishino [2] proponen una de las

definiciones más aceptadas de la realidad aumentada, donde crean la

realidad de Milgram-Virtuality Continuum, la cual es un entorno que se

observa desde la parte real hasta la parte virtual de modo continuo, donde

la realidad aumentada es la parte más cercana a la realidad, con la

superposición de ciertos aspectos virtuales.

Fig. 3. Tipos de realidad aumentada

Captación del entorno

Identificación del entorno

Aumento de la realidad

Visualización

Fig. 2. Tareas de la realidad aumentada

[1] Baz Alonso, A; Ferreira Artime, I; Álvarez Rodriguez, M; García Baniello R. “Dispositivos móviles”. 2009.

[2] Milgram, P. y Kishino, F. "Taxonomy of Mixed Reality Visual Displays". 1994. Pp. 1321-1329.

[3] Abril Redondo, D. “Realidad Aumentada”. 2010. Reporte técnico.

[4] Domhan, T. “Augmented Reality on Android Smartphones”. 2010. Reporte técnico.

[5] López Pompo, H. “Análisis y Desarrollo de Sistemas de Realidad Aumentada”. Universidad Complutense de

Madrid. 2009. Tesis de maestría.

[6] Gaip Weng, E. N. “A Framework for Outdoor Mobile Augmented Reality”. International Journal of Computer

Science Issues, Vol. 9. 2012. Pp. 419- 423.

[7] Turunen, T. “Mobile AR Requirements for Location Based Social Networks”. The International Journal of Virtual

Reality. 2010. Pp. 67-78.

[8] Santoso, M. “Development of Edutainment Content for Elementary School using Mobile Augmented Reality”.

4th International Conference on Computer Research and Development IPCSIT Vol. 39. 2012.

[9] Yim, J. “Implementation of Building Recognition Android App”. International Journal of Multimedia and

Ubiquitous Engineering, 7 (2). 2012. Pp. 37-52.

[10] Jing, C.; Junwei, G. y Yongtian, W. “Mobile Augmented Reality System for Personal Museum Tour Guide

Applications”. 2011.

[11] Behzadan, A., y Kamat, V. “Georeferenced Registration of Construction Graphics in Mobile Outdoor

Augmented Reality”. Journal of Computing in Civil Engineering. 2007. Pp. 247-258.

[12] Jie, L., y Zheng, X. “Invariant Based Augmented Reality on Mobile Phones”. Journal of Multimedia. 5 (6).

2010. Pp. 588-595.

[13] Prochazka, D.; Stencl, M.; Popelka, O.; y Stastny, J. “Mobile Augmented Reality Applications”. Universidad

Mendel, Brno, Rep. Checa. 2011. Reporte técnico.

Existen cuatro tareas principales que se llevan a cabo al implementar la

realidad aumentada [3]:

Se mencionan los puntos relevantes del análisis que se realizó:

Una de las técnicas que más se utilizan para el desarrollo de realidad

aumentada en dispositivos móviles es el uso de códigos QR.

El procesamiento y almacenamiento de la información se realiza en

servidores remotos o en la nube.

Dentro de los algoritmos que más se utilizan para el reconocimiento de

imágenes están SURF (Speeded Up Robust Feature) y SIFT (Scale

Invariant Feature Transformation).

A continuación se enlistan los frameworks de realidad aumentada que

existen actualmente, así como las investigaciones académicas

relacionadas con el análisis, diseño y desarrollo de la tecnología.

La tabla anterior indica cuales son las fortalezas y limitantes de cada

Framework tomando en cuenta distintos aspectos que influyen en su

funcionalidad y alcances.

Generar realidad aumentada en dispositivos móviles requiere optimizar los

recursos del dispositivo debido a las limitantes de los mismos, por lo que se

sugieren los siguientes aspectos para su desarrollo:

Utilizar geo localización para disminuir las consultas de búsqueda en las

bases de datos de las aplicaciones.

Utilizar algoritmos que disminuyan la complejidad del procesamiento en

el dispositivo, como son: SURF y SIFT.