procesador paralelo para la recuperacion 3d a partir del
TRANSCRIPT
Procesador Paralelo para larecuperacion 3D a partir del
Flujo Optico.
por
Jose Hugo Barron Zambrano
Tesis sometida como requisito parcial paraobtener el grado de
Maestro en Ciencias en la especialidad deCiencias Computacionales
en el
Instituto Nacional de Astrofısica, Optica yElectronica
Noviembre 2008Tonantzintla, Puebla
Supervisada por:
Dr. Miguel O. Arias Estrada.
c©INAOE 2008El autor otorga al INAOE el permiso de
reproducir y distribuir copias en su totalidad o enpartes de esta tesis
I
a
Abstract.
Resumen.
En los ultimos anos la recuperacion 3D ha sido uno de los principales esfuer-
zos en los sistema de vision computacional. Dado que la recuperacion 3D deman-
da alto poder computacional es necesario desarrollar arquitecturas de proposito
especıfico que se ajusten a esta aplicacion en particular para disminuir los tiem-
pos de procesamiento.
El principal problema en la recuperacion 3D es el numero de operaciones que
se tienen que realizar y el numero de accesos a memoria. En este trabajo de tesis se
propone una arquitectura hardware de un procesador paralelo para la recuperacion
3D haciendo uso de los Arreglos Logicos Programables (FPGAs). Las principales
caracterısticas del procesador son la maxima reutilizacion de datos, un consumo
de recursos moderado y la precision con que se logra recuperar la 3D. Ademas,
el computo de la recuperacion 3D se hace en tiempo predecible. Se considera que
un sistema opera en tiempo predecible cuando realiza el procesamiento en una
restriccion de tiempo establecida, en este caso 5 cuadros por segundo.
La obtencion de la recuperacion 3D en este trabajo es a traves del calculo del
Flujo Optico en secuencias de imagenes con resolucion VGA.
II
Abstract.
III
Abstract.
Abstract.
In recent years, 3D recovery from motion has received a major effort in com-
puter vision systems. Since the motion estimation is computationally intensive,
specific architectures adecuated to this particular application to decrease the pro-
cessing time are needed.
The main problem lies in the number of operations and memory accesses that
have to be performed by the majority of the existing techniques when translated
to hardware or software implementations. This work proposes a hardware archi-
tecture for a parallel processor for 3D recover using a field-programmable gate
array (FPGA). The main features of the processor are the maximum reuse of data,
a small size, along with the precision with which 3D recovery is achieved. Also,
computing of 3D recovery is performance in predictable time. In this case, 5 fra-
mes per second.
The 3D recovery is calculated from the optical flow estimation in image se-
quences with VGA resolution.
IV
Abstract.
V
Abstract.
Agradecimientos.
A mis padres Hilaria y Hugo, ası como a mis hermanos Alberto, Fabiola y
Tere. A mis sobrinos por todas las alegrıas en mis visitas a casa.
A mi novia Erendira por tu apoyo y todo el amor que me has dado. A mis
companeros de generacion en especial a Atlantida, Carolina, Fernando y Roberto
por convivir conmigo durante dos anos.
A la familia Gutierrez Meza por su apoyo y amistad.
A mi asesor Dr. Miguel Arias, por los consejos y ensenanzas pero sobre todo
por el apoyo en todo momento.
A mi comite revisor, Dra. Pilar Gomez, Dr. Rene Cumplido, Dr. Leopoldo Al-
tamirano por el tiempo y los consejos otorgados a este trabajo.
A mis companeros del laboratorio de FPGA’s, Marco, Juan Carlos y Liz, por
sus consejos y platicas.
Al Consejo Nacional de Ciencia y Tecnologıa (CONACyT) por el apoyo economi-
co brindado a lo largo de mis estudios de maestrıa. Al Instituto Nacional de As-
trofısica, Optica y Electronica por la formacion academica y todos los recursos
brindados.
VI
Abstract.
VII
Abstract.
Dedicatoria.
A mi madre por ensenarme que todo se puede con trabajo y esfuerzo.
A mi novia Ery por iluminar mi vida y por ser un ejemplo de bondad y lucha.
VIII
Abstract.
Indice general
1. Introduccion 1
1.1. Motivacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Metodologıa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Organizacion de la Tesis. . . . . . . . . . . . . . . . . . . . . . . 6
2. Antecedentes. 7
2.1. Flujo Optico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Algoritmos basados en gradiente. . . . . . . . . . . . . . 8
2.1.2. Algoritmos basados en correlacion. . . . . . . . . . . . . 10
2.1.3. Limitantes del Flujo Optico. . . . . . . . . . . . . . . . . 11
2.1.4. Seleccion del algoritmo. . . . . . . . . . . . . . . . . . . 14
2.1.5. Medidas de Correlacion. . . . . . . . . . . . . . . . . . . 17
2.2. Recuperacion 3D a partir del movimiento. . . . . . . . . . . . . . 19
2.2.1. Estimacion de la profundidad a partir del movimiento en
la escena. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2. Recuperacion 3D a partir del Flujo Optico. . . . . . . . . 22
2.3. Trabajos previos. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. Arquitectura propuesta. 32
3.1. Especificaciones de la arquitectura propuesta. . . . . . . . . . . . 33
3.2. Descripcion de la arquitectura propuesta. . . . . . . . . . . . . . . 34
3.3. Modulos funcionales de la arquitectura propuesta. . . . . . . . . . 36
3.3.1. Modulo calculo de Flujo Optico. . . . . . . . . . . . . . . 37
3.3.2. Modulo calculo de profundidad. . . . . . . . . . . . . . . 48
IX
X
3.3.3. Modulos Ruteadores. . . . . . . . . . . . . . . . . . . . . 54
3.3.4. Modulo Control. . . . . . . . . . . . . . . . . . . . . . . 60
3.4. Arquitectura Final. . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5. Rendimiento de la arquitectura propuesta. . . . . . . . . . . . . . 65
3.6. Escalabilidad y Reconfigurabilidad. . . . . . . . . . . . . . . . . 67
3.6.1. Escalabilidad. . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.2. Reconfigurabilidad. . . . . . . . . . . . . . . . . . . . . . 72
4. Implementacion y resultados. 73
4.1. Implementacion. . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.1. Software utilizado. . . . . . . . . . . . . . . . . . . . . . 74
4.1.2. Hardware utilizado . . . . . . . . . . . . . . . . . . . . . 75
4.2. Metodologıa de prueba. . . . . . . . . . . . . . . . . . . . . . . . 76
4.3. Resultados de las pruebas en el dispositivo. . . . . . . . . . . . . 78
4.3.1. Resultados para el Flujo Optico. . . . . . . . . . . . . . . 79
4.3.2. Resultados para la recuperacion 3D. . . . . . . . . . . . . 85
4.3.3. Implementacion, resultados y sıntesis. . . . . . . . . . . . 95
4.4. Analisis de resultados. . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.1. Analisis de resultados software/hardware. . . . . . . . . . 96
4.5. Rendimiento de la arquitectura. . . . . . . . . . . . . . . . . . . . 101
4.6. Discusion de resultados. . . . . . . . . . . . . . . . . . . . . . . 102
5. Conclusiones y trabajo futuro. 104
5.1. Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2. Trabajo futuro. . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
A. Hoja de Datos de la Arquitectura. 108
Indice de figuras 113
Indice de tablas 118
Bibliografıa 119
Capıtulo 1
Introduccion
La recuperacion 3D de un conjunto de imagenes es uno de los principales
esfuerzos en vision computacional. A diferencia de una imagen estatica, la infor-
macion contenida en una secuencia de imagenes es importante porque permite
conocer el movimiento y la estructura de los objetos en la escena.
El presente capıtulo esta divido en cuatro secciones. En la primera se presentan
los problemas en la recuperacion 3D. El objetivo de la tesis y sus alcances son
propuestos en la segunda seccion. La tercera seccion describe la metodologıa de
la solucion propuesta. Finalmente, la cuarta seccion presenta la organizacion de la
tesis.
1
2
1.1. Motivacion.
En la actualidad, el desarrollo de aplicaciones industriales, medicas o militares
requiere de procesar de manera rapida y eficiente la informacion captada por las
camaras digitales. Dicho procesamiento resulta imposible de realizar en modelos
software debido a su alto tiempo de procesamiento, por lo que se ha optado por
modelos hardware, en los cuales el tiempo de procesamiento se puede reducir.
La recuperacion 3D tiene como finalidad reconstruir un modelo en tercera
dimension de un objeto a partir de datos observados. La implementacion de un
algoritmo para recuperar la 3D depende considerablemente de la aplicacion que
se desee desarrollar. Las principales tecnicas para la recuperacion 3D se basan en
vision estereo, sombreado y estimacion de movimiento.
La busqueda de precision en la recuperacion 3D lleva a implementar algorit-
mos mas complejos y computacionalmente costosos [1]. Los algoritmos estereo
realizan la calibracion de una o mas camaras para despues triangular los puntos
de la escena y calcular la recuperacion 3D [2]. Diferentes metodos tratan de re-
cuperar la 3D a partir del movimiento e intensidad de las imagenes. Los metodos
basados en correspondencia de caracterısticas buscan hacer empatamientos entre
caracterısticas de varias imagenes. Despues, estos metodos estiman el movimien-
to en la secuencia de imagenes y luego aplican triangulacion como los metodos
estereo para recuperar la 3D [2]. Los metodos basados en correspondencia tra-
bajan correctamente, pero obtienen la profundidad unicamente donde exista una
correspondencia entre las caracterısticas, lo cual provoca recuperar superficies
dispersas. Algunos metodos proponen realizar una estimacion de la profundidad
utilizando operaciones que manipulen los cambios de intensidad en la imagen e
integrando la informacion dentro de un filtro Kalman [3]. La problematica de los
metodos basados en correspondencia e intensidad es que ni las caracterısticas y
ni la intensidad son constantes o continuas en las imagenes, suposiciones hechas
en la mayorıa de los algoritmo de calculo de movimiento, restando confiabilidad
a los resultados.
3
Tambien hay metodos que calculan la profundidad a partir de objetos conoci-
dos en la escena. Otros metodos estiman la profundidad de una escena con solo
calcular el componente normal al Flujo Optico [6]. Para un correcto funciona-
miento del ultimo metodo es necesario conocer la trayectoria seguida entre la
camara y el escenario [3]. La mayorıa de los algoritmos descritos imponen res-
tricciones como el conocimiento del movimiento de la camara, su posicion con
respecto al escenario o de tecnicas de calibracion.
En el caso de los enfoques basados en Flujo Optico, se puede hacer la recu-
peracion 3D mediante una camara sin necesidad de conocer los parametros de la
misma, no se necesita alineacion de multiples camaras, conocimientos previos de
la escena o del movimiento, solo se requiere que el movimiento de la camara y la
escena sea relativamente pequeno.
En la recuperacion 3D a partir del Flujo Optico se tiene una carga computacio-
nal exhaustiva. Por ejemplo, para la recuperacion 3D se realizan aproximadamente
6 mil millones de operaciones aritmeticas con 1,500 millones de accesos a memo-
ria por segundo, con imagenes en escala de grises de 256 tonos y resolucion de
640 × 480 pixeles [12] [17]. Un procesador secuencial resulta insuficiente para
realizar esta tarea en un tiempo corto. Por tal motivo, se ha optado por el desa-
rrollo de arquitecturas de proposito especıfico, como un procesador paralelo, que
se ajusten a esta aplicacion. Las arquitecturas de proposito especıfico tienen la
caracterıstica que hacen una maxima reutilizacion de datos y ası minimizan los
accesos a memoria. Ademas, las arquitecturas de este tipo realizan el calculo de
varias operaciones en paralelo con lo cual el tiempo de procesamiento es menor.
Por lo tanto, las arquitecturas de proposito especıfico resultan adecuadas para este
tipo de aplicaciones.
1.2. Objetivo.
El objetivo general de este trabajo es disenar un procesador paralelo para el
calculo de la recuperacion 3D a partir del Flujo Optico. La recuperacion 3D se
realiza bajo la condicion de un ambiente estatico. Esto significa que ningun objeto
4
se mueve en el ambiente. Los movimientos dentro de la secuencia de video de-
ben de ser pequenos, maximo de dos pixeles por imagen. Ademas, el procesador
cumplira con las restricciones de que sea capaz de operar en tiempo predecible, 5
cuadros por segundo (fps), para imagenes con resolucion VGA (Video Graphics
Array), 640 × 480 pixeles, en escala de grises de 256 tonos.
Como objetivos particulares se tienen: la seleccion de un algoritmo base y
modificarlo para la recuperacion 3D; el analisis del grado de paralelismo del algo-
ritmo seleccionado para la arquitectura del procesador; la implementacion de la ar-
quitectura del procesador propuesta en una plataforma FPGA (Field-Programmable
Gate Array) para la validacion. Por ultimo, analizar la escalabilidad de la arqui-
tectura para procesar 30 fps en dispositivos FPGAs de mayor capacidad.
1.3. Metodologıa.
La metodologıa seguida para el desarrollo del presente trabajo se muestra en
la figura 1.1.
El primer paso es la busqueda de algoritmos para el calculo de Flujo Optico
(FO). Despues, se hizo la seleccion del algoritmo para el calculo del Flujo Optico.
En la seleccion del algoritmo se consideraron caracterısticas como desempeno,
simplicidad de aplicacion y robustez. Por lo anterior, se analizaron algoritmos
cuyas operaciones no fueran demasiado complejas en hardware y se identifico el
posible paralelismo del algoritmo. Una vez seleccionado el algoritmo, se realizo la
implementacion software, siguiendo con la etapa de pruebas y el analisis de los re-
sultados obtenidos. En seguida de la implementacion software del calculo de Flujo
Optico, se hizo la implementacion software para el calculo de la recuperacion 3D.
Posteriormente, se llevo acabo la fase de pruebas y analisis de los resultados de la
implementacion.
Paralelamente con la implementacion software para el calculo de la recupera-
cion 3D, se definio el esquema de la arquitectura y sus modulos funcionales. Para
la codificacion del diseno se uso un lenguaje de descripcion de hardware como
5
Figura 1.1: Metodologıa de desarrollo.
VHDL (Very-High-Speed Integrated Circuits hardware description language) o
Handel-C. En seguida, se realizo el diseno y codificacion hardware del modulo
para el calculo del Flujo Optico. A continuacion, se realizaron las pruebas del
modulo y un analisis de los resultados obtenidos. Para el analisis se hizo la com-
paracion de los resultados obtenidos por el modulo en las implementaciones soft-
ware y hardware.
6
Una vez validado el diseno en software para la recuperacion 3D a partir del
Flujo Optico, se definio el esquema y se diseno el modulo para la recuperacion
3D en la implementacion hardware. Posteriormente, se hizo la codificacion del
modulo en el lenguaje de descripcion de hardware seleccionado.
Despues, se realizo la integracion de los modulos del Flujo Optico y la recu-
peracion 3D en una sola arquitectura. Se hizo la etapa de pruebas y depuracion
de la arquitectura mediante una plataforma FPGA. Las pruebas se hicieron en dos
etapas. En la primera etapa, las pruebas se realizaron con secuencias de imagenes
sinteticas. En la segunda etapa, las pruebas se realizaron con secuencias de image-
nes reales.
En seguida, se analizaron los resultados obtenidos de la implementacion en
hardware comparandolos con los resultados de la implementacion software. Ade-
mas, en este paso se realizo un analisis cuantitativo de los resultados obtenidos
por la arquitectura propuesta. Para el analisis se usaron metricas como tiempo de
procesamiento, numero de pixeles procesados por unidad de tiempo y el error en
los calculos. Por ultimo, se realizaron las conclusiones del presente trabajo de te-
sis.
Con la metodologıa propuesta se logro alcanzar el objetivo general y los obje-
tivos particulares presentados en la pasada seccion.
1.4. Organizacion de la Tesis.
El presente trabajo de tesis esta dividido de la siguiente manera. En el capıtulo
2 se muestran las bases teoricas para el desarrollo de la investigacion, tambien
se incluye un analisis de trabajos relacionados en el area. La descripcion de los
modulos de la arquitectura, funcionamiento e interaccion se explica en el capıtu-
lo 3. En el capıtulo 4 se muestra el rendimiento y el analisis de los resultados
proporcionados por la arquitectura. Por ultimo, en el capıtulo 5 se presentan las
conclusiones y el trabajo futuro de la tesis.
Capıtulo 2
Antecedentes.
En los ultimos anos la recuperacion 3D ha sido uno de los principales esfuer-
zos en los sistemas de vision computacional. Existen diferentes metodos para la
recuperacion 3D. Estos varıan segun la aplicacion que se quiera desarrollar y pre-
sentan diferentes caracterısticas. En este trabajo de tesis nos enfocaremos a los
metodos que utilizan estimacion de movimiento para la recuperacion 3D.
El presente capıtulo esta dividido en tres secciones. En la primera se revisan las
tecnicas para la estimacion de movimiento, caracterısticas, ventajas y desventajas.
En esta seccion tambien se revisan las limitaciones presentes en el calculo del
Flujo Optico. En la segunda seccion se plantean las ecuaciones necesarias para
la recuperacion 3D a partir del Flujo Optico. En la ultima seccion se mencionan
algunos trabajos relacionados con la presente tesis.
7
8
2.1. Flujo Optico.
El Flujo Optico es un campo de vectores que asocia el movimiento en la es-
cena con los cambios en los patrones de intensidad [4]. El movimiento puede ser
causado por los objetos en la escena o por la camara.
La aplicacion del Flujo Optico incluye el problema de inferir no solo el mo-
vimiento del observador y objetos en la escena, sino tambien la estructura de los
objetos y el ambiente, lo cual es un componente crıtico en el sistema de vision
humana. La conversion de esta habilidad innata a una capacidad computacional es
crucial en el campo de vision computacional.
Los algoritmos de Flujo Optico estiman el movimiento entre dos o mas image-
nes de una secuencia de video. La suposicion basica para el calculo del Flujo
Optico es la conservacion de la intensidad de los pixeles en las imagenes de la
secuencia de video. Esto asume que la intensidad o color de los objetos no cambia
significativamente entre imagenes consecutivas de la secuencia video. Basandose
en esta idea, se puede derivar una ecuacion que puede describir el movimiento a
traves de la secuencia.
Existen diferentes algoritmos para el calculo del Flujo Optico. En los siguien-
tes dos apartados se describiran los algoritmos basados en gradiente y los algorit-
mos basados en correlacion.
2.1.1. Algoritmos basados en gradiente.
Los algoritmos basados en gradientes calculan el Flujo Optico con derivadas
espacio-temporales de la intensidad de los pixeles de las imagenes o mediante
versiones filtradas de la imagen (usando filtros pasa bajas o pasa bandas) [9]. El
metodo trata de calcular el movimiento entre dos o mas cuadros de la secuencia de
video. Las imagenes de la secuencia fueron tomadas en un tiempo t y t + δt para
cada posicion de pixel. Un pixel localizado en (x, y, t) con intensidad I(x, y, t) se
puede mover δx, δy y δt entre dos imagenes de la secuencia de video [5], esto es:
9
I(x, y, t) = I(x + δx, y + δy, t + δt) (2.1)
Suponiendo que el movimiento es lo suficientemente pequeno, la ecuacion
( 2.1) se puede desarrollar mediante series de Taylor y se obtiene:
I(x + δx, y + δy, t + δt) = I(x, y, t) +∂I
∂xδx +
∂I
∂yδy +
∂I
∂tδt (2.2)
Combinando las ecuaciones 2.1 y 2.2 resulta la siguiente ecuacion:
∂I
∂xδx +
∂I
∂yδy +
∂I
∂tδt = 0 (2.3)
Se divide la ecuacion 2.3 por δt:
∂I
∂x
δx
δt+
∂I
∂y
δy
δt+
∂I
∂t
δt
δt= 0 (2.4)
o∂I
∂xu +
∂I
∂yv +
∂I
∂t= 0 (2.5)
donde u y v son los componentes de la velocidad de x y y o Flujo Optico
de I(x, y). En tanto ∂I∂x
,∂I∂y
y ∂I∂t
son las derivadas de la imagen en (x, y, t) en las
correspondientes direcciones Ix, Iy y It. Por lo tanto, la ecuacion 2.4 puede ser
escrita como:
Ixu + Iyv = −It (2.6)
o
∇I · −→V = −It (2.7)
Como se observa, la ecuacion 2.7 posee dos incognitas y no puede ser resuelta
con solucion unica. Esto se conoce como el problema de apertura en los algorit-
mos de Flujo Optico y corresponde solo a recuperar la componente normal del
vector de movimiento. Para encontrar el Flujo Optico es necesario otro conjunto
de ecuaciones o proporcionar algunas condiciones adicionales. En el mejor de los
10
casos solo se puede determinar la velocidad normal dada por:
Vn =−It√I2x + I2
y
(2.8)
Debido a que la ecuacion no puede ser resuelta unicamente usando la informa-
cion del pixel de la imagen, se propone usar la informacion de los pixeles vecinos,
este enfoque es usado por ciertos algoritmos [9]. Otros algoritmos proponen utili-
zar derivadas de segundo orden para la estimacion de movimiento.
2.1.2. Algoritmos basados en correlacion.
La exactitud numerica de los algoritmos basados en gradiente puede ser afec-
tada por el ruido, para un numero pequeno de imagenes en la secuencia de video,
o por el fenomeno de aliasing en el proceso de adquisicion de las imagenes. El
fenomeno de aliasing en imagenes es comunmente visto como los rizos, escalones
o dientes de sierra de baja frecuencia causados por los componentes de alta fre-
cuencia en los bordes de un polıgono [10]. En estos casos los algoritmos basados
en gradiente pueden ser inapropiados y por ello se utilizan los algoritmos basados
en correlacion [11].
Los algoritmos basados en correlacion suponen que se conserva la distribu-
cion que rodea al punto donde se desea evaluar el movimiento [12]. El proposito
de estos algoritmos es encontrar la mejor correspondencia de un bloque de una
imagen i, llamada ventana de referencia, en un bloque de otra imagen j, llamada
ventana de busqueda, donde la ventana de busqueda puede aparecer antes o des-
pues de la imagen i. La figura 2.1 muestra un esquema de los algoritmos basados
en correlacion.
La posicion idonea de la ventana de referencia sobre la ventana de busqueda se
localiza maximizando o minimizando la medida de correspondencia. Generalmen-
te la medida de correspondencia es una correlacion entre la ventana de referencia
y la de busqueda.
11
Figura 2.1: Esquema del algoritmo basado en correlacion [12].
2.1.3. Limitantes del Flujo Optico.
El Flujo Optico es un problema mal planteado al tener como solucion una
ecuacion con dos incognitas. Esto ocasiona algunas limitantes en el calculo del
Flujo Optico. A continuacion se muestran algunas de las limitantes.
Problema de apertura. El problema de apertura es la dificultad de recuperar
de manera correcta la direccion del movimiento [5]. Partiendo de la ecuacion 2.6
la solucion al Flujo Optico basado en gradiente es una ecuacion con dos incognitas
y por tanto existen infinitas soluciones para u y v. Expresando (u, v) en funcion
de (Ix, Iy) y (Iy,−Ix), dos vectores perpendiculares, se obtiene:
(u, v) = − It
I2x + I2
y
(Ix, Iy) + λ(Iy,−Ix) (2.9)
Lo que significa que se puede determinar la componente de (u, v) en la direc-
cion del gradiente espacial (Ix, Iy) pero no en su direccion perpendicular [14].
Graficamente el problema de apertura se puede entender como si se observara
12
un objeto a traves de una apertura que es mas pequena que el tamano del objeto,
esto provoca que no se aprecie de manera adecuada el movimiento que el objeto
realice y por tal motivo no poder calcular de forma correcta la direccion de la
velocidad. En la figura 2.2 se muestra el esquema del problema de apertura.
Figura 2.2: Problema de apertura. En la secuencia de imagenes se observa el pro-blema de calcular de manera correcta la direccion de la velocidad de la barra.
En el ejemplo de la figura 2.2 se tiene una secuencia de 3 imagenes. En el ins-
tante t se muestra una barra que se ve a traves de un orificio que es mas pequeno
que el tamano del objeto. En el instante t + 1 la barra se desplaza en su propio
eje en direccion vertical, pero desde la perspectiva del orificio parece que no hubo
movimiento. En el instante t + 2 la barra se desplaza en la direccion normal a
su eje. Este movimiento es visible a traves de la apertura y por tanto su calculo
correcto. Por lo anterior, es imposible calcular el desplazamiento en la secuencia
en los instantes t y t + 1 si se observa por un orificio mas pequeno que la barra.
De manera mas general, no es posible calcular la direccion de la velocidad ob-
servando una pequena vecindad de un punto que esta en movimiento. La unica
informacion obtenible a partir de las vecindades del punto es la componente de la
velocidad normal al borde [15].
Problema de oclusion. El termino oclusion se refiere a tapar/destapar una su-
perficie debido a la rotacion 3D y a la traslacion de un objeto que ocupa solo parte
del campo de vision.
En la figura 2.3 se muestra una secuencia de imagenes que presenta el proble-
ma de oclusion. En el instante t se observa un solo objeto en el campo de vision.
En el instante t + 1 el objeto presenta un movimiento de traslacion y se descubre
13
una region que estaba oculta en las imagenes previas. La region descubierta en la
imagen t + 1 no encontrara alguna correlacion con ninguna region de la imagen t,
provocando una estimacion incorrecta del movimiento.
Figura 2.3: Problema de oclusion. En la secuencia se descubre una region en elinstante t + 1, ninguna otra region en el instante t correspondera con la nuevaregion.
Movimiento de iluminacion. En este caso se calcula un Flujo Optico gene-
rado por el cambio en la posicion de la fuente de iluminacion y no por el movi-
miento del objeto. En la figura 2.4 se muestra un ejemplo de este problema. En el
ejemplo, los cambios de intensidad de los pixeles en las imagenes se genera por
el cambio de la posicion de la iluminacion externa y no por el movimiento del
objeto. Por lo tanto, al aplicar el algoritmo de Flujo Optico en la secuencia, este
proporcionara un calculo incorrecto debido a que el movimiento encontrado no es
del objeto.
Figura 2.4: Movimiento de la fuente de iluminacion externa ante un objeto sinmovimiento [14].
Objetos sin textura. Una restriccion para el calculo del Flujo Optico es que
las estructuras capturadas en la secuencia de imagenes deben tener textura [3].
Esto implica que tiene que haber suficiente variacion en el nivel de gris de la
14
region que se mueve para que su movimiento se detecte. Al carecer de textura un
objeto, no habra variacion en la region que se mueve y por tanto se obtendra un
Flujo Optico igual a cero. En la figura 2.5 se muestra el movimiento presentado
por un objeto sin textura.
Figura 2.5: Movimiento de un objeto sin textura provoca un Flujo Optico igual acero [14].
Ambiguedad en la solucion. El problema del calculo del Flujo Optico es
un problema mal definido, por lo que existen multiples opciones de resolverlo
o al menos acotarlo. La ambiguedad en la solucion se puede presentar cuando
al capturarse una secuencia el desplazamiento entre los objetos de las imagenes
es muy grande, el movimiento es mas grande que el tamano de la ventana de
busqueda, o porque existe un gran numero de puntos similares que confunden al
algoritmo [3] [11].
Figura 2.6: Falsas correspondencias debido a la semejanza entre regiones .
2.1.4. Seleccion del algoritmo.
En la literatura existen diversos trabajos comparativos entre algoritmos de Flu-
jo Optico de diferentes tipos. En [11], [40] y [13] se presentan diferentes analisis
15
comparativos del rendimiento de los algoritmos basados en correlacion, gradiente
y energıa para el calculo del Flujo Optico. En estos trabajos se obtienen que los
algoritmos basados en correlacion presentan resultados satisfactorios en compara-
cion con los algoritmos basados en gradiente. Ademas, los analisis de rendimiento
presentes en los trabajos muestran que la complejidad de las operaciones en los
algoritmos basados en correlacion es menor que la de los algoritmos basados en
energıa. Los algoritmos basados en energıa presentan una complejidad muy alta
de implementacion, al operar en el dominio de la frecuencia. La implementacion
hardware de estos algoritmos consume demasiados recursos y su implementacion
es poco viable.
En la literatura hay diversas implementaciones hardware de diferentes algo-
ritmos de Flujo Optico [11] [12] [16] [26]. Cada uno de estos trabajos analiza y
evalua el rendimiento y la complejidad de los diferentes algoritmos para el calculo
del Flujo Optico. En la seleccion del algoritmo para el calculo del Flujo Optico
es necesario e importante considerar la complejidad de las operaciones, el nume-
ro de accesos a memoria, el grado de paralelismo del algoritmo y la continuidad
en el flujo de los datos. Lo anterior tiene como proposito lograr una maxima re-
utilizacion de datos y el procesamiento de la secuencia de imagenes en tiempo
predecible. Se considera que un sistema opera en tiempo predecible cuando reali-
za el procesamiento en una restriccion de tiempo establecida.
Los algoritmos basados en correlacion presentan un alto grado de paralelismo
y gran reutilizacion de datos. Estas caracterısticas son debido a que presentan un
flujo regular en el manejo de la informacion. Ademas, las operaciones que utilizan
no son muy complejas con respecto a otros metodos como los metodos basados en
gradiente y energıa. En [17] se muestran estudios del desempeno y complejidad
de implementacion hardware de los algoritmos basados en correlacion.
El tipo algoritmo seleccionado para la implementacion hardware para el calcu-
lo del Flujo Optico fue el basado en correlacion. Esta seleccion se debio a los bue-
nos resultados mostrados en los trabajos de analisis de rendimiento ( [11], [12] y
[40]) y a la baja complejidad para su implementacion hardware ( [12] y [17]).
16
Los algoritmos de correlacion funcionan en base al manejo de ventanas, cono-
cidas comunmente como ventanas de referencia y de busqueda. De la secuencia
de video, se toman dos cuadros (imagenes) consecutivos, los cuadros selecciona-
dos se dividen en bloques de igual tamano en forma periodica los cuales pueden
traslaparse pero conservando el mismo tamano [17].
El cuadro previo, Ig−1, es divido en ventanas de tamano de 8 × 8 o 16 × 16
pixeles, estas divisiones formaran las ventanas de busqueda. El cuadro actual, Ig,
se divide en ventanas mas pequenas que las de busqueda, generalmente de 4× 4 u
8× 8 pixeles, llamadas ventanas de referencia. La ventana de referencia se coloca
dentro de la de busqueda en todas las posibles posiciones. Para cada posicion de
la ventana de referencia sobre la de busqueda se calcula la correlacion, siendo esta
posicion de la ventana de referencia un posible candidato a vector de movimiento.
Posteriormente que se calcularon las correlaciones en todas las posiciones de la
ventana de referencia sobre la de busqueda, se toma aquella que dio el mayor o
menor valor dependiendo de la medida que se este usando. En la figura 2.7 se
muestra el funcionamiento base de los algoritmos de correlacion.
Figura 2.7: Funcionamiento base de los algoritmos basados en correlacion [17].
17
2.1.5. Medidas de Correlacion.
Una vez que se ha seleccionado el tipo de algoritmo basado en correlacion,
se analizaran algunas de las medidas de correlacion que existen en la literatura y
su factibilidad de uso en FPGAs. A continuacion se describen algunas de las mas
frecuentemente utilizadas.
Suma de Diferencias Absolutas (Sum of Absolute Differences - SAD) [17].
SAD(dx, dy) =x+N−1∑
m=x
y+N−1∑n=y
|Ig(m,n) − Ig−1(m + dx, n + dy)| (2.10)
donde N es el tamano de la ventana de referencia, x e y son la posicion de la
ventana de referencia, dx y dy es el desplazamiento de la ventana de referencia
entre imagenes de la secuencia, m y n son los ındices de los pixeles, Ig(m,n) es
el valor de intensidad del pixel en la imagen actual e Ig−1(m + dx, n + dy) es el
valor en la imagen previa.
La SAD es una de las medidas de correlacion mas simples que se encuen-
tran en la literatura. Su principal caracterıstica es su facil implementacion y poco
consumo de recursos en hardware. La implementacion hardware del SAD solo ne-
cesita operaciones de suma, comunmente disponible en los FPGAs actuales [19],
y calculo de valor absoluto. Por lo que su implementacion hardware resulta viable
en dispositivos FPGAs de pequena escala.
Suma de Diferencias al Cuadrado (Sum of Squared Differences - SSD)
SSD(dx, dy) =x+N−1∑
m=x
y+N−1∑n=y
(Ig(m,n) − Ig−1(m + dx, n + dy))2 (2.11)
donde x, y, dx, dy, m, n, Ig(m,n) e Ig−1(m + dx, n + dy) se definieron en la
ecuacion anterior.
18
La principal ventaja de la medida de correlacion SSD consiste en su confiabili-
dad, que se cataloga aceptable. Una desventaja es que proporciona algunas falsos
empatamientos entre la ventana de busqueda y de referencia debido al ruido [20].
La implementacion hardware para la SSD resulta mas complicada debido a que su
modulo base esta formado por un bloque sumador y un bloque multiplicador. Los
bloques multiplicadores, a pesar de que ya son un elemento comun en los dispo-
sitivos FPGAs [19], aun se tienen disponibles de manera reducida y por tanto el
uso de esta medida de correlacion se ve restringida a los dispositivos FPGAs de
gran escala.
Correlacion Cruzada Normalizada (Normalized Cross-Correlation - NCC)) [17]
NCC(dx, dy) =x+N−1∑
m=x
y+N−1∑n=y
Ig(m,n)Ig−1(m + dx, n + dy)√Ig(m,n)2
√Ig−1(m + dx, n + dy)2
(2.12)
donde x, y, dx, dy, m, n, Ig(m,n) e Ig−1(m + dx, n + dy) se definieron en la
ecuacion 2.10.
La ultima medida de correlacion es una de las mas confiables encontradas en
la literatura [20]. Una de sus principales desventajas consiste en que su imple-
mentacion hardware consume muchos recursos debido a que tiene operaciones
de division, multiplicacion y obtencion de raıces. Las operaciones de division y
raız cuadrada se hacen regularmente de manera iterativa para hacer un consumo
no excesivo de recursos. Por tanto su implementacion hardware se ve acotada a
FPGAs de gran escala o en aplicaciones donde el tiempo de procesamiento no sea
un factor critico.
Por lo anterior, la medida de correlacion que se utilizara para esta tesis es la
de Suma de Diferencias Absolutas (SAD). Esta seleccion se hace debido a su sim-
plicidad y al consumo moderado de recursos para la implementacion hardware de
sus operaciones, que incluye un bloque sumador y un bloque de valor absoluto.
Ademas, esta medida de correlacion ha reportado buenos resultados en diferentes
implementaciones hardware [12] [16][17].
19
Una vez calculada la medida de correlacion para todas las ventanas de refe-
rencia, el vector de movimiento se obtiene mediante la siguiente ecuacion [17]:
MV = (MVx,MVy) = min(dx,dy)εR2SAD(dx, dy) (2.13)
2.2. Recuperacion 3D a partir del movimiento.
El objetivo de la recuperacion 3D es obtener una representacion de la informa-
cion de profundidad a partir del movimiento extraıdo de una secuencia de image-
nes. La implementacion de algun algoritmo para recuperar la 3D depende de la
aplicacion que se quiera desarrollar. Las principales tecnicas se basan en vision
estereo, sombreado y estimacion de movimiento o shape from motion.
La estimacion del movimiento y de la profundidad son de gran utilidad para
un robot movil en tareas tales como navegacion, guiado, evitacion de obstaculos,
formacion de mapas, etc. Si bien estas tareas pueden ser llevadas a cabo por otro
tipo de sensores usualmente activos (infrarrojos, ultrasonidos, laser, etc..), la utili-
zacion de tecnicas de vision artificial resulta atractiva por la posibilidad de realizar
un barrido electronico de una amplia zona del entorno, mucho mas rapido, preci-
so y economico que el barrido mecanico que precisan efectuar los otros sensores.
Las tecnicas de vision artificial tambien proveen resultados con una resolucion y
precision potencialmente muy alta. Por otra parte, estas tecnicas presentan dificul-
tades tanto teoricas como computacionales, ası como limitantes en peso, tamano
y consumo de potencia.
2.2.1. Estimacion de la profundidad a partir del movimiento
en la escena.
En esta seccion se revisaran las ecuaciones que describen la relacion entre la
estimacion de profundidad y el Flujo Optico generado por el movimiento de la
20
camara. Se utilizara la misma notacion que en [22]. Ademas, se asume que el
movimiento de la camara es a traves de un medio estatico. El sistema coordenado
de referencia se muestra en la figura 2.8.
Figura 2.8: Sistema coordenado de referencia.
Se tiene el sistema coordenado X , Y , Z fijo con respecto a la camara. El eje Z
esta ubicado a lo largo del eje optico de la camara. Cualquier movimiento puede
ser descrito por medio de dos factores, uno de traslacion y uno de rotacion con
respecto a la camara. Se denota por �T el componente traslacional de la camara y
�ω como la velocidad angular. Por ultimo, las coordenadas instantaneas del punto
P en el ambiente son (X,Y, Z) [22].
La velocidad de un punto P con respecto al sistema coordenado X , Y , Z
esta dada por:
�V = −�T − �ω × �r (2.14)
se definen �T , �ω y �r como:
�T = (U, V,W )T �ω = (A,B,C)T �r = (X,Y, Z)T (2.15)
donde (U, V,W ) representa los componentes de traslacion de la camara y
(A,B,C) representa los componentes de la velocidad angular.
21
sustituyendo los valores de �T , �ω y �r en (2.14) se tiene:
�V = −
⎛⎜⎜⎝
U
V
W
⎞⎟⎟⎠ −
⎛⎜⎜⎝
A
B
C
⎞⎟⎟⎠ ×
⎛⎜⎜⎝
X
Y
Z
⎞⎟⎟⎠ (2.16)
realizando las operaciones matriciales se obtiene:
�V = −
⎛⎜⎜⎝
−U − BZ + CY
−V − CX + AZ
−W − AY + BX
⎞⎟⎟⎠ (2.17)
sustituyendo �V por (X′, Y
′, Z
′) se puede reescribir la ecuacion 2.17 como:
X′= −U − BZ + CY
Y′= −V − CX + AZ
Z′= −W − AY + BX
(2.18)
El vector (X′, Y
′, Z
′)T es la derivada de la posicion del punto P con respecto
al tiempo, es decir, la velocidad 3D. Con la ecuacion 2.18 se tiene la velocidad
instantanea de cada punto con respecto a las coordenadas de la camara.
Aunque se derivo una ecuacion para la velocidad 3D de cada punto en la esce-
na producida por el movimiento de la camara, se desconocen aun los componentes
de traslacion y rotacion. Ademas, se desconoce tambien la posicion en el espacio
3D de cada punto. Una forma de reducir el numero de incognitas es a traves de la
proyeccion de la velocidad 3D en el plano 2D. Para esto, se hace una estimacion
del Flujo Optico 2D proyectado por el movimiento 3D de la camara [3].
Se puede definir (x, y) como las coordenadas del punto p en la imagen plana
(ver figura 2.8). Es posible definir una proyeccion entre el punto P en el espacio y
su correspondiente punto p en la imagen. La relacion esta dada por [9]:
x = XZ
y = YZ
(2.19)
El Flujo Optico esperado, (uesp, vesp), en el punto (x, y) se define como:
22
uesp = x′ vesp = y′ (2.20)
Diferenciando la ecuacion 2.19 con respecto al tiempo y sustituyendo en la
ecuacion 2.20 se obtiene la siguiente ecuacion para el Flujo Optico esperado:
uesp = X′Z
− XZ′Z2 =
(−UZ− B + Cy
) − x(−W
Z+ Ay + Bx
)vesp = Y ′
Z− Y Z′
Z2 =(−V
Z− Cx + A
) − y(−W
Z+ Ay + Bx
) (2.21)
agrupando terminos se escribe la ecuacion 2.21 de la siguiente forma:
uesp = −U+xWZ
+ Axy − B(x2 + 1) + Cy
vesp = −V +yWZ
+ A(y2 + 1) − Bxy − Cx(2.22)
la ecuacion anterior se puede escribir como:
uesp = ut + ur vesp = vt + vr (2.23)
donde (ut, vt) denota los componentes de traslacion del Flujo Optico esperado
y (ur, vr) el componente de rotacion:
ut = −U+xWZ
ur = Axy − B(x2 + 1) + Cy
vt = −V +yWZ
vr = A(y2 + 1) − Bxy − Cx(2.24)
Las ecuacion 2.23 describe el Flujo Optico esperado a partir de los compo-
nentes de la velocidad angular y traslacional.
2.2.2. Recuperacion 3D a partir del Flujo Optico.
En la seccion anterior se revisaron las ecuaciones para obtener el Flujo Optico
esperado generado por los componentes de movimiento de la camara. El Flujo
Optico estima el movimiento de una escena dando por hecho una iluminacion in-
variante. Bajo la consideracion anterior, se puede asumir que la estimacion del
Flujo Optico esperado es similar al Flujo Optico calculado en la escena mediante
el algoritmo de correlacion. Esto es posible, porque ambos enfoques recuperan
los mismos vectores de movimiento para todos los puntos de la escena. Enton-
23
ces, los vectores de movimiento resultantes del Flujo Optico calculado pueden ser
combinados con los vectores del Flujo Optico esperado. De esta manera, se en-
cuentra una distancia hacia los puntos de la estructura en la escena. La solucion
para encontrar la distancia es por un metodo de minimizacion del error cuadrado
entre el Flujo Optico calculado (u, v) y el Flujo Optico esperado (uesp, vesp) [24].
La relacion de error entre el Flujo Optico calculado y el Flujo Optico esperado se
observa en la ecuacion de error 2.25 [3] [9].
Min(Z) = ((u − uesp)2 + (v − vesp)
2) (2.25)
sustituyendo el Flujo Optico esperado (ecuacion 2.23) en la expresion ante-
rior, el error total que se quiere minimizar esta dado por:
∫ ∫{[u − (ut + ur)]
2 + [v − (vt + vr)]2}[(Zut)
2 + (Zvt)2]dxdy (2.26)
por efectos de simplificacion se puede definir que:
α = −U + xW β = −V + yW (2.27)
sustituyendo las ecuaciones 2.27 en la ecuacion 2.26 se tiene:
∫ ∫{[u − (
α
Z+ ur)]
2 + [v − (β
Z+ vr)]
2}[α2 + β2]dxdy (2.28)
Para minimizar la ecuacion anterior, se diferencia con respecto a Z y se iguala
a cero la expresion resultante:
(α2 + β2)
{[(u − ur) − α
Z
] α
Z2+
[(v − vr) − β
Z
]β
Z2
}= 0 (2.29)
despejando Z de la ultima ecuacion se tiene:
Z =α2 + β2
(u − ur)α + (v − vr)β(2.30)
24
donde α y β estan definidas en la ecuacion 2.27, ur y vr en la ecuacion 2.24.
Con la ecuacion 2.30 se tiene Z en terminos del Flujo Optico calculado, (u, v),
por el metodo de correlacion. Al no tener una calibracion sobre los parametros de
la camara, estos aun son desconocidos. Sin embargo, los valores de los parametros
unicamente sirven para escalar el valor de Z y no afectan en la recuperacion de la
estructura. Por lo tanto, es posible asumir valores constantes para cada uno de los
parametros. La desventaja de la recuperacion 3D es que solo se tiene un valor de
profundidad relativo a los parametros de la camara.
2.3. Trabajos previos.
En la presente seccion se hace una revision a los trabajos relacionados con la
recuperacion 3D y el Flujo Optico.
Hernandez, en [12], propone una arquitectura FPGA para el calculo del Flujo
Optico en tiempo real, al menos 30 cuadros por segundo (fps). La arquitectura
esta basada en el algoritmo de correlacion Block matching en su version exhausti-
va. El algoritmo es empleado mediante el diseno de procesadores de movimiento,
los cuales contienen a su vez procesadores de distancia mınima. La arquitectura
propuesta tiene varios procesadores trabajando en paralelo. El trabajo reporta una
capacidad de procesamiento de 56 fps con para imagenes con resolucion de 640
× 480 pixeles.
En [16] Maya Rueda et al. proponen una implementacion FPGA para el calcu-
lo del Flujo Optico mediante el algoritmo basado en gradiente de Srinivasan. El
algoritmo ofrece una buena precision, sin embargo el tiempo para el computo del
Flujo Optico esta en el orden de segundos para secuencias de imagenes con re-
solucion de 512 × 512 pixeles, por lo que no es lo suficientemente bueno para
situaciones con restricciones de tiempo real. La principal aportacion de este tra-
bajo es que esta basado en un arreglo sistolico 2D y es escalable.
Dıaz y Rıos proponen en [26] una arquitectura de procesamiento segmentado
25
para el calculo del Flujo Optico con el algoritmo de Lucas y Kanade. La arqui-
tectura esta formada por 5 etapas de pipeline; en cada etapa el ancho de bus se
va incrementando, terminando con una precision de 25 bits en la unidad de punto
flotante. Este trabajo presenta el desempeno para 4 configuraciones con distinta
calidad y grado de paralelismo implementado. La configuracion con un buen ba-
lance entre calidad y rendimiento es capaz de procesar 24 fps para imagenes con
resolucion de 320 × 240 pixeles y haciendo uso del 65 % de un dispositivo de 2
millones de compuertas.
Rosales en [3] propone recuperar la profundidad a partir de la estimacion
de movimiento. La deteccion de movimiento la realiza a traves de Flujo Optico
utilizando un modelo de gradiente modificado. Rosales usa el seguimiento de ca-
racterısticas mediante un filtro Kalman como corrector de errores en el calculo del
Flujo Optico. La recuperacion de profundidad la realiza mediante el error cuadrati-
co medio entre el Flujo Optico calculado y el esperado. La implementacion solo
obtiene la recuperacion 3D para el movimiento traslacional de la camara. La im-
plementacion fue realizada en C++ y reporta tiempos de procesamiento para la
recuperacion 3D a partir de dos imagenes de 640 × 480 pixeles de 35 segundos.
Fife et al. en [27] reportan una implementacion para la recuperacion 3D para
la navegacion de pequenos vehıculos autonomos. En el trabajo, la recuperacion se
hace a traves de correspondencia de caracterısticas (esquinas). Para cada imagen,
el sistema debe localizar cada una de las caracterısticas que fueron identificadas
en la imagen previa y actualizar la estimacion actual de la posicion de cada una
en el espacio 3D. La implementacion fue realizada mediante computo reconfigu-
rable y el uso de procesadores empotrados. Los resultados de operacion son de 30
fps para imagen con una resolucion de 320× 240 pixeles. La principal desventaja
de este trabajo es la recuperacion 3D poco densa debido a que solo se calcula la
profundidad para puntos especıficos en la secuencia de video.
En [28], Sosa et al. proponen un sistema para la recuperacion 3D de una esce-
na rıgida. El sistema se basa en una secuencia de imagenes tomadas con un camara
en movimiento libre. Sosa realiza la recuperacion 3D mediante el seguimiento de
26
caracterısticas (esquinas) a lo largo de la secuencia de imagenes. Una vez encon-
tradas las caracterısticas se aplica geometrıa epipolar para cada par de imagenes
en la secuencia. Para la reconstruccion 3D no se necesita conocimiento previo de
la escena, solo la matriz de calibracion de la camara. La implementacion fue he-
cha en Borland Builder C++. El tiempo de procesamiento depende del numero
de imagenes, numero de caracterısticas y la posicion de las caracterısticas en las
imagenes. El trabajo reporta un tiempo promedio para la recuperacion menor a los
2 minutos para alrededor de 40 caracterısticas con una secuencia de 7 imagenes.
Yuan et al. en [29] presentan un metodo para obtener la reconstruccion 3D a
partir del fondo y el movimiento de los objetos en una secuencia de video. La re-
construccion 3D la realizan mediante dos metodos diferentes. Ellos usan el meto-
do conocido como estructura por movimiento (shape from motion) para hacer el
calculo de la reconstruccion 3D con el fondo estatico. Posteriormente calculan la
reconstruccion 3D a partir de los movimientos de los objetos. Para esto, utilizan
una camara virtual simulando que lo que se mueve es la camara y no el obje-
to. Despues, combinan ambos resultados para obtener la reconstruccion 3D. En
ambos metodos utilizan correspondencia de caracterısticas. Yuan et al obtienen
resultados cualitativos y cuantitativos para la demostrar la robustez y eficiencia
del metodo. El metodo utiliza 60 caracterısticas para la reconstruccion 3D y tiene
un error promedio de 0.78.
En [30] Dıaz et al. presentan una implementacion FPGA para la recupera-
cion 3D utilizando luz estructurada. En esta implementacion realizan una simpli-
ficacion de codigo buscando operaciones que sean redundantes en el algoritmo.
Ademas, las operaciones utilizadas son en punto fijo con una precision de 14 bits
para la parte entera y 5 o 6 para la parte decimal. El trabajo reporta tiempo de
procesamiento de alrededor de 20 segundos para imagenes con un resolucion de
640 × 480 pixeles.
Zach et al en [31], presentan un trabajo para acelerar la recuperacion 3D densa
en imagenes estereo. Su implementacion se basa en un diseno hardware-software.
La parte hardware del diseno usa el procedimiento que opera mediante empata-
27
miento de regiones evitando la perdida de exactitud por la limitada precision de
los calculos en las Unidad de Procesamiento de Grafico (GPU). Una vez hecho el
empatamiento de regiones la profundidad se calcula aplicando geometrıa epipolar.
La parte de software la utilizan para llevar el control de flujo y la transferencia de
informacion. La implementacion reporta el procesamiento promedio de 2.46 fps
para imagenes de 512 × 512, en una computadora con un procesador Athlon XP
2700 y una tarjeta de video ATI Radeon 9700.
En [32] Viejo et al. proponen la reconstruccion 3D de mapas a partir de da-
tos de rango (colecciones de puntos 3D) obtenidos mediante una camara estereo.
Viejo dividio en dos partes su proceso de reconstruccion. En la primer parte, a
partir de datos tomados a intervalos regulares de tiempo por un robot dentro de un
entorno realiza un proceso de empatamiento de puntos 3D. En la segunda parte,
y haciendo uso del resultado de la fase anterior, se plantea extraer las primitivas
geometricas (planos, cilindros, etc.) para hacer la reconstruccion del entorno. Los
autores reportan una reconstruccion de cualquier entorno a partir de un conjunto
de 4 millones de puntos 3D obtenidos por la camara estereo. Los autores no re-
portan el tiempo de procesamiento para la reconstruccion 3D.
Nister en [33] presenta una reconstruccion automatica de escenas 3D a partir
de imagenes y video. Para la recuperacion 3D utiliza multiples vistas del ambien-
te. En las imagenes obtenidas se realiza un seguimiento de caracterısticas. A cada
punto se le hace una estimacion geometrica para recuperar la posicion relativa de
la camara seguida por una optimizacion de mapas de profundidad en una formula-
cion Bayesiana. Posteriormente el autor aplica un metodo de Graph Cuts y estima
la textura de la superficie. Nister reporta una recuperacion 3D densa y robusta. El
autor reporta un tiempo de procesamiento de 12 segundos para la reconstruccion
tridimensional a partir de imagenes reales.
28
Tabl
a2.
1:T
raba
jos
rela
cion
ados
.
Aut
orM
etod
oIm
plem
enta
cion
Res
oluc
ion
FP
SO
bser
vaci
ones
Her
nand
ez[1
2]Fl
ujo
Opt
ico
Bas
ado
enC
orre
laci
on.
Impl
emen
taci
onH
Wco
n4
mod
ulos
para
laes
timac
ion
dem
ovim
ient
o.C
a-da
uno
tiene
5pr
oces
ador
esde
dist
an-
cia
mın
ima.
640×
480
56fp
sO
btie
neve
ctor
esde
mov
imie
nto
para
cada
4pi
xele
sen
laim
agen
.
May
a[1
6]Fl
ujo
Opt
ico
Bas
ado
enG
radi
ente
.Im
plem
enta
cion
HW
.C
onst
ade
unar
regl
osi
stol
ico
de8×
8pr
oces
ador
es.
160×
120
0.6
La
arqu
itect
ura
eses
cala
ble.
Dıa
z[2
6]Fl
ujo
Opt
ico
Bas
ado
enG
radi
ente
.Im
plem
enta
cion
HW
.Tie
ne5
etap
asde
pipe
line
y4
confi
gura
cion
espa
raca
li-da
dy
para
lelis
mo.
160×
120
y32
0×
240
97fp
sy
24fp
sU
sode
65%
deun
disp
ositi
vode
2000
ky
obtie
neve
ctor
espa
raca
da4
pixe
les
dela
imag
en.
Ros
ales
[3]
Rec
uper
acio
n3D
apa
rtir
deFl
ujo
Opt
ico.
Impl
emen
taci
onSW
.Cal
culo
delF
lujo
Opt
ico
med
iant
eal
gori
tmo
degr
adie
n-te
yfil
tros
pred
ictiv
os.
640×
480
.02
fps
La
impl
emen
taci
onfu
ere
aliz
ada
enC
++
con
vari
able
sen
form
ato
doub
lede
64bi
ts.
Fife
[27]
Rec
uper
acio
n3D
apa
rtir
deco
-rr
espo
nden
cia
deca
ract
erıs
ticas
.
Impl
emen
taci
onH
Wre
aliz
ada
me-
dian
teco
mpu
tore
confi
gura
ble
ypr
oce-
sado
res
empo
trad
os.
320×
240
30fp
sR
ecup
erac
ion
3Dpo
code
nsa.
Sosa
[28]
Rec
uper
acio
n3D
apa
rtir
del
mov
imie
nto
libre
deca
mar
a.
Impl
emen
taci
onSW
.U
tiliz
ase
gui-
mie
nto
deca
ract
erıs
ticas
yge
omet
rıa
epip
olar
para
lare
cons
truc
cion
3D.
640×
480
0.00
8fp
sL
aim
plem
enta
cion
fue
real
izad
aen
Bor
land
Bui
lder
C+
+y
solo
nece
sita
lam
atri
zde
calib
raci
onde
laca
mar
apa
rala
recu
pera
-ci
on.
Yua
n[2
9]R
ecup
erac
ion
3Da
part
irde
co-
rres
pond
enci
ade
cara
cter
ıstic
as.
Impl
emen
taci
onSW
que
real
iza
lare
-cu
pera
cion
3Dm
edia
nte
dos
met
odos
yco
mbi
nand
olo
sre
sulta
dos.
No
repo
rta
tiem
pode
proc
esa-
mie
nto
nila
reso
luci
onde
laim
agen
esqu
eus
a.
29
Tabl
a2.
1T
raba
jos
rela
cion
ados
(Con
tinua
cion
).
Aut
orM
etod
oIm
plem
enta
cion
Res
oluc
ion
FP
SO
bser
vaci
ones
Dıa
z[3
0]R
ecup
erac
ion
3Dus
ando
luz
estr
uctu
ra-
da.
Impl
emen
taci
onH
W,s
impl
ifica
cion
deco
digo
elim
inan
doop
erac
ione
sre
dun-
dant
esy
enre
pres
enta
cion
depu
nto
fijo
para
los
calc
ulos
.
640×
480
0.05
fps
Err
orge
nera
dodu
rant
eel
proc
e-sa
mie
nto
debi
doal
trun
cam
ient
olo
repo
rtan
com
oac
epta
ble.
Zac
h[3
1]R
ecup
erac
ion
3Da
part
irim
agen
eses
tero
.Im
plem
enta
cion
HW
-SW
,us
aem
pata
-m
ient
ode
regi
ones
yge
omet
rıa
epi-
pola
r,se
real
iza
med
iant
eH
W.
El
SWso
lolle
vael
cont
rol.
512×
512
2.46
fps
Cal
culo
deap
roxi
mad
amen
te13
0,00
0va
lore
sde
prof
undi
dad
por
segu
ndo.
Vie
jo[3
2]R
ecup
erac
ion
3Dm
e-di
ante
laex
trac
cion
depr
imiti
vas.
Impl
emen
taci
onSW
.L
are
cupe
raci
onse
real
iza
endo
spa
rtes
,en
lapr
ime-
rapa
rte
hace
empa
tam
ient
o3D
yco
nes
tos
resu
ltado
sha
cela
extr
acci
onde
prim
itiva
s.
nore
port
ado
nore
por-
tado
Part
ede
unco
njun
tode
mas
de4
mill
ones
depu
ntos
3Dob
teni
dos
por
elro
bote
nel
ento
rno
para
elpr
oces
o.
Nis
ter
[33]
Rec
uper
acio
n3D
apa
rtir
dem
ultip
les
vist
asde
lam
bien
te.
Impl
emen
taci
onSW
.Se
real
iza
unse
-gu
imie
nto
deca
ract
erıs
ticas
.Par
aca
dapu
nto
seha
cees
timac
ion
geom
etri
cay
ası
recu
pera
rla
posi
cion
rela
tiva
dela
cam
ara.
nore
port
ado
0.08
fps
El
auto
rre
port
aun
are
cupe
ra-
cion
3Dde
nsa
yro
bust
a.
Arq
.pr
opue
sta
Bar
ron
Rec
uper
acio
n3D
apa
rtir
delF
lujo
Opt
ico.
Impl
emen
taci
onH
W.
Util
iza
5m
odu-
los
con
20pr
oces
ador
esca
daun
opa
rael
calc
ulo
del
Fluj
oO
ptic
oy
etap
asde
pipe
line
para
lare
cupe
raci
on3D
.
640×
480
5fp
sL
aar
quite
ctur
aes
tima
elm
ovi-
mie
nto
detr
asla
cion
y/o
rota
cion
para
cada
pıxe
l,po
rlo
tant
ose
tiene
una
recu
pera
cion
3Dde
nsa
ym
edia
nte
una
sola
cam
ara.
30
La revision de la literatura, resumida en la tabla 2.1, incluyo trabajos relacio-
nados con el Flujo Optico y la recuperacion 3D.
Para el calculo del Flujo optico se puede resaltar el trabajo de [12]. En este
trabajo se realiza el calculo del Flujo Optico basado en correlacion y para image-
nes con resolucion VGA, lo cual es un requerimiento en el desarrollo del presente
trabajo de tesis. La capacidad de procesamiento reportada en [12] es mucho ma-
yor que la arquitectura propuesta, pero tiene la desventaja que obtiene los vectores
de movimiento para cada ventana de referencia, cada 4 pixeles, y al escalar a la
estimacion de movimiento pixel por pixel su capacidad de procesamiento por uni-
dad de tiempo es menor. Hernandez obtiene 1, 075, 200 vectores de movimiento
por segundo y la arquitectura propuesta calcula 1, 497, 045 vectores por segundo.
Los trabajos [26] y [16] tambien realizan el calculo del Flujo Optico. En es-
tos se puede observar que procesan imagenes con resolucion muy pequena y en
el caso de escalar a imagenes con resolucion VGA estarıan lejos de procesar en
el orden de 5 fps estimando el movimiento pixel por pixel, ya que representarıa
procesar una mayor cantidad de datos.
Para la recuperacion 3D, los trabajos mas relevantes son [3] y [27] debido a
que obtienen la recuperacion en base a la estimacion de movimiento. El principal
inconveniente que tiene [3] es su alto tiempo de procesamiento al ser una imple-
mentacion software compensado esto con su exactitud en los calculos. Ademas, el
calculo de profundidad es solamente para movimientos de traslacion de la camara.
En [27] se presenta una plataforma hardware con alta capacidad de procesamiento
(30 fps). La principal desventaja de la implementacion es que calcula la profun-
didad donde hay correspondencia de caracterısticas, por lo tanto su recuperacion
3D es dispersa.
La gran cantidad de datos manejados es una desventaja para algunos traba-
jos mencionados. Para el calculo del Flujo Optico las implementaciones descritas
anteriormente solo estiman el movimiento para cada ventana de referencia en la
imagen, por lo que se propone una arquitectura capaz de realizar el calculo de
movimiento para cada pixel de la imagen. En la recuperacion 3D, las implementa-
31
ciones presentan limitantes en el tiempo de respuesta o calculan una recuperacion
3D dispersa de la escena. Por lo anterior se propone una arquitectura que calcule
la profundidad para cada pixel en la imagen de la secuencia de video obteniendo
ası una recuperacion 3D densa. Ademas, la arquitectura es provista con elemen-
tos que permiten un flexible direccionamiento de los datos. Tambien se cuenta
con elementos de almacenamiento que facilitan la reutilizacion de la informacion
de los pixeles. El diseno de la arquitectura puede ser escalable y configurado de
acuerdo a diferentes requerimientos de area y rendimiento.
Capıtulo 3
Arquitectura propuesta.
La arquitectura propuesta tiene como objetivo la recuperacion 3D a partir del
Flujo Optico encontrado en una secuencia de video. La arquitectura tiene una
maxima reutilizacion de datos y una optimizacion en el uso de recursos. La arqui-
tectura realiza el procesamiento para la recuperacion 3D en tiempo predecible. Se
considera que un sistema opera en tiempo predecible cuando realiza el procesa-
miento en una restriccion de tiempo establecida, en este caso 5 fps.
El presente capıtulo esta dividido en 4 secciones, en las primeras dos se des-
cribe la arquitectura de manera general y las restricciones que debe cumplir. En la
tercera seccion se explican todos los modulos que la conforman, mientras que en
la cuarta se muestra la arquitectura final con una descripcion de su funcionamien-
to. El capıtulo concluye con una discusion de la escalabilidad y reconfigurabilidad
de la arquitectura.
32
33
3.1. Especificaciones de la arquitectura propuesta.
La arquitectura debe operar bajo ciertas especificaciones, las cuales tienen co-
mo finalidad lograr los objetivos planteados en el primer capıtulo. Las especi-
ficaciones permiten tener una arquitectura operando en tiempo predecible , una
maxima reutilizacion de datos y minimizando los accesos a memoria. Ademas,
las especificaciones, permiten calcular una recuperacion 3D densa y un diseno
que es escalable y configurable.
Dichas especificaciones se presentan a continuacion:
La arquitectura debe funcionar con imagenes en escala de grises. La arquitec-
tura trabaja con imagenes en escala de grises de 256 tonos. Cada valor de
pixel esta codificado mediante 8 bits. Los valores de los pıxeles deben ser
proporcionados por un sensor de imagen o por un proceso previo a la recu-
peracion 3D a partir del Flujo Optico.
La arquitectura debe trabajar con imagenes en resolucion VGA. La resolucion
de las imagenes para el funcionamiento de la arquitectura es de 640 × 480
pıxeles (resolucion VGA). Esta resolucion es ampliamente utilizada en di-
ferentes aplicaciones como analisis de imagenes y navegacion.
La arquitectura debe operar en tiempo predecible. Esto significa que la arqui-
tectura debe de procesar por lo menos 5 fps. La arquitectura debe ser capaz
de calcular 1, 536, 000 valores de profundidad por segundo y mejorar el
desempeno, con respecto a lo reportado en [3], en tres ordenes de magnitud.
La arquitectura debe maximizar la reutilizacion de datos. Esto tiene como ob-
jetivo minimizar los accesos a memoria y reducir los tiempos de latencia
ocasionados por los procesos de lectura. Para el proceso de la recuperacion
3D a partir del Flujo Optico se necesitan alrededor de 471.859 millones de
accesos a memoria por segundo [17].
La arquitectura debe ser portable. La arquitectura debe operar independiente-
mente del sistema en el que se use. Es decir, la arquitectura debe de fun-
cionar como un sistema digital por sı sola o como un modulo en un sistema
digital mas complejo.
34
La recuperacion 3D debe presentar un bajo error relativo con el software. Esto
se debe a la representacion que tienen las variables en la arquitectura. Se
establece un lımite de error de 0.001 por pixel en los calculos de la recupe-
racion 3D con respecto al software. El error es un promedio establecido de
acuerdo a los valores revisados en la literatura en la seccion 2.3.
Tamano y escalabilidad. La arquitectura puede ser implementada en un FPGA
de 1 a 1.5 millones de compuertas y es flexible para su futura escalabilidad
en dispositivos de mayor capacidad.
3.2. Descripcion de la arquitectura propuesta.
La arquitectura propuesta tiene como objetivo la recuperacion 3D a partir del
Flujo Optico. El diseno debe cumplir con las especificaciones anteriormente des-
critas, y se puede dividir en dos modulos funcionales principales: calculo del Flujo
Optico y calculo de recuperacion 3D.
El funcionamiento general de la arquitectura propuesta se muestra en la figu-
ra 3.1. En un primer paso, la arquitectura toma los datos referentes a los pıxeles
de dos imagenes consecutivas dentro de la secuencia de video. La transferencia
de los datos se realiza a traves de un bus de 8 bits. Posteriormente, se efectua el
proceso de calculo del Flujo Optico mediante el algoritmo de correlacion utili-
zando las ecuaciones 2.10 y 2.13, donde se obtienen los vectores de movimiento
(u, v). Estos vectores se entregan al proceso para la recuperacion 3D. Este preceso
se realiza mediante la ecuacion 2.30, para cada par de vectores de movimiento.
Por ultimo, los valores obtenidos en el proceso de la recuperacion 3D se entregan
al mundo real, memorias externas u otros procesos, mediante un bus de datos de
salida de 36 bits. Las direcciones de escritura y de lectura son generadas por un
proceso encargado de llevar a cabo el control del flujo de datos. Las senales que
coordinan el funcionamiento de la arquitectura estan dispuestas en un bloque de
control.
A partir de la descripcion anterior, se realiza el diseno de la arquitectura don-
de cada proceso se describe mediante un modulo funcional. La arquitectura se
muestra en la figura 3.2, en donde se observan los siguientes modulos principales:
35
Ruteadores.
Modulo Calculo de Flujo Optico.
Modulo Calculo de Profundidad.
Control.
Figura 3.1: Funcionamiento general de la arquitectura propuesta.
Figura 3.2: Diagrama general a bloques de la arquitectura.
A continuacion se proporciona una breve descripcion de los modulos de la
arquitectura.
Ruteadores. Su funcion es hacer el calculo de las direcciones para lectura y es-
critura de datos a la memoria externa. El modulo tambien almacena varios
36
renglones de las imagenes para realizar un solo proceso de lectura para cada
dato de la memoria externa. Debido a que el algoritmo de correlacion se ba-
sa en el manejo de ventanas, hace uso del mismo dato varias veces. Al tener
el dato almacenado dentro de la arquitectura ya no es necesario leerlo cada
vez que se necesite de la memoria externa. Los modulos Ruteadores llevan
el control del suministro de datos al modulo de Flujo Optico y el control pa-
ra el almacenamiento de los valores de Z calculados por el modulo calculo
de profundidad.
Modulo de calculo de Flujo Optico. El modulo realiza la estimacion de movi-
miento mediante la medida de correlacion SAD. El modulo esta formado
por varios procesadores que trabajan en paralelo. Cada uno realiza el calcu-
lo de la resta entre pixeles y valor absoluto. Una vez que ha terminado el
procesamiento de las ventanas de referencia y de busqueda, el modulo pro-
porciona los vectores de movimiento al modulo de calculo de profundidad.
Modulo de calculo de Profundidad. Su funcion es calcular los valores de pro-
fundidad por medio de lo vectores de movimiento obtenidos por el modulo
Flujo Optico. El modulo esta formado por etapas tipo pipeline para un me-
jor rendimiento. El diseno en pipeline consiste en ir transformando un flujo
de datos en un proceso comprendido por varias fases secuenciales, siendo
la entrada de cada una la salida de la anterior [18]. Al terminar el calculo
de la profundidad, el modulo entrega el resultado a los ruteadores para su
almacenamiento en la memoria externa.
Modulo Control. Lleva el control general de la arquitectura y sincroniza cada
uno de los modulos descritos anteriormente.
En las siguientes secciones se dara una descripcion detallada de los modulos
de la arquitectura.
3.3. Modulos funcionales de la arquitectura propues-
ta.
En seguida se presenta una descripcion mas detallada del funcionamiento de
cada modulo de la arquitectura propuesta en la figura 3.2, ası como de los factores
37
que influyeron en su diseno.
3.3.1. Modulo calculo de Flujo Optico.
En esta seccion se describe la arquitectura utilizada en el modulo calculo de
Flujo Optico, encargado de obtener los vectores de movimiento. Como primer pa-
so, se hara una breve revision del funcionamiento del algoritmo para el calculo
del Flujo Optico basado en correlacion. La finalidad de dicha revision es resaltar
el alto grado de paralelismo y la gran reutilizacion de datos en el algoritmo.
El proceso del algoritmo para el calculo del Flujo Optico basado en correla-
cion se muestra en la figura 2.1 e implica el calculo de las ecuaciones 2.10 y
2.13. El algoritmo de correlacion opera de la siguiente manera: se toman los va-
lores correspondientes a las ventanas de busqueda y de referencia de la secuencia
de imagenes. La ventana de referencia se coloca sobre la ventana de busqueda
(posicion 1 de la figura 3.3) y se calcula la correlacion mediante SAD (ecuacion
2.10) para obtener un valor de similitud entre la ventana de referencia y parte de la
ventana de busqueda. El valor de similitud es almacenado en una matriz de 5 × 5
elementos. La ventana de referencia se desplaza una posicion sobre la de busque-
da (posicion 2 en la figura 3.3), se calcula la correlacion en la nueva posicion y
se obtiene una medida de similitud para esta posicion. El nuevo valor de correla-
cion obtenido es almacenado en la matriz de correlacion. Este proceso se repite
hasta que la ventana de referencia hace un barrido completo sobre la ventana de
busqueda, es decir, la ventana de referencia toma las 25 diferentes posiciones en
la ventana de busqueda. Una vez que todos los valores de correlacion han sido
almacenados en la matriz, se analizan y se obtiene el menor valor de correlacion,
al igual que su posicion dentro de la matriz. Por ultimo, se realiza el calculo del
vector de desplazamiento. Este se calcula tomando la distancia del centro de la
matriz a la posicion donde se encuentra el elemento con menor valor de correla-
cion.
Ahora, partiendo de un enfoque secuencial, se analizara el rendimiento del
proceso de la figura 3.3. Para este analisis, se parte de varias suposiciones. La
primera es que todos los datos estan disponibles de manera inmediata. La ventana
de referencia es de un tamano de 4 × 4 pixeles y la ventana de busqueda es de
38
Figura3.3:Proceso
deestim
acionde
movim
iento.
39
8 × 8 pixeles. El calculo de la correlacion mediante SAD (seccion 2.1.5) contie-
ne 3 operaciones, que se realizan en un solo ciclo de reloj. Por lo tanto, para el
calculo de la correlacion entre la ventana de referencia y parte de la ventana de
busqueda se necesitan 16 ciclos de reloj.
De la figura 3.3 se observa que cada ventana de referencia contiene 25 posi-
ciones en la ventana de busqueda. Por lo anterior, para procesar cada ventana de
busqueda en la imagen se necesitan 400 ciclos de reloj (25 posiciones/ventana de
busqueda × 16 ciclos de reloj/posicion). Ahora cada imagen contiene 633 venta-
nas de busqueda de manera horizontal y 473 de manera vertical. En consecuencia,
para hacer el procesamiento de una imagen con un elemento que realice las tres
operaciones, se necesitan 119, 763, 600 ciclos de reloj ((633 × 433) ventanas de
busqueda/imagen × 400 ciclos de reloj/ventana de busqueda).
El numero de operaciones por segundo (OPS) para el calculo de la estimacion
de movimiento a traves SAD se define en [17], que esta dado por:
OPS = 3 ∗ 2p ∗ 2p ∗ Nh ∗ Nv ∗ f (3.1)
Donde Nh y Nv son el tamano vertical y horizontal de la imagen en pıxeles, p
es el tamano de la ventana de busqueda y f representa la tasa de cuadros por se-
gundo. Para este trabajo en particular con p = 8, f = 5, Nh = 640 y Nv = 480,
la ecuacion anterior da como resultado una carga computacional de 235, 929, 600
operaciones aritmeticas enteras por segundo. Por lo tanto, un enfoque secuencial
o un procesador de proposito general actual resulta inadecuado e insuficiente para
la estimacion de movimiento.
Por lo anterior, en esta tesis se utiliza un enfoque paralelo donde se realizan
un conjunto de operaciones en un mismo ciclo de reloj. Para el diseno se utiliza
un bloque base llamado Elemento Procesador (PE), que se encarga de realizar la
operacion de resta entre pixeles y el calculo de valor absoluto necesarias en SAD.
Todo el proceso se realiza en un ciclo de reloj. El diagrama del bloque PE se
muestra en la figura 3.4.
Una primera aproximacion en el diseno del modulo calculo de Flujo Optico
40
es colocar 4 elementos PE en paralelo (figura 3.5). En el figura 3.6, se muestra el
procesamiento de la ventana de referencia en las posiciones dentro de la ventana
de busqueda.
Figura 3.4: Diagrama del Elemento Procesador (PE), bloque base de la arquitec-tura.
Figura 3.5: Primera aproximacion para el modulo calculo de Flujo Optico con 4bloques PE trabajando en paralelo.
En el ejemplo se muestra como en cada ciclo de reloj se realiza el calculo de
4 operaciones en paralelo. Por consecuencia, el arreglo de 4 bloques PE necesita
4 ciclos de reloj para realizar la correlacion de la ventana de referencia sobre la
ventana de busqueda. El diseno necesita 100 ciclos para procesar por completo la
ventana de busqueda (4×25). El numero total de ciclos de reloj para procesar una
imagen completa es de 29, 940, 900 (100 × 633 × 473).
Esta cantidad aun es demasiado elevada, por lo cual una segunda aproxima-
cion es replicar 5 veces el diseno de la figura 3.5. En esta nueva aproximacion se
tienen 20 bloques PE trabajando en paralelo. El nuevo diseno realiza en 4 ciclos
de reloj el calculo de la correlacion entre las ventanas de referencia y de busqueda,
41
Figura 3.6: Procesamiento de la ventana de referencia dentro de la ventana debusqueda para el arreglo de 4 bloques PE. En cada ciclo de reloj se realiza elprocesamiento de 4 pixeles en paralelo
al igual que en el diseno anterior, pero con la ventaja de que mientras se calcula la
correlacion en la primera posicion dentro de la ventana de busqueda, se empiezan
a calcular las correlaciones correspondientes a las tres posiciones contiguas de la
ventana de referencia. El diseno hace reutilizacion de datos aprovechando varias
veces el mismo para efectuar el calculo de varias correlaciones. El calculo de la
correlacion entre las primeras 5 posiciones de la ventana de referencia en la de
busqueda se realiza en 8 ciclos de reloj. El arreglo con 20 bloques PE permite
procesar la ventana de busqueda en 40 ciclos de de reloj (8 × 5). El numero de
ciclos de reloj para procesar una imagen es 11, 976, 360 (40 × 633 × 473).
El diseno de la figura 3.7 aprovecha el traslape presentado por las ventanas de
referencia en las diferentes posiciones sobre la ventana de busqueda. En la figura
3.8 se observa el procesamiento de la venta de referencia y de busqueda para el
arreglo el arreglo de 20 elementos PE. En el primer ciclo de reloj se procesa la
primera columna de la ventana de referencia en la posicion 1. En el segundo ciclo
42
Figura 3.7: Segunda aproximacion del modulo calculo de Flujo Optico. Funcionacon 20 bloques PE .
de reloj se procesa la segunda columna de la ventana de referencia en la posicion
1 y empieza el procesamiento de la ventana de referencia en la posicion 2. Para
el tercer ciclo de reloj se procesa la tercera columna de la ventana de referencia
en la posicion 1, la segunda columna de la ventana de referencia en la posicion 2
y comienza el procesamiento de la ventana de referencia en la posicion 3. En el
cuarto ciclo de reloj se termina de procesar la ventana de referencia en la posicion
1 y se obtiene el primer resultado de correlacion, se procesa la tercera columna
de la ventana de referencia en la posicion 2, se procesa la segunda columna de la
ventana de referencia en la posicion 3 y comienza el procesamiento de la ventana
de referencia en la posicion 4.
El procesamiento de las demas ventanas continua mientras la columna 1 de
elementos PE deja de operar. En el quinto ciclo de reloj comienza el procesamien-
to de la posicion 5 de la ventana de referencia, se termina de procesar la posicion
2 de la ventana de referencia y se obtiene el segundo valor de correlacion, se pro-
cesan la tercera y la cuarta columna de la ventana de referencia en las posicion 3 y
4 respectivamente. En el sexto ciclo de reloj se termina de procesar la ventana de
referencia en la posicion 3 y se obtiene el tercer valor de correlacion, se procesa
la tercera columna de la ventana de referencia en la posicion 4 y se procesa la se-
gunda columna de la ventana de referencia en la posicion 5. En el septimo ciclo de
reloj el procesamiento de la ventana de correlacion en la posicion 4 termina y se
obtiene el cuarto valor de correlacion, se procesa la tercer columna de la ventana
43
de referencia en la posicion 5. Por ultimo, en el octavo ciclo de reloj se termina de
procesar la posicion 5 de la ventana de referencia y se obtiene el ultimo valor de
correlacion. El proceso anterior realiza el calculo de la correlacion para la primera
posicion vertical de la ventana referencia. Por lo tanto, para procesar por comple-
to la ventana de busqueda se repite para cada una de las posiciones que ocupa la
ventana de referencia de manera vertical.
Figura 3.8: Procesamiento de la ventana de referencia dentro de la ventana debusqueda para el arreglo de 20 bloques PE.
En el diseno de la figura 3.7 se aprovecha el traslape horizontal de las ven-
tanas de referencia. Por lo tanto, para aprovechar el traslape de manera vertical,
se replica 5 veces el diseno de la figura 3.7 cubriendo por completo la ventana
de busqueda. El diseno procesa la ventana de busqueda en 8 ciclos de reloj y la
imagen completa en 2, 386, 432 ciclos de reloj (8 × 473 × 633). La arquitectura
para el modulo calculo de Flujo Optico se muestra en la figura 3.9.
La figura 3.10 muestra el procesamiento de la ventana de referencia en las di-
ferentes posiciones de la ventana de busqueda. El arreglo cuenta con 100 bloques
PE funcionando de forma paralela. El arreglo tiene el mismo funcionamiento para
el procesamiento que el arreglo con 20 bloques PE en las posiciones horizontales
de la ventana de referencia. La diferencia es que el arreglo de 100 bloques PE pro-
cesa en el mismo instante las 5 posiciones verticales de la ventanas de referencia.
44
Figura 3.9: Diagrama del modulo calculo de Flujo Optico, opera con 100 bloquesPE en paralelo.
45
Figura 3.10: Procesamiento de la ventana de referencia dentro de la ventana debusqueda para el arreglo de 100 bloques PE.
46
El diseno hace una maxima reutilizacion de datos aprovechando el traslape
horizontal y vertical de la ventana de referencia. Ademas, el tiempo de procesa-
miento con este diseno se reduce 50 veces con respecto al enfoque secuencial.
Por ultimo, el bloque encargado de obtener los vectores de movimiento con los
valores de correlacion es el bloque de comparacion (ecuacion 2.13). Este bloque
es un arreglo combinacional que no necesita ciclos adicionales para sus calculos.
Mientras se procesa la ventana de busqueda, se calcula parcialmente cual es el
menor valor de correlacion, ası como su posicion dentro de la matriz. El diseno
final del modulo calculo de Flujo Optico se muestra en la figura 3.11.
Figura 3.11: Diagrama final del modulo calculo de Flujo Optico.
47
En la figura 3.12 se muestra una aproximacion del rendimiento de la arquitec-
tura para el calculo del Flujo Optico obtenido de manera experimentalmente. En
el inciso (a), se visualizan los ciclos de reloj necesarios para procesar las ventanas
de busqueda y de referencia. En el inciso (b), el numero de ciclos de reloj necesa-
rios para el procesamiento de una imagen completa. Ambas dependen del numero
de bloques PE utilizados.
(a)
(b)
Figura 3.12: Graficas de rendimiento del modulo calculo de Flujo Optico.
El modulo calculo de Flujo Optico entrega los vectores de movimiento en las
variables u y v. Dichas variables se entregan cada 8 ciclos de reloj y de manera
directa al modulo calculo de profundidad. u y v no se almacenan en la memoria
externa debido a su nula utilizacion en etapas futuras. Ademas, el tamano de la
48
memoria externa es limitado por lo cual no es practico almacenar los vectores de
movimiento.
3.3.2. Modulo calculo de profundidad.
La recuperacion de la profundidad de una secuencia de video puede ser reali-
zada en base al Flujo Optico calculado y al Flujo Optico esperado. En la seccion
2.2.1 se parte del sistema coordenado mostrado en la figura 3.13, del cual se
obtiene la ecuacion 3.2.
Figura 3.13: Sistema coordenado de referencia.
Z =α2 + β2
(u − ur)α + (v − vr)β(3.2)
donde:
α = −U + xW β = −U + yW
ur = Axy − B(x2 + 1) + Cy vr = A(y2 + 1) − Bxy − Cx(3.3)
La implementacion de la ecuacion 3.2 se puede realizar de dos formas: la pri-
mera es implementar la ecuacion con elementos puramente combinacionales. La
complejidad de la ecuacion es demasiado alta al incluir operaciones de multipli-
cacion y division, por lo que un enfoque combinacional afectarıa notablemente el
rendimiento de la arquitectura.
La segunda forma de implementacion es mediante el diseno en pipeline. La
49
forma de diseno en pipeline permite dividir el calculo de la ecuacion 3.2 en eta-
pas. Este enfoque ataca la complejidad de la ecuacion al dividirla en operaciones
mas simples y de facil implementacion. Ademas, se cuenta con 8 ciclos de reloj
entre cada par de vectores calculados por el modulo calculo de Flujo Optico, por
lo que, la implementacion en pipeline resulta adecuada para el diseno del modulo
calculo de profundidad sin afectar el rendimiento total de la arquitectura.
A continuacion se describen las etapas de pipeline y los bloques del modulo
calculo de profundidad. Las operaciones en las etapas se hacen en aritmetica de
punto fijo, los bloques tienen diferentes longitudes en la parte entera como en la
parte fraccional segun se necesite. La finalidad de una longitud variable es tener
el error mas bajo posible sin hacer un consumo excesivo de recursos.
La primera etapa del pipeline realiza el calculo de las variables α y β, ası como
parte del calculo de las variables ur y vr. En la tabla 3.1 se muestran las variables
que se procesan en esta etapa y los diagramas de los bloques.
Tabla 3.1: Primera etapa de pipeline.
α x2 + 1
β y2 + 1
y ∗ x
50
Las variables x e y son valores enteros representados con 10 bits. Las variables
U , V y W son fracciones y se representan con 8 bits, 0 bits para la parte entera y
8 bits para la parte fraccional. Las variables α y β resultan con una longitud de 17
bits en representacion de 9 bits para la parte entera y 8 bits para la parte fraccional.
En la segunda etapa del proceso de pipeline se calculan los valores cuadrados
de α y β, y otra parte de las variables ur y vr. La tabla 3.2 muestra las variables
calculadas en la etapa, ası como el diagrama de los bloques.
Tabla 3.2: Segunda etapa de pipeline.
α2 A ∗ (y2 + 1)
β2 B ∗ (x ∗ y)
B ∗ (x2 + 1) C ∗ x
A ∗ (x ∗ y) C ∗ y
Para el calculo de α2 y β2 solo se toma parte de los valores α y β: se toman
unicamente 5 bits de la parte entera y los 8 bits de la parte fraccional. Este trunca-
miento se hace en base a que los valores de U , V y W son relativamente bajos, lo
51
que provoca valores de α y β pequenos en la parte entera o incluso valores iguales
a cero. Por esta razon nunca se requieren de mas de 5 bits para la representacion
de la parte entera.
En la tercera etapa de pipeline se termina el calculo de las variables ur y vr.
En esta etapa tambien se ajusta la posicion del punto decimal en los vectores de
movimiento u y v. El ajuste de las variables consiste en mover el punto para que
las operaciones se realicen con la misma representacion en punto fijo. Para los
calculo de ur y vr no se realiza ningun truncamiento al no tener una longitud muy
larga (26 bits). La tercera etapa del proceso se muestra en la tabla 3.3.
Tabla 3.3: Tercera etapa de pipeline.
ur u′
vr v′
La penultima etapa hace el calculo de las variables que conforman el denomi-
nador de la ecuacion 3.2. La tabla 3.4 muestra los componentes de esta etapa.
Tabla 3.4: Cuarta etapa de pipeline.
(u − ur)α (v − vr)β
52
En la ultima etapa se hace el calculo del numerador y del denominador, se
ajusta el punto en la misma posicion y se realiza la division para obtener el valor
de profundidad. La tabla 3.5 muestra la etapa final del pipeline.
Tabla 3.5: Quinta etapa de pipeline.
α2 + β2 Z
u − (ur)α + v − (vr)β
En la figura 3.14 se presenta el diseno para el modulo calculo de profundi-
dad y en la figura 3.15 se muestra el calculo de la profundidad en cada una de
las etapas de pipeline. Una vez que se han calculado los vectores de movimiento
comienza el calculo del valor de profundidad. Los valores de entrada A, B, C,
U , V , y W simulan un movimiento de traslacion de un objeto en la direccion del
eje x. El movimiento del objeto es de un pixel por imagen en la simulacion. La
simulacion fue realizada en Handel-C.
El valor de profundidad es obtenido con una representacion de 9 bits. La re-
presentacion de Z es de 0 bits para la parte entera y 9 bits para la parte fraccional.
Esta representacion se utiliza para obtener un resultado con un error bajo, cum-
pliendo la restriccion planteada en la primera seccion del capıtulo. La resolucion
de las variables de entrada A, B, C, U , V y W afecta directamente la exactitud en
el calculo de la profundidad. Las variables x y y no varıan su resolucion ya que
dependen directamente del tamano de la imagen. En el capıtulo 4 se muestra un
analisis de como afecta la resolucion de las variables de entrada en el calculo de
la profundidad.
53
Figu
ra3.
14:M
odul
oca
lcul
ode
prof
undi
dad.
54
Figura 3.15: Calculo de profundidad en las diferentes etapas de pipeline.
3.3.3. Modulos Ruteadores.
La principal funcion de los modulos Ruteadores es suministrar el direcciona-
miento a la memoria para la lectura de datos o escritura de las imagenes a procesar,
ası como tambien el direccionamiento de los datos a sus respectivos modulos de
procesamiento.
El primer aspecto a considerar es la forma de almacenamiento los datos de en-
trada y salida. A diferencia de un modelo de software, donde el almacenamiento
de la imagenes se representa en arreglos bidimensionales, en un modelo hardware
los datos se almacenan en un arreglo unidimensional, es decir, un vector. En la fi-
gura 3.16 se observa la forma de almacenamiento de las imagenes en los modelos
software y hardware.
En los modelos hardware, el almacenamiento masivo de datos se realiza re-
gularmente en memorias de acceso aleatorio, conocidas como memorias RAM
(Random Access Memory). Las memorias RAM poseen diferentes capacidades y
anchos de palabra por localidad. Para la arquitectura propuesta se trabaja con una
55
Figura 3.16: Almacenamiento de datos en los modelos software y hardware.
memoria de 256k × 36Abits, es decir, es una memoria con 262, 144 localidades
de almacenamiento, cada una con un ancho de palabra de 36 bits. Esta memoria
permite almacenar 4 pıxeles de la imagen por cada localidad. Esto contribuye a
tener un menor numero de accesos a memoria, dado que por cada ciclo de lectura
se obtienen 4 pıxeles en vez de uno solo. En la figura 3.17, se muestra el esquema
de almacenamiento de los datos en la memoria utilizada.
En la memoria RAM se almacenan los datos correspondientes a dos imagenes
consecutivas de la secuencia de video. Para ello, la memoria se dividio en sec-
ciones, como se muestra en la figura 3.18. Cada parte de la memoria almacena
datos especıficos. En la parte baja de la memoria, de la direccion 00000016 a la
12BFF16, se almacena la imagen actual, mientras que de la direccion 12C0016 a
la 257FF16 se almacena la imagen previa. Los valores de profundidad se almace-
nan de la direccion 2580016 en adelante.
El proceso de lectura de datos es realizado por el modulo Ruteador de Lectu-
ra. El modulo fue disenado en base a la forma en que el modulo calculo de Flujo
Optico necesita los datos para estimar los vectores de movimiento. El Ruteador
de Lectura opera de la siguiente manera: el modulo lee y almacena 8 renglones
56
Figura 3.17: Forma de almacenamiento de datos en la memoria RAM.
Figura 3.18: Mapa de la memoria RAM utilizada.
de la imagen previa, estos datos forman la ventana de busqueda. Posteriormente,
el modulo lee y almacena 4 renglones de la imagen actual, que forman la ventana
de referencia. Los datos se almacenan en arreglos independientes de memorias
RAMs internas. El Ruteador de Lectura proporciona 12 datos de forma paralela,
8 de la ventana de busqueda y 4 de la ventana de referencia, como lo necesita el
modulo calculo de Flujo Optico para su funcionamiento. Al mismo tiempo que se
suministran los datos, se hacen los calculos de las nuevas direcciones para la lec-
57
tura de datos a la memoria RAM. El diagrama del modulo Ruteador de Lectura,
con las variables de entrada y salida, se muestra en la figura 3.19. La figura 3.20
muestra los componentes internos del modulo.
Figura 3.19: Diagrama del modulo Ruteador del Lectura
Figura 3.20: Componentes del bloque Ruteador de Lectura.
Los bloques Gen Addr VB y Gen Addr VR realizan el calculo de las direccio-
nes para la lectura de datos. Estos son controlados mediante una senal de habilita-
cion que les indica a los bloques cuando realizar el calculo de la nueva direccion
de lectura.
58
El almacenamiento de los datos de las imagenes se hace en los bloques Buf-
fer VB y Buffer VR. Los bloques de almacenamiento estan compuestos por 8 y
4 renglones de memorias RAMs internas. Cada renglon de la memoria esta com-
puesto por 640 localidades con una ancho de palabra de 9 bits. Una vez que ambos
buffers son llenados por completo, empieza el suministro de los datos al modulo
calculo de Flujo Optico. Los datos, como se menciono anteriormente, son sumi-
nistrados de manera paralela y el flujo es controlado por dos punteros de direc-
cion (bloques Ptr VB y Ptr VR). Cada que se termina de procesar una ventana de
busqueda, los datos en las direcciones de los punteros se almacenan en el renglon
previo, en la misma direccion, y se lee un nuevo dato de la memoria RAM exter-
na. Este se almacena en el ultimo renglon de los buffers, en la direccion de los
punteros. Con esto se mantienen los buffers con datos listos para ser suministra-
dos al modulo calculo de Flujo Optico. En las figuras 3.21 y 3.22 se muestra la
estructura de los buffers de almacenamiento.
Figura 3.21: Estructura interna del bloque Buffer VB de almacenamiento.
El bloque Sep Datos realiza la manipulacion de los datos de 36 bits, prove-
nientes de la memoria externa, para que puedan ser manejados por los buffers de
almacenamiento. El modulo esta formado por dos registros de desplazamiento a
la derecha, un registro para los datos de la imagen previa y otro para los datos
59
Figura 3.22: Estructura interna del Buffer BR de almacenamiento.
de la imagen actual. El ultimo bloque del modulo Ruteador de Lectura es el de
control. Este se forma por una maquina de estados finitos (FSM, por sus siglas en
ingles). El bloque de control mantiene la sincronizacion activando o desactivando
el proceso de lectura de datos. Este bloque a su vez recibe las senales del control
maestro para iniciar o detener su funcionamiento.
El modulo Ruteador de Lectura logra maximizar la reutilizacion de datos me-
diante el almacenamiento de parte de los datos dentro de la arquitectura. El modu-
lo lee solo una vez cada dato de entrada de la memoria externa y ası reduce los
tiempos de latencia ocasionados por el proceso de lectura.
El modulo Ruteador de Escritura (figura 3.23) realiza la escritura en la me-
moria RAM de los resultados proporcionados por la arquitectura . Este modulo
es mucho mas simple que el modulo Ruteador de Lectura. El modulo Ruteador
de Escritura esta formado por un generador de direcciones y un registro (figura
3.24).
Figura 3.23: Diagrama del modulo Ruteador de Escritura.
60
Figura 3.24: Componentes del modulo Ruteador de Escritura.
El bloque Gen Addr Esc controla la direccion de almacenamiento del dato co-
rrespondiente a la profundidad, proveniente del modulo calculo de profundidad.
El bloque Concatena une 4 valores de profundidad calculados por la arquitectura.
La concatenacion tiene como funcion almacenar un dato de 36 bits en cada loca-
lidad de la memoria RAM.
Los modulos Ruteador de Lectura y Ruteador de Escritura comparten el bus
de datos para los procesos lectura y escritura en la memoria externa. Esto se hace
porque solo se cuenta con un bus bidireccional para realizar los dos procesos. El
control general de la arquitectura le indica al controlador de la memoria RAM
cuando se va efectuar una lectura o escritura en la memoria externa y ası seleccio-
nar el bus de datos correspondiente.
3.3.4. Modulo Control.
El modulo de Control se encarga de la sincronizacion de cada uno de los
modulos de la arquitectura. Este modulo esta formado por una maquina de es-
tados finitos. El diagrama del modulo de Control se muestra en la figura 3.25 y
en la tabla 3.6 se muestra la descripcion de sus terminales.
Figura 3.25: Diagrama del modulo Control.
61
Tabla 3.6: Descripcion de pines del modulo Control.Pin Tipo DescripcionRCI IN Fin de proceso de captura de imagen.ICA OUT Inicia proceso de captura de imagen.FCR IN Fin de almacenamiento de datos de la imagen.FPI IN Fin de imagen.SCR OUT Inicia proceso de carga de ruteadores.RFO IN Vectores de movimiento listos.IFO OUT Inicia proceso de calculo de vectores de movimiento.FPO IN Termina el calculo de profundidadCPO OUT Inicia el calculo de profundidadALZ IN Almacenamiento de profundidad terminado.HLD OUT Espera un nuevo valor de profundidad para almacenar.
En la figura 3.26 se muestra la maquina de estados finitos del modulo Con-
trol. En el primer estado, s0, se inicia el proceso de captura de las imagenes y su
almacenamiento en la memoria RAM externa mediante la senal ICA. Al terminar
el proceso de captura, mediante la senal RCI, se pasa al siguiente estado. En el
estado s1, se empieza el proceso de lectura de datos de la memoria externa (me-
diante la senal SCR) por el modulo Ruteador Lectura, el fin del proceso de lectura
de datos se hace con la senal FCR y se avanza al siguiente estado. Para el estado
s2, se empieza el calculo del Flujo Optico, a traves de la senal IFO, con la primera
ventana de busqueda y de referencia. La senal RFO indica cuando se terminan de
procesar las ventanas. En el estado s3, se empieza el proceso para el calculo de la
profundidad y se hace la lectura de dos nuevos datos a la memoria externa para
almacenarlos en el modulo Ruteador Lectura, uno para la ventana de busqueda y
otro para la de referencia, mediante la senal SCR. En el siguiente estado, s4, se
continua con el calculo de profundidad y se empieza a procesar la siguiente ven-
tana de busqueda y de referencia. Al terminar el calculo de la profundidad, senal
RPO, se pasa al estado s5 donde se almacena el valor de profundidad y se sigue
con el calculo de los vectores de movimiento regresando al estado s2. Los estados
s5 y s6 realizan el calculo y almacenamiento del valor de profundidad cuando se
termino de estimar el movimiento en toda la imagen. Una vez terminado el ultimo
calculo de profundidad, se reinicia el proceso regresando al estado s0.
62
Figura 3.26: Maquina de Estados Finitos para el modulo de Control.
3.4. Arquitectura Final.
En la figura 3.27 se muestra la arquitectura propuesta para realizar la recu-
peracion 3D a partir del Flujo Optico. En la figura se muestran todos lo modulos
descritos en las secciones anteriores y su interconexion.
La arquitectura final funciona de la siguiente manera: como primer paso se
almacenan un par de imagenes provenientes de un sensor u otro proceso. Las
imagenes se almacenan segun el mapa de memoria de la figura 3.18. En seguida,
se lee un arreglo de datos de las dos imagenes por el modulo Ruteador de Lectura,
8 renglones de la imagen previa y 4 renglones de la imagen actual. A continua-
cion, los datos almacenados en el modulo se direccionan a los elementos PE para
la estimacion de movimiento. Una vez calculados los vectores de movimiento se
pasan al siguiente modulo para el calculo de la profundidad. Paralelamente se
adquiere un nuevo dato de la imagen actual y de la imagen de referencia, y se em-
pieza el proceso de la estimacion de movimiento. Una vez terminado el calculo
63
Figu
ra3.
27:A
rqui
tect
ura
prop
uest
apa
rala
recu
pera
cion
3Da
part
irde
lFlu
joO
ptic
o.
64
de profundidad, el resultado se almacena en la memoria externa y se espera por
los vectores de movimiento para realizar el proceso nuevamente. Al terminar el
proceso de estimacion de movimiento, los vectores son suministrados nuevamente
para el calculo de la profundidad. Esto se repite hasta terminar de procesar el par
de imagenes. Al finalizar el procesamiento de las imagenes se inicia con una nue-
va captura de un par de imagenes y su almacenamiento. La figura 3.28 muestra el
diagrama de funcionamiento de la arquitectura propuesta.
Figura 3.28: Diagrama de funcionamiento de la arquitectura.
65
3.5. Rendimiento de la arquitectura propuesta.
A partir de la descripcion general de la arquitectura se puede obtener un esti-
mado del rendimiento. La velocidad de procesamiento de la arquitectura se puede
estimar en funcion del tamano de la imagen, el numero de ciclos necesarios para
procesar una ventana de referencia de n × n, el numero de PEs operando en pa-
ralelo y el numero de veces que se repite el arreglo de bloques PE que forman el
diseno. Para el analisis se parte del modulo mas lento que es el modulo calculo de
Flujo Optico.
El numero de ciclos para procesar un renglon de la ventana de busqueda de
m × m con la ventana de referencia de n × n esta dado por el numero de ciclos
para procesar un renglon de la ventana de referencia mas el numero de ciclos para
procesar las posiciones que ocupa la ventana de referencia sobre la de busqueda
de manera horizontal. El numero de ciclos para procesar un renglon de la ventana
de busqueda se calcula mediante la ecuacion 3.4.
#ciclos×reng = #ciclos×V r +(#ciclos×V r)(V rpos hor)
#Vr proc par
(3.4)
donde:
#ciclos×reng es el numero de ciclos para procesar un renglon de la ventana de
busqueda.
#ciclos×V r es el numero de ciclos para procesar un renglon de la ventana de re-
ferencia.
V rpos hor) es el numero de posiciones que ocupa la ventana de referencia en la de
busqueda de manera horizontal.
#Vr proc par es el numero de ventanas que se procesan en paralelo.
El numero de ciclos para procesar una ventana de busqueda es: el tamano de
la ventana de referencia, n, multiplicado por el numero de ciclos para procesar
un renglon de la ventana de busqueda y por el numero de posiciones que ocupa
la ventana de referencia en la de busqueda de manera vertical. Dividida por el
numero de procesadores que funcionan en paralelo y el numero de veces que
se repite el arreglo de bloques PE. Una vez terminada de procesar la ventana
de busqueda, se hace la lectura de 2 datos de la memoria externa, por lo que se
66
necesitan 2 ciclos de reloj mas. La ecuacion 3.5 calcula el numero de ciclos para
procesar la ventana de busqueda:
#ciclos×Vb=
n(#ciclos×reng)(V rpos ver)
(#PEpar)(#bloquesPEpar)+ #cicloslectura (3.5)
donde:
#ciclos×Vbes el numero de ciclos para procesar una venta de busqueda.
n es el tamano de la ventana de busqueda.
#ciclos×reng es el numero de ciclos para procesar un renglon de la ventana de
referencia.
V rpos ver) es el numero de posiciones de la ventana de referencia en la de busque-
da.
#PEpar es el numero de elementos procesadores que operan en paralelo.
#bloquesPEpar es el numero de veces que se repite el arreglo de elementos proce-
sadores.
Por ultimo, la ecuacion 3.6 representa el numero total de ciclos para procesar
una imagen completa. Esto se calcula multiplicando el numero de ciclos para pro-
cesar la ventana de busqueda por el numero de ventanas de busqueda que hay en
la imagen manera horizontal y vertical.
#ciclos×Imag = (#ciclos×Vb)(Imghor − m + 1)(Imgver − m + 1) (3.6)
para el modulo propuesto se tienen los valores de:
n = 4
m = 8
#ciclos×V r = 4 ciclos:
V rpos hor = m − n = 8 − 4 = 4 posiciones.
#Vr proc par = 4 ventanas.
V rpos ver = m − n + 1 = 8 − 4 + 1 = 5 posiciones.
#PEpar = 4 bloques PE operando en paralelo.
#bloquesPEpar = 5 bloques de 4 elementos PE.
Imghor = 640
Imgver = 480
67
Sustituyendo los valores de #ciclos×V r, V rpos hor y #Vr proc par en 3.4 se
obtiene:
#ciclos×Vreg = 4 +(4)(4)
4= 8aciclos×reng (3.7)
Ahora se sustituyen los valores de n, #ciclos×Vb, V rpos ver, #bloquesPEpar
y #PEpar en la ecuacion 3.5 para obtener el numero de ciclos para procesar la
ventana de busqueda.
#ciclos×Vb=
4(8)(5)
(4)(5)+ 2 = 10aciclosap/V b (3.8)
Para obtener el numero de ciclos totales para procesar una imagen se sustituye
los valores m, #ciclos p/Vb, Imghor y Imgver en la ecuacion 3.6.
#ciclos×Imag = (10)(640− 8)(480− 8) = 2, 994, 090aciclosap/imagen (3.9)
Si se considera que la arquitectura funciona a 50 MHz, se puede estimar enton-
ces el numero de cuadros procesados por segundo. La arquitectura puede procesar
16 fps para imagenes con resolucion 640 × 480 pixeles. Por lo tanto, se supera
ampliamente el objetivo de 5 fps propuesto en este trabajo de tesis.
3.6. Escalabilidad y Reconfigurabilidad.
3.6.1. Escalabilidad.
Con frecuencia la arquitectura de una aplicacion se evalua en terminos de su
rendimiento (throughtput): la habilidad que tiene para terminar un numero dado
de operaciones logicas en un periodo especıfico de tiempo. La meta es lograr una
arquitectura que garantice que el rendimiento alcanzara un nivel suficientemente
alto, que permita darle un tiempo de respuesta adecuado. Una arquitectura escala-
ble es aquella que tiene la capacidad de incrementar el rendimiento sin que tenga
que redisenarse, aprovechando el hardware adicional que se le agregue [41].
Como se menciono anteriormente, la habilidad de una arquitectura para es-
calar se evalua en terminos del rendimiento que puede ofrecer. Considerese la
68
grafica de la figura 3.29 en la que se compara el rendimiento contra los recursos
hardware para un diseno hipotetico. En la grafica se muestra un crecimiento no
lineal del rendimiento. En otras palabras, la tasa a la que el rendimiento crece, va
disminuyendo y eventualmente se estabiliza. La estabilizacion representa el rendi-
miento maximo posible que la arquitectura proveera sin importar cuantos recursos
de hardware se pongan a su disposicion [41].
Figura 3.29: Rendimiento comparado contra recursos hardware [41].
La arquitectura propuesta es escalable en el modulo calculo de Flujo Optico.
El modulo calculo de profundidad, al tener un diseno en pipeline, puede operar
tan rapido como el modulo calculo de Flujo Optico calcule los vectores de movi-
miento. En otras palabras, si el modulo estima los vectores de movimiento cada
ciclo de reloj, el modulo calculo de profundidad operarıa entregando un valor de
profundidad cada ciclo de reloj una vez lleno el pipeline.
El numero de ciclos de reloj necesarios para procesar la ventana de busque-
da con la de referencia es el mınimo sin importar cuantos mas elementos PE se
anadan al arreglo. Es decir, el tiempo de procesamiento para la ventana de busque-
da no se puede reducir aunque se agreguen mas elementos PE. La limitante se
debe a la forma en que son entregados los datos de las ventanas de referencia y
de busqueda. La escalabilidad para el modulo calculo de Flujo Optico se puede
hacer mediante el procesamiento de varias ventanas de busqueda en paralelo. En
el diseno propuesto solo procesa una ventana de busqueda a la vez sin aprovechar
el traslape entre ventanas. En la figura 3.30 se muestra el funcionamiento de la
arquitectura propuesta. La arquitectura procesa cada 8 ciclos de reloj la ventana
69
de busqueda, como se menciono anteriormente.
Figura 3.30: Funcionamiento de la arquitectura propuesta, se procesa una ventanade busqueda cada 8 ciclos de reloj.
Para procesar las 5 posiciones se necesitan 40 ciclos de reloj con el diseno
propuesto. La forma de escalar la arquitectura es replicando varias veces el modu-
lo calculo de Flujo Optico. Con ello se logra aprovechar el traslape de datos que
haya en las diferentes ventanas de busqueda. En la figura 3.31 se muestra el pro-
cesamiento replicando 4 veces el modulo calculo de Flujo Optico. El numero de
ciclos se reduce notablemente de 40 a solo 12 ciclos de reloj. En la figura se mues-
tra el arreglo de 20 PE para cada modulo calculo de Flujo Optico, con el cual se
procesa el primer renglon de la ventana de busqueda.
En la figura 3.31 se observa el procesamiento de la ventanas de busqueda y
como se aprovecha el traslape entre ventanas. En el primer ciclo de reloj empieza
el procesamiento de la ventana de busqueda en la posicion 1, con el primer modulo
70
calculo de Flujo Optico. En el segundo ciclo se continua con el procesamiento de
la ventana de busqueda en la posicion 1 y se comienza a procesar la ventana de
busqueda en la posicion 2 con el segundo modulo calculo de Flujo Optico. El
proceso continua hasta que se activan todos los modulos y se estan procesando 4
ventanas de busqueda en paralelo (cuarto ciclo de reloj).
Figura 3.31: Funcionamiento de la arquitectura escalandola con 4 modulos decalculo de Flujo Optico.
En el quinto ciclo de reloj, la primera columna de bloques PE del modulo 1
de calculo Flujo Optico empieza a procesar la ventana de busqueda en la posicion
5. Esto es posible debido a que parte de los datos de la ventana de busqueda en
la posicion 1 son los mismos que los de la ventana de busqueda en la posicion
5 (figura 3.32), solo cambian los datos de la ventana de referencia. En paralelo
el modulo 1 de calculo de Flujo Optico procesa la posicion 1 de la ventana de
busqueda y la posicion 5. Lo mismo se aplica para los demas modulos de calculo
Flujo Optico, el modulo 2 procesa la posicion 2 de la ventana de busqueda y la
71
posicion 6, el modulo 3 procesa la posicion 3 de la ventana de busqueda y la posi-
cion 7, el modulo 4 procesa la posicion 4 de la ventana de busqueda y la posicion 8.
Figura 3.32: Traslape entre las ventanas de busqueda en la posiciones 1 y 5.
En la figura 3.31, los bloques en negro indican el procesamiento de las ven-
tanas de busqueda en las siguientes posiciones. Con el arreglo de 4 modulos
calculo Flujo Optico es posible obtener los vectores de movimiento cada ci-
clo de reloj y el tiempo de procesamiento es de solo 299, 409 ciclos de reloj
((640 − m + 1) ∗ (480 − m + 1)) por imagen. Suponiendo que la arquitectura
opera a 50 MHz se podrıan procesar alrededor de 166 cuadros por segundo. Este
calculo no toma en cuenta los accesos a memoria para lectura de datos y almace-
namiento de resultados.
El diseno propuesto podrıa operar arriba de 30 fps agregando otro modulo
calculo de Flujo Optico. Al tener dos modulos funcionando (figura 3.33) se pue-
de realizar el procesamiento de las ventanas de busqueda en paralelo y obtener los
vectores de movimiento para las dos ventanas en 9 ciclos de reloj. El numero de
ciclos de reloj para procesar una imagen con 2 modulos de Flujo Optico en para-
lelo es 1, 345, 212 (9 × 633/2 × 473). Si la arquitectura opera 50 MHz se pueden
procesar 37 fps.
El analisis de escalabilidad muestra hasta donde es conveniente hacer crecer
el diseno propuesto, y como es posible obtener el procesamiento en tiempo real
72
Figura 3.33: Procesamiento realizado con 2 modulos calculo de Flujo Optico.
de 30 fps.
3.6.2. Reconfigurabilidad.
La reconfigurabilidad en hardware involucra la manipulacion de la logica del
dispositivo FPGA en tiempo de ejecucion. En otras palabras, el diseno hardware
puede cambiar en respuesta a los incrementos en las demandas del sistema mien-
tras esta funcionando. Aquı, el FPGA actua como una plataforma de ejecucion
para una variedad de diferentes funciones hardware tal como un CPU es la base
de ejecucion para una variedad de tareas software [42].
A partir de la definicion anterior podemos decir que la arquitectura no es re-
configurable pero si parametrizable. La parametrizacion de la arquitectura con-
siste en hacer que el diseno opere solo utilizando algunos bloques PE. Esto se
realiza modificando directamente el codigo la arquitectura mientras esta no reali-
za ningun procesamiento. La parametrizacion a este nivel no tiene mucho sentido,
ya que si se quiere procesar una gran cantidad de informacion, reducir el numero
de elementos PE solo incrementara el tiempo de procesamiento, pero puede servir
para implementar el diseno en plataformas FPGAs de menor capacidad.
Capıtulo 4
Implementacion y resultados.
En este capıtulo se presenta la implementacion, sıntesis y resultados de la
arquitectura propuesta en el capıtulo 3. Para evaluar el desempeno de la arquitec-
tura, se utilizaron secuencias de imagenes sinteticas y reales. De igual forma, se
muestra el consumo de recursos de hardware en el FPGA y las velocidades de pro-
cesamiento obtenidas. Tambien se presentan los resultados de la implementacion
hardware.
El presente capıtulo esta dividido en las siguientes secciones: la primera hace
referencia a la implementacion y las herramientas usadas durante el desarrollo de
esta tesis. La segunda seccion presenta la metodologıa de prueba para validar la
arquitectura propuesta. En la tercera y cuarta seccion se presentan los resultados
obtenidos y un analisis del rendimiento de la arquitectura. La quinta seccion pre-
senta el rendimiento de la arquitectura y en la ultima se hace una discusion sobre
los resultados obtenidos.
73
74
4.1. Implementacion.
Para la implementacion, la arquitectura fue descrita en Handel-C mediante DK
4.0 SP2 y se utilizo ISE Project Navigator 9.1 para la sıntesis. El dispositivo usado
para la implementacion fue la tarjeta de desarrollo ML403 de la companıa Xilinx.
En la implementacion software de los algoritmos se utilizo Matlab version 7.3.
4.1.1. Software utilizado.
Handel-C y DK. Handel-C es un lenguaje para la descripcion de hardware
basado en la sintaxis convencional de C. Los programas escritos en Handel-C son
implıcitamente secuenciales, un comando es escrito despues de otro indicando
que las instrucciones deben de ser ejecutadas en ese orden [34]. En Handel-C
el flujo de programa se traduce en una maquina de estados finitos por lo que se
simplifica el diseno de la etapa de control. Handel-C provee las expresiones nece-
sarias para describir algoritmos complejos, pero tambien permite caracterısticas
de alto nivel, como son los apuntadores y la aritmetica de punto flotante. Ademas,
al ser Handel-C un compilador hardware de bajo nivel, permite la ejecucion de
varias instrucciones en paralelo mediante la palabra reservada par. Por lo tanto,
Handel-C permite obtener los mismo beneficios al describir un diseno como cual-
quier otro lenguaje de descripcion de hardware como VHDL o Verilog. DK es una
herramienta para el diseno y creacion de sistemas electronicos usando Handel-C.
DK provee facilidades para la creacion, depuracion, simulacion, compilacion y
simulacion de sistemas digitales [35].
ISE Project Navigator es una de las herramientas proporcionadas por el fa-
bricante de FPGAs Xilinx para la sıntesis del diseno implementado en Handel-C.
La herramienta se encarga de obtener el archivo de configuracion del FPGA a
partir del archivo de descripcion EDF generado por Handel-C [21]. Los archivos
EDF son un formato usado para intercambiar datos entre diferentes sistemas CAD
(Computer Aided Design) [36].
Matlab es un lenguaje de alto nivel y ambiente interactivo para el desarrollo de
algoritmos, computo numerico, visualizacion y analisis de datos. Matlab permite
acortar el tiempo de desarrollo de una aplicacion gracias a la gran cantidad de
75
librerıas que posee [38]. En Matlab se realizo la implementacion software de los
algoritmos para la recuperacion 3D a partir del Flujo Optico.
4.1.2. Hardware utilizado
La plataforma utilizada para las pruebas es una tarjeta ML403, de la com-
panıa Xilinx. La tarjeta ML403 es una plataforma de evaluacion disponible para
disenadores con fines de investigacion y desarrollo [37]. La plataforma cuenta
con un dispositivo FPGA de la familia Virtex-4. Algunas de las caracterısticas de
la tarjeta de se mencionan a continuacion:
FPGA Virtex-4: ML403 modelo XC4VFX12.
Memoria asıncrona ZBT SRAM de 8 MB de 36 bits.
Puerto Serial RS-232.
Reloj de operacion de 100 MHz.
LEDs y botones.
Convertidor de video de 15 bits.
Chip de interfaz USB.
Puerto VGA y conectores PS/2 (Personal System/2) para teclado y raton.
Puerto de configuracion JTAG (Joint Test Action Group).
La tarjeta ML403 provee un ambiente de diseno completo a traves de las di-
ferentes caracterısticas que posee. Los medios de almacenamiento con los que
cuenta la plataforma permite guardar elevadas cantidades de informacion, con
respecto a otras plataformas, de una manera sencilla. La tarjeta ML403 permiten
la comunicacion con el exterior por medio de sus interfaces (puerto serial, puerto
VGA, puerto JTAG, convertidores) de una manera directa. Ademas, la plataforma
cuenta con diferentes tipos de entradas y salidas (LED, botones). Por lo tanto, la
tarjeta ML403 es una plataforma que ofrece grandes prestaciones para el diseno y
prueba de sistemas digitales.
76
4.2. Metodologıa de prueba.
En la figura 4.1 se muestra la metodologıa de prueba de la arquitectura pro-
puesta en esta tesis.
El primer paso es el desarrollo de la arquitectura mediante Handel-C con el
paquete de diseno DK 4 Design Suite de Celoxica. En este paquete de software
se realizaron las simulaciones de los modulos en forma individual y en conjunto,
con el fin de observar que el funcionamiento sea correcto. Para la etapa de simu-
lacion, se toman dos imagenes de la secuencia y se codifican mediante Matlab
como archivos de texto, los cuales tienen la funcion de memorias externas en la
simulacion. La simulacion del diseno calcula la recuperacion 3D y el Flujo Optico
almacenado los resultados en archivos de texto. Posteriormente, los archivos obte-
nidos en la simulacion, mediante Matlab, se convierten en matrices y se visualizan
los resultados. Paralelamente, se ejecuta el algoritmo de la recuperacion 3D a par-
tir del Flujo Optico en Matlab y se analizan los resultados de ambas simulaciones
(Matlab y Handel-C).
Posteriormente se realiza la sıntesis de la arquitectura, con la cual se obtie-
ne la frecuencia de trabajo de la arquitectura y el consumo de espacio dentro del
dispositivo FPGA seleccionado. La sıntesis se realiza con ISE Project Navigator
utilizando el archivo EDF generado por Handel-C. El archivo de configuracion
generado es un archivo .bit. Este contiene la configuracion de conectividad del
dispositivo FPGA [19].
La validacion de la arquitectura se realizo descargando el archivo .bit en la
plataforma de evaluacion y mediante una computadora personal. Las dos image-
nes codificadas como archivos de texto son enviadas a la plataforma de evaluacion
desde Matlab a traves de una comunicacion serial, RS-232. La arquitectura reali-
za el calculo de la recuperacion 3D a partir del Flujo Optico. Los datos obtenidos
son enviados a la computadora personal a traves de comunicacion serial. Mediante
Matlab, los datos calculados por la arquitectura son recibidos y codificados como
una matriz para su visualizacion. Por ultimo, en Matlab se realiza un analisis de
los resultados obtenidos en la simulaciones software (Matlab y Handel-C) y la
implementacion hardware. La figura 4.1 muestra un esquema de la metodologıa
77
de prueba.
Figura 4.1: Metodologıa de prueba de la arquitectura.
Las pruebas se hicieron con secuencias de imagenes sinteticas y reales. La ta-
bla 4.1 es un resumen de las secuencias utilizadas en la pruebas, presentado las
diferentes caracterısticas de las imagenes. Las secuencias utilizadas se descarga-
ron de [39] y son ampliamente utilizadas para las pruebas de algoritmos de Flujo
Optico y de recuperacion 3D. Estas secuencias no son de resolucion VGA y me-
diante la etapa de codificacion a archivos de texto se cambiaron a esta resolucion.
Este cambio consiste en rellenar con ceros los valores mayores al tamano real de
la imagen en la secuencia.
78
Num. Sec. Tipo desecuen-cia
Num. deimagenes
Resolucion Tipo deimagen
Mov.pro-medio
Imagen
(1) Lata Sintetica 40 160 × 120640 × 480
Color 1 ppf
(2) Cubo Sintetica 50 160 × 240 Color 1.2 ppf
(3) Carro Sintetica 50 160 × 120 Color 1.3 ppf
(4) Calle Sintetica 50 120 × 160 Color 1.2 ppf
(5) LataPepsi
Real 10 100 × 100 Escaladegrises
1 ppf
(6) Jardın Real 30 160 × 120 Escaladegrises
1.5 ppf
Tabla 4.1: Secuencias utilizadas en las pruebas de la arquitectura
4.3. Resultados de las pruebas en el dispositivo.
En esta seccion se presentan y analizan los resultados obtenidos por la arqui-
tectura propuesta operando en la plataforma de evaluacion.
79
4.3.1. Resultados para el Flujo Optico.
Las figuras 4.2, 4.3 y 4.4 muestran los resultados obtenidos para el Flujo
Optico de la simulacion software (SW) y la implementacion hardware (HW) con
la secuencia Lata(1). Esta secuencia simula diferentes movimientos de traslacion
a traves de los ejes X y Y . El desplazamiento es de 1 pixel por imagen durante
toda la secuencia.
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.2: Resultados obtenidos del Flujo Optico a partir de la secuencia Lata(1). La secuencia simula un movimiento de traslacion de un pixel por imagen atraves del eje X .
80
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.3: Resultados obtenidos para el Flujo Optico a partir de la secuencia Lata(1). La secuencia simula un movimiento de traslacion de un pixel por imagen atraves del eje Y .
81
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.4: Resultados obtenidos para el Flujo Optico a partir de la secuencia Lata(1). La secuencia simula un movimiento de traslacion de un pixel por imagencombinado a traves del eje X y del eje Y .
82
Las pruebas realizadas para el Flujo Optico de las secuencias (2), (3) y (4) se
observan en las figuras 4.5, 4.6 y 4.7 respectivamente. Las secuencias utilizadas
presentan diferentes grados de complejidad [39]. En estas secuencias el fondo ya
no es completamente uniforme y en ocasiones tambien presenta movimiento. Por
lo tanto, hay una mayor posibilidad de calcular un Flujo Optico incorrecto.
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.5: Resultados obtenidos de Flujo Optico a partir de la secuencia Cubo(2).En la secuencia el cubo y la esfera presentan movimiento. El cubo presenta unmovimiento de traslacion combinado a traves del eje X y del eje Y , en tanto quela esfera presenta un movimiento de rotacion sobre su propio eje.
83
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.6: Resultados obtenidos de Flujo Optico a partir de la secuencia Carro(3).En la secuencia el carro y el satelite muestran movimiento. El cubo muestra unmovimiento de traslacion a traves del eje X , en tanto que el satelite presenta unmovimiento de acercamiento.
84
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(a) Simulacion SW
0 20 40 60 80 100 120 140 160−120
−100
−80
−60
−40
−20
0
(b) Implementacion HW
Figura 4.7: Resultados obtenidos para el Flujo Optico a partir de la secuenciaCalle(4). En la secuencia el carro, satelite y la calle presentan movimiento. Elcarro presenta un movimiento de traslacion a traves del eje X , el satelite presentaun movimiento de traslacion en el eje X y la calle presenta un movimiento derotacion sobre su propio eje con respecto a la camara.
85
4.3.2. Resultados para la recuperacion 3D.
Las primeras pruebas de recuperacion 3D se realizaron con el Flujo Optico
de la secuencia Lata(1). En las figuras 4.8 a 4.11 se muestran los resultados
obtenidos por la arquitectura propuesta para esta secuencia. La recuperacion 3D
se hace solamente para un par de imagenes
(a) Simulacion SW
(b) Implementacion HW
Figura 4.8: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opticocalculado de la secuencia Lata(1) para un par de imagenes.
86
(a) Simulacion SW
(b) Implementacion HW
Figura 4.9: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opticocalculado de la secuencia Lata(1) para un par de imagenes.
87
(a) Simulacion SW
(b) Implementacion HW
Figura 4.10: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co calculado de la secuencia Lata(1) para un par de imagenes.
88
(a) Simulacion SW
(b) Implementacion HW
Figura 4.11: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co calculado de la secuencia Lata(1) para un par de imagenes. La resolucion es de640 x 480 pixeles en las imagenes
Los resultados obtenidos de la recuperacion 3D a partir del Flujo Optico mues-
tran una recuperacion burda de los objetos en la escena. Estos resultados se deben
a que la recuperacion 3D se realiza con los vectores de movimiento obtenidos a
partir de un par de imagenes. Esto es una limitante en la arquitectura.
Una forma de mejorar los estos resultados es combinar la salida de varias
89
recuperaciones 3D. Esto permite tener una reconstruccion mas detallada de los
objetos en la escena. Las figuras 4.12, 4.13, 4.14 y 4.15 muestran los resultados
obtenidos a partir de un metodo iterativo para la secuencia Lata(1). El metodo
toma los valores de varias recuperaciones 3D previas, las promedia y obtiene una
reconstruccion final mas detalla de los objetos. El metodo utiliza 28 iteraciones
para obtener la recuperacion 3D final.
Figura 4.12: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata(1), iteracion 7.
Figura 4.13: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata(1), iteracion 14.
90
Figura 4.14: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata(1), iteracion 21.
Figura 4.15: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata(1), iteracion 28.
Los resultados de la recuperacion 3D a partir del Flujo Optico de la secuencia
Lata(1) ha permitido comprobar el correcto funcionamiento del modulo. ası como
el del metodo propuesto para obtener una recuperacion 3D mas detallada. En este
metodo, la integracion de los resultados se hace desde software, cada uno de los
valores es proporcionado por la arquitectura.
Una vez comprobado el correcto funcionamiento de los modulos, se utiliza-
ron secuencias de imagenes mas complejas. Las secuencias Lata Pepsi y Jardın se
utilizaron para las pruebas con imagenes reales. Estas secuencias tienen la carac-
91
terıstica de que la intensidad de los pıxeles no se conserva, lo que puede llevar a
calcular un Flujo Optico erroneo y por tanto una incorrecta recuperacion 3D. Una
forma de minimizar el problema es usar los valores de varias recuperaciones 3D
y obtener un promedio, al igual que en la secuencia Lata(1). Las figuras 4.16,
4.17, 4.18 y 4.19 muestran la recuperacion 3D para la secuencia Lata Pepsi(5)
en diferentes iteraciones. Para la secuencia Jardın(5) las figuras 4.20, 4.21, 4.22
y 4.23 muestran la recuperacion 3D para un numero de 15 iteraciones.
Figura 4.16: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata Pepsi(5), iteracion 1.
Figura 4.17: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata Pepsi(5), iteracion 3.
92
Figura 4.18: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata Pepsi(5), iteracion 6.
Figura 4.19: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Lata Pepsi(5), iteracion 9.
93
Figura 4.20: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Jardın(6), iteracion 1.
Figura 4.21: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Jardın(6), iteracion 5.
94
Figura 4.22: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Jardın(6), iteracion 10.
Figura 4.23: Resultados obtenidos para la recuperacion 3D a partir del Flujo Opti-co de la secuencia Jardın(6), iteracion 15.
95
4.3.3. Implementacion, resultados y sıntesis.
La sıntesis del diseno se realizo con el programa de Xilinx ISE Project Navi-
gator 9.1. El diseno se sintetizo para el dispositivo Xilinx Virtex-4 XC4VFX12.
La sıntesis de la arquitectura permite obtener un reporte de los recursos hardware
utilizados y de retardos dentro del diseno.
El Place & Route, proporciona informacion acerca de los recursos utilizados
dentro del dispositivo elegido. Un numero importante en este reporte es el nume-
ro de LUTs ( lookup tables), ya que indica cuanto espacio se ocupo dentro del
dispositivo. Las tablas 4.2, 4.3, 4.4 y 4.5 muestran la estadıstica de consumo
de recursos utilizados en el dispositivo y la frecuencia maxima de operacion. La
tabla 4.2 muestra el consumo de recursos hardware para el modulo calculo de
Flujo Optico. La tabla 4.3 presenta el uso de recursos para el modulo calculo
de profundidad. La tabla 4.4 muestra el consumo de recursos de la arquitectura
completa. Por ultimo, la tabla 4.5 muestra el porcentaje de recursos utilizados por
los modulos y la arquitectura propuesta.
Tabla 4.2: Resultados de sıntesis para el modulo calculo de Flujo Optico.Recursos Utilizacion
FFs: 1, 986 de 10, 944LUTs: 5, 192 de 10, 944Slices: 3, 519 de 5, 472
Frec. Maxima de Oper. 70 MHz
Tabla 4.3: Resultados de sıntesis para el modulo calculo de profundidad.Recursos Utilizacion
FFs: 68 de 10,944LUTs: 1, 882 de 10,944Slices: 983 de 5,472
Frec. Maxima de Oper. 100 MHz
96
Tabla 4.4: Resultados de sıntesis de la arquitectura completa.Recursos Utilizacion
FFs: 2, 177 de 10, 944LUTs: 8, 024 de 10, 944Slices: 4, 739 de 5, 472
BlockRams : 12 de 36Frec. Maxima de Oper. 66 MHz
Tabla 4.5: Porcentaje de consumo de recursos del dispositivo FPGA por los modu-los de la arquitectura propuesta.
Modulo % recursosModulo calculo de Flujo Optico 47Modulo calculo de profundidad 17
Arquitectura propuesta 73
4.4. Analisis de resultados.
En esta seccion se muestra un analisis de los resultados obtenidos para la recu-
peracion 3D a partir del Flujo Optico. Ademas, se revisan los resultados obtenidos
en la sıntesis de la arquitectura.
4.4.1. Analisis de resultados software/hardware.
El analisis de los resultados es una tarea importante para medir el desempeno
de la arquitectura. En este trabajo se utilizaron diferentes metricas para el Flujo
Optico y para la recuperacion 3D. Todo el analisis se efectua comparando los re-
sultados de la implementacion hardware con la simulacion software.
Para el calculo del Flujo Optico, el tratar de resumir la calidad de millones de
vectores de movimiento a un solo numero es una tarea muy complicada, por tanto
se prefirio utilizar dos metricas. La primera metrica es el error entre el angulo
de los vectores calculados mediante la simulacion software y el angulo de los
vectores de la implementacion hardware. Esta metrica nos indica el porcentaje
acumulado de vectores que tienen un error a determinado angulo o menor. La
metrica de error esta dada por la ecuacion 4.1 [40].
EA = cos−1(c · e) (4.1)
97
donde EA es el error medido, c es el vector de movimiento calculado por el
software y e es el vector de movimiento calculado por hardware. c denota la nor-
malizacion del vector.
La segunda metrica es la magnitud normalizada de la diferencia entre los vec-
tores calculados por las simulacion software y los obtenidos por la implementa-
cion hardware. El factor de normalizacion es la magnitud del vector de movimien-
to correcto [40]. Este error esta dado por la ecuacion 4.2.
EA =
‖c−e‖‖c‖ si ‖c‖ ≥ T ,
‖e‖−TT
si ‖c‖ < T y ‖e‖ ≥ T ,
0 si ‖c‖ < T y ‖e‖ < T ,
(4.2)
A partir de las metricas de error se obtuvo que el 100 % de los vectores calcu-
lados por la implementacion tienen un error igual a cero con respecto a la simula-
cion software, es decir, se obtienen los mismo vectores de movimiento en ambos
casos. Este comportamiento es correcto debido a que el algoritmo implementado
trabaja con numeros enteros y no se realiza ningun truncamiento en las operacio-
nes realizadas en la implementacion hardware.
Al igual que para el Flujo Optico, no hay una medida unica de error para la ex-
traccion 3D. Por lo anterior, para medir la calidad de la recuperacion 3D se uso la
medida de error RMSE (Root Mean Squared Error). La RMSE es frecuentemente
usado como una medida de las diferencias entre el valor predicho por un modelo
y el valor observado de lo que se esta modelando. En la medida de error se usaron
los valores calculados por software como los valores predichos y los valores ob-
tenidos por la implementacion hardware como los valores observados. El RMSE
esta dado por la ecuacion 4.3.
RMSE(θ) =
√E((θ − θ)2) (4.3)
Como se menciono en el capıtulo 3, la exactitud en el calculo de la recupera-
cion 3D se ve afectada directamente por la resolucion de las variables de entrada
A, B, C, U , V y W . La grafica de la figura 4.24 muestra el error promedio
obtenido para representar valores fraccionales, al implementar las variables con
diferentes resoluciones. Todos las variables tienen la misma resolucion y su repre-
98
sentacion es en aritmetica de punto fijo. Todos los bits de la resolucion se utilizan
para representar la parte fraccional de las variables. Los valores fueron obtenidos
a traves de la implementacion hardware.
Figura 4.24: Error promedio en funcion de la resolucion utilizada en las variablesde entrada A, B, C, U , V y W .
En la grafica anterior se observa como el error promedio disminuye conforme
se aumenta la resolucion de las variables de entrada. La reduccion del error no se
hace de manera lineal y el comportamiento de la grafica indica un punto donde la
reduccion ya no es significativa, sin importar que se incremente el numero de bits
en las variables.
Tambien, a partir de la resolucion de las variables de entrada, se obtiene el
error en el calculo de la recuperacion 3D. La figura 4.25 muestra el error obte-
nido en los calculos de profundidad en base a la resolucion de las variables de
entrada. Al igual que en la grafica de la figura 4.24, la curva decae rapidamente
para los primeros valores y luego tiende a una estabilizacion. En el punto de es-
tabilizacion, el incremento en el numero de bits tiene poco efecto en la reduccion
del error en el calculo de la recuperacion 3D.
99
Figura 4.25: Error RMSE de la recuperacion 3D en funcion de la resolucion de lasvariables de entrada A, B, C, U , V y W .
Por ultimo, la grafica de la figura 4.26 muestra la variacion del uso de recursos
combinacionales (LUTs) del dispositivo contra la resolucion de las variables de
entrada. A diferencia de las dos graficas anteriores, esta tiene un comportamiento
casi lineal. El consumo de recursos crece conforme se va incrementando el nume-
ro de bits en la resolucion de los variables.
Figura 4.26: Numero de LUTs utilizadas en el dispositivo en funcion de la reso-lucion de las variables de entrada A, B, C, U , V y W .
A partir de las graficas anteriores, se puede seleccionar el numero de bits pa-
100
ra la resolucion de las variables. En las figuras 4.24 y 4.25 se observa que una
resolucion de 8 para las variables de entrada tiene buenos resultados. Ademas, el
numero de recursos utilizados en el dispositivo con esta resolucion es moderado.
Tambien se puede apreciar que al incrementar el numero de bits en mas de 8, la
reduccion del error es mınimo en los calculos de la recuperacion 3D. Por lo tanto,
el numero de bits que se utiliza para la resolucion de las variables de entrada para
la recuperacion 3D a partir del Flujo Optico es de 8.
Una vez seleccionada la resolucion de las variables de entrada, se realizo la
recuperacion 3D variando el valor de las variables de entrada. La figura 4.27
muestra los valores de error RMSE obtenidos para la recuperaciones de 3D a
partir del Flujo Optico.
Figura 4.27: Valores de la medida de error RMSE obtenida para la recuperaciones3D con diferentes valores en las variables de entrada.
La grafica (Figura 4.27) confirma que el error en la recuperacion 3D a par-
tir del Flujo Optico es bajo, con respecto a la implementacion software, con el
numero de bits seleccionado para las variables de entrada. Ademas, para ciertos
valores de las variables el error es igual a cero, lo cual brinda un mejor desempeno.
La simulacion software para la recuperacion 3D a partir del Flujo Optico utili-
za variables en representacion punto flotante del tipo double de 64 bits. La imple-
mentacion hardware utiliza diferentes longitudes en las variables segun se requiera
101
en las etapas de pipeline del modulo calculo de profundidad. La longitud maxima
en los calculos en el modulo calculo de profundidad es de 26 bits y con una reso-
lucion en las variables de entrada de 8 bits. La arquitectura propuesta obtiene un
error RMSE promedio en la recuperacion 3D con respecto al software de 0.00105,
lo cual cumple con las restricciones de la arquitectura.
4.5. Rendimiento de la arquitectura.
El rendimiento de la arquitectura esta dado en funcion del numero de image-
nes procesadas por segundo, el numero de operaciones realizadas por segundo y
el numero de valores de profundidad calculados. A continuacion se muestra un
analisis cuantitativo de la arquitectura.
El rendimiento, tiempo de procesamiento de las imagenes por la arquitectura,
esta en funcion de la frecuencia maxima de operacion. Esta se establece en fun-
cion de los retardos de la logica combinacional, la forma en que la senal de reloj
es distribuida y del ruteo interno del dispositivo.
Como se mostro en la seccion 4.3.3, la frecuencia maxima de operacion de la
arquitectura implementada es de 66 MHz, lo cual permite procesar 16 cuadros por
segundo, operando con imagenes de 640 × 480 pixeles. La arquitectura tiene la
capacidad de calcular 4, 915, 200 valores de profundidad por segundo con un error
promedio de 0.00105.
Una vez conocido el numero de imagenes por segundo que procesa el diseno,
se puede calcular el numero de operaciones por segundo (OPS) que realiza el
diseno. El numero de OPS se obtiene multiplicando el numero de fps, el numero de
operaciones por ventana de busqueda y el numero total de ventanas de busqueda
en la imagen.
OPSSAD = fps(#operacionesVb)(Imghor − m + 1)(Imgver − m + 1)
OPSSAD = 16(3 ∗ 16 ∗ 25)(640 − 8 + 1)(480 − 8 + 1) = 5,748 × 109
(4.4)
102
Para la recuperacion 3D a partir del Flujo Optico el numero de operaciones
se obtiene multiplicando el numero de cuadros por segundo, el numero de ope-
raciones para calcular un solo valor de profundidad y el numero de vectores de
movimiento calculados por imagen. La ecuacion 4.5 obtiene el numero de opera-
ciones realizadas para la recuperacion 3D a partir del Flujo Optico.
OPSZ = fps(#operacionesZ)(Imghor − m + 1)(Imgver − m + 1)
OPSZ = 16(32)(640 − 8 + 1)(480 − 8 + 1) = 153,297 × 106(4.5)
La arquitectura realiza 5,748 millones de OPS en representacion entera, para
el Flujo Optico y 153 millones de OPS en representacion punto fijo para la re-
cuperacion 3D a partir del Flujo Optico. Por lo tanto, la arquitectura realiza un
numero total de 5,901 millones de OPS durante el proceso de la recuperacion 3D
a partir del Flujo Optico.
4.6. Discusion de resultados.
En la seccion 4.4.1 se puede ver que no existe degradacion de los resultados
para calculo del Flujo Optico a nivel hardware. Esto es debido a que no se efectua
ningun truncamiento de bits durante los calculos, por lo que es posible obtener
los mismos resultados que a nivel de software. Para la recuperacion 3D se tiene
un error con respecto al software, debido a que se trabaja con aritmetica de punto
fijo, restandole precision a los calculos.
El error la recuperacion 3D a partir del Flujo Optico es aceptable si se consi-
dera que la arquitectura se enfoca en tareas de navegacion. En el caso de imagenes
reales, donde la suposicion base de los algoritmos de correlacion no se cumple, se
muestra una alternativa para que este problema afecte de manera mınima la recu-
peracion 3D a partir del Flujo Optico.
En la seccion anterior, se presento el rendimiento de la arquitectura en tiem-
po de procesamiento, donde se indica que la arquitectura es capaz de procesar 16
cuadros por segundo con resolucion VGA. La carga computacional para realizar
103
el procesamiento es de alrededor de 6 mil millones de OPS, lo cual es difıcil de
realizar en un tiempo corto (orden de milisegundos) en los procesadores secuen-
ciales actuales.
La arquitectura disenada cumple con las especificaciones planteadas en las
seccion 3.1 y los objetivos del capıtulo 1. La arquitectura procesa imagenes de
con resolucion 640×480 pixeles en escala de 256 tonos de grises. La arquitectura
procesa 16 cuadros por segundo, superando en 3.2 veces el objetivo inicial, y solo
se hace un acceso a memoria por cada pixel de las imagenes. El error de la recu-
peracion 3D a partir del Flujo Optico es bajo (0.001), en base al numero de bits
usados en la arquitectura y al numero de recursos utilizados en el dispositivo. Por
ultimo, la arquitectura puede operar por si sola como un sistema digital o como
un modulo dentro de un sistema digital mas complejo.
Capıtulo 5
Conclusiones y trabajo futuro.
En este capıtulo se detallan las conclusiones que se obtuvieron despues de
realizar este trabajo de tesis. Igualmente son detallados los trabajos futuros que
pueden ser estudiados para lograr una mayor confiabilidad en la recuperacion de
la profundidad de la escena.
El capıtulo esta dividido en dos secciones. La primera presenta las conclu-
siones del presente trabajo mientras que la segunda seccion detalla los trabajos
futuros.
104
105
5.1. Conclusiones.
El presente trabajo ha presentado un procesador paralelo para la recuperacion
3D a partir del Flujo Optico dentro de una secuencia de video bajo restricciones de
tiempo predecible. Ademas, el diseno presenta un balance entre area y velocidad.
La arquitectura disenada utiliza un adecuado direccionamiento de los datos,
permitiendo de esta forma utilizar el inherente paralelismo de los datos y dismi-
nuyendo el numero de accesos a memoria, solo un acceso a memoria por cada
pixel. La unidad principal de procesamiento esta basada en un arreglo de 20 ele-
mentos procesadores (PE) agrupadas en un modulo. El diseno final para el calculo
del Flujo Optico esta formado por 5 modulos y cuenta con 100 bloques PE fun-
cionando en paralelo.
La arquitectura se puede escalar para procesar un numero mayor de venta-
nas de busqueda en paralelo y se puede parametrizar en el numero de bloques
PE utilizados para el procesamiento. La parametrizacion de la arquitectura se ha-
ce mediante la modificacion del control y anadiendo mas modulos de calculo de
Flujo Optico. El control se puede modificar facilmente al no ser una FSM muy
compleja, y por el reducido numero de senales que manejan. En el caso de querer
reducir el numero de ciclos de latencia entre cada par de vectores de movimiento
calculados se pueden traslapar varios modulos con 20 bloques PE, el traslape de
los modulos se puede hacer de manera horizontal, vertical o en ambas direccio-
nes. En el caso de traslape horizontal se reduce el tiempo de procesamiento para
procesar el numero de pixeles por renglon. En el traslape vertical, la latencia del
calculo de los vectores de movimiento se mantiene pero ofrece la ventaja de ob-
tener varios vectores en paralelo. En el caso de los traslapes en direccion vertical
y horizontal, se reduce el tiempo total de procesamiento de la imagen. Esto es a
debido a que se reduce el tiempo de procesamiento de cada renglon de la ventana
de busqueda y, en el mismo instante, se obtienen varios vectores de movimiento.
Es posible escalar la arquitectura propuesta pero siempre es necesario considerar
el balance area/velocidad, importante en una implementacion hardware.
El diseno del modulo calculo de profundidad en pipeline afecta de manera
mınima el desempeno de la arquitectura propuesta. El arreglo de pipeline pro-
106
puesto opera de manera idonea debido a que termina su procesamiento antes de
que los siguientes vectores de movimiento sean suministrados. Por consecuencia
se puede escalar el modulo de Flujo Optico sin modificar el modulo de la recupe-
racion 3D.
La aritmetica de punto fijo utilizada en la recuperacion 3D ofrece buenos resul-
tados. En el analisis se muestra un error bajo en los calculos sin hacer un excesivo
uso de recursos hardware.
Es importante mencionar que la tecnica de correlacion empleada para este tra-
bajo opera bajo la suposicion de que las intensidades de los pixeles se mantienen
constantes a lo largo de la secuencia de video, por lo que la arquitectura disenada
es susceptible a cambios de iluminacion, y detectar movimiento donde no existe,
pudiendo calcular una recuperacion 3D erronea. Se presento una forma de enfren-
tar el problema sin modificar la arquitectura.
La implementacion cumple con el requerimiento de obtener la recuperacion
3D a partir del Flujo Optico en secuencias de imagenes de resolucion VGA en
tiempo predecible, ya que es capaz de procesar 16 fps. Dado que la arquitectura
hardware es un diseno compacto es posible implementarla en sistemas donde el
tamano y el consumo de potencia son importantes restricciones, como es el caso
de sistemas de vision moviles y vision robotica.
5.2. Trabajo futuro.
Teniendo como base los resultados y las conclusiones obtenidas a lo largo
del desarrollo del presente trabajo se sugieren como trabajo futuro los siguientes
puntos:
Realizar pruebas y analizar resultados con diferentes tamanos de ventanas
de busqueda y de referencia, con el fin de darle mayor confiabilidad al sis-
tema, sobre todo en imagenes donde no se conserva la intensidad de los
pixeles.
Analisis para la implementacion de otros algoritmos de Flujo Optico utili-
zando los modulos basicos con los que se cuenta. Esto implica hacer cam-
107
bios mınimos y poco incremento en la complejidad de las unidades de pro-
cesamiento, manteniendose el direccionamiento y el control de los datos en
la arquitectura propuesta.
Realizar pruebas con un sensor de imagen con el fin de obtener un flujo
continuo de imagenes y analizar los resultados de la reconstruccion 3D.
Estudiar algoritmos predictivos y su implementacion hardware, para lograr
una mejor estimacion en la recuperacion 3D.
Apendice A
Hoja de Datos de la Arquitectura.
La arquitectura propuesta tiene como proposito la Recuperacion 3D a partir
del Flujo Optico encontrado en una secuencia de video. La arquitectura posee
una maxima reutilizacion de datos y una optimizacion en el uso de recursos. La
implementacion es capaz de procesar 16 fps.
Caracterısticas Principales.
Modulo para la recuperacion 3D a partir del Flujo Optico.
Procesamiento para imagenes en escala de grises de 8 bits (256 tonos).
Resolucion de imagenes de 640 x 480 pıxeles.
Tiempo de procesamiento de 62.5 ms.
Recuperacion 3D densa a partir de 2 imagenes.
Descripcion Funcional.
El funcionamiento general del diseno es el siguiente: la arquitectura toma los
datos referentes a los pixels de las dos imagenes consecutivas dentro de la secuen-
cia de video a traves de un bus de datos de 32 bits. Posteriormente se efectua el
proceso del calculo de Flujo Optico donde se obtienen los vectores de movimien-
to. Los vectores de movimiento se proporcionan al proceso para la recuperacion
3D. Por ultimo, los valores obtenidos de la recuperacion 3D se proporcionan al
108
109
mundo real, memorias externas u otro proceso, mediante un bus de datos de sali-
da. La direcciones de escritura y de lectura son generadas por modulos ruteadores
que se encargan de llevar el control de flujo de datos. Las senales que coordinan
el funcionamiento de la arquitectura estan dispuestas en un bus y son procesadas
por un modulo de control.
Descripcion de Terminales.
El diagrama del modulo con las senales de entrada y salida se muestra en la
figura A.1.
Figura A.1: Diagrama del modulo para la recuperacion 3D.
La tabla A.1 presenta las senales del modulo con una breve descripcion fun-
cional.
Caracterısticas de Rendimiento.
Los valores en la tabla A.2 muestran la frecuencia maxima de operacion del
modulo y otros parametros de rendimiento. Diferentes resultados pueden ser ob-
tenidos usando las opciones de sıntesis (area/velocidad).
110
Tabla A.1: Descripcion de pines del modulo para la recuperacion 3D.Pin Tipo Ancho Descripcion
(bits)
CLK E 1 Senal de reloj del modulo, activa en flanco positivoRST E 1 Reset asıncrono del modulo, activo en bajo.A, B, C,U, V yW
E 8 Parametros de entrada para la descripcion del movi-miento de la camara.
DIN E 32 Dato de entrada de la memoria, representa los pixelesde las imagenes a procesar. Por cada dato de entradase tienen 4 pixeles.
DOUT 36 S Representa el resultado de la recuperacion 3D, por ca-da data de salida se tienen 4 valores de profundidad.
ADDR 17 S Direccion de la memoria. Direccion del pıxel de en-trada o valor de profundidad de salida.
RDY 1 S Senal de finalizacion de los procesos.WE/RD 1 S Senal para la lectura o escritura de datos en la memo-
ria externa. Para lectura WE/RD=0 y para escrituraWE/RD=1.
FST 1 S Senal que indica cuando se terminaron de procesarcada par de imagenes.
Tabla A.2: Caracterısticas de rendimiento.Caracterıstica Rendimiento
Dispositivo Virtex-4Frecuencia Maxima de operacion 66 MHz
Imagenes por segundo 16OPS 5,901 millones de OPS
Modo de Operacion.
El modulo esta controlado por la senal RST. Cuando la senal RST esta activa
(RST=1) el modulo no realiza ningun tipo de procesamiento, si la senal se desac-
tiva, RST=0, el modulo realiza el proceso para la recuperacion 3D. Como primer
paso, el modulo efectua la lectura de 1920 datos de 32 bits correspondientes a 4
renglones de la imagen actual y 8 de la imagen previa (DIN). La finalizacion de
este proceso se notifica mediante la activacion de la senal RDY. Posteriormente, se
realiza el calculo de la recuperacion 3D. Para el calculo de cada valor de profundi-
dad son necesarios 8 ciclos de reloj. Cada que se obtiene un valor de profundidad
111
(DOUT) se activa la senal RDY y se actualizan las direcciones para la lectura y
escritura de datos. Mediante la senal WE/RD se lleva el control para almacenar
los resultados de la recuperacion 3D y para leer los datos de los pixeles de las
imagenes. Despues que se obtiene un valor de profundidad se leen dos pixeles de
la imagenes. La senal FST indica cuando se termino de procesar el par de image-
nes. Los diagramas de tiempo para los procesos se muestran en las figura A.2
A.3.
Figura A.2: Diagrama de tiempo del funcionamiento del modulo para el procesode lectura.
Figura A.3: Diagrama de tiempo del funcionamiento del modulo para el procesode recuperacion 3D.
112
Uso de Recursos.
La tabla A.3 muestra la estadıstica de consumo de recursos utilizados para la
implementacion del modulo en un dispositivo Virtex-IV XC4VFX12. Los resul-
tados fueron obtenidos median ISE Project Navigator.
Tabla A.3: Resultados de sıntesis de la ArquitecturaRecurso Utilizacion %
FFs: 1,277 11 %LUTs: 6,024 55 %Slices: 4,739 86 %
BlockRams : 12 33 %
Indice de figuras
1.1. Metodologıa de desarrollo. . . . . . . . . . . . . . . . . . . . . . 5
2.1. Esquema del algoritmo basado en correlacion [12]. . . . . . . . . 11
2.2. Problema de apertura. En la secuencia de imagenes se observa el
problema de calcular de manera correcta la direccion de la veloci-
dad de la barra. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Problema de oclusion. En la secuencia se descubre una region en
el instante t + 1, ninguna otra region en el instante t correspon-
dera con la nueva region. . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Movimiento de la fuente de iluminacion externa ante un objeto sin
movimiento [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Movimiento de un objeto sin textura provoca un Flujo Optico
igual a cero [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Falsas correspondencias debido a la semejanza entre regiones . . . 14
2.7. Funcionamiento base de los algoritmos basados en correlacion [17]. 16
2.8. Sistema coordenado de referencia. . . . . . . . . . . . . . . . . . 20
3.1. Funcionamiento general de la arquitectura propuesta. . . . . . . . 35
3.2. Diagrama general a bloques de la arquitectura. . . . . . . . . . . . 35
3.3. Proceso de estimacion de movimiento. . . . . . . . . . . . . . . . 38
3.4. Diagrama del Elemento Procesador (PE), bloque base de la arqui-
tectura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5. Primera aproximacion para el modulo calculo de Flujo Optico con
4 bloques PE trabajando en paralelo. . . . . . . . . . . . . . . . . 40
3.6. Procesamiento de la ventana de referencia dentro de la ventana de
busqueda para el arreglo de 4 bloques PE. En cada ciclo de reloj
se realiza el procesamiento de 4 pixeles en paralelo . . . . . . . . 41
113
114
3.7. Segunda aproximacion del modulo calculo de Flujo Optico. Fun-
ciona con 20 bloques PE . . . . . . . . . . . . . . . . . . . . . . . 42
3.8. Procesamiento de la ventana de referencia dentro de la ventana de
busqueda para el arreglo de 20 bloques PE. . . . . . . . . . . . . 43
3.9. Diagrama del modulo calculo de Flujo Optico, opera con 100 blo-
ques PE en paralelo. . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.10. Procesamiento de la ventana de referencia dentro de la ventana de
busqueda para el arreglo de 100 bloques PE. . . . . . . . . . . . . 45
3.11. Diagrama final del modulo calculo de Flujo Optico. . . . . . . . . 46
3.12. Graficas de rendimiento del modulo calculo de Flujo Optico. . . . 47
3.13. Sistema coordenado de referencia. . . . . . . . . . . . . . . . . . 48
3.14. Modulo calculo de profundidad. . . . . . . . . . . . . . . . . . . 53
3.15. Calculo de profundidad en las diferentes etapas de pipeline. . . . . 54
3.16. Almacenamiento de datos en los modelos software y hardware. . . 55
3.17. Forma de almacenamiento de datos en la memoria RAM. . . . . . 56
3.18. Mapa de la memoria RAM utilizada. . . . . . . . . . . . . . . . . 56
3.19. Diagrama del modulo Ruteador del Lectura . . . . . . . . . . . . 57
3.20. Componentes del bloque Ruteador de Lectura. . . . . . . . . . . 57
3.21. Estructura interna del bloque Buffer VB de almacenamiento. . . . 58
3.22. Estructura interna del Buffer BR de almacenamiento. . . . . . . . 59
3.23. Diagrama del modulo Ruteador de Escritura. . . . . . . . . . . . 59
3.24. Componentes del modulo Ruteador de Escritura. . . . . . . . . . 60
3.25. Diagrama del modulo Control. . . . . . . . . . . . . . . . . . . . 60
3.26. Maquina de Estados Finitos para el modulo de Control. . . . . . . 62
3.27. Arquitectura propuesta para la recuperacion 3D a partir del Flujo
Optico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.28. Diagrama de funcionamiento de la arquitectura. . . . . . . . . . . 64
3.29. Rendimiento comparado contra recursos hardware [41]. . . . . . 68
3.30. Funcionamiento de la arquitectura propuesta, se procesa una ven-
tana de busqueda cada 8 ciclos de reloj. . . . . . . . . . . . . . . 69
3.31. Funcionamiento de la arquitectura escalandola con 4 modulos de
calculo de Flujo Optico. . . . . . . . . . . . . . . . . . . . . . . 70
3.32. Traslape entre las ventanas de busqueda en la posiciones 1 y 5. . . 71
3.33. Procesamiento realizado con 2 modulos calculo de Flujo Optico. . 72
115
4.1. Metodologıa de prueba de la arquitectura. . . . . . . . . . . . . . 77
4.2. Resultados obtenidos del Flujo Optico a partir de la secuencia La-
ta (1). La secuencia simula un movimiento de traslacion de un
pixel por imagen a traves del eje X . . . . . . . . . . . . . . . . . 79
4.3. Resultados obtenidos para el Flujo Optico a partir de la secuencia
Lata (1). La secuencia simula un movimiento de traslacion de un
pixel por imagen a traves del eje Y . . . . . . . . . . . . . . . . . 80
4.4. Resultados obtenidos para el Flujo Optico a partir de la secuencia
Lata (1). La secuencia simula un movimiento de traslacion de un
pixel por imagen combinado a traves del eje X y del eje Y . . . . . 81
4.5. Resultados obtenidos de Flujo Optico a partir de la secuencia Cu-
bo(2). En la secuencia el cubo y la esfera presentan movimiento.
El cubo presenta un movimiento de traslacion combinado a traves
del eje X y del eje Y , en tanto que la esfera presenta un movi-
miento de rotacion sobre su propio eje. . . . . . . . . . . . . . . . 82
4.6. Resultados obtenidos de Flujo Optico a partir de la secuencia Ca-
rro(3). En la secuencia el carro y el satelite muestran movimiento.
El cubo muestra un movimiento de traslacion a traves del eje X ,
en tanto que el satelite presenta un movimiento de acercamiento. . 83
4.7. Resultados obtenidos para el Flujo Optico a partir de la secuencia
Calle(4). En la secuencia el carro, satelite y la calle presentan mo-
vimiento. El carro presenta un movimiento de traslacion a traves
del eje X , el satelite presenta un movimiento de traslacion en el
eje X y la calle presenta un movimiento de rotacion sobre su pro-
pio eje con respecto a la camara. . . . . . . . . . . . . . . . . . . 84
4.8. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico calculado de la secuencia Lata(1) para un par de imagenes. 85
4.9. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico calculado de la secuencia Lata(1) para un par de imagenes. 86
4.10. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico calculado de la secuencia Lata(1) para un par de imagenes. 87
4.11. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico calculado de la secuencia Lata(1) para un par de imagenes.
La resolucion es de 640 x 480 pixeles en las imagenes . . . . . . . 88
116
4.12. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata(1), iteracion 7. . . . . . . . . . . . . 89
4.13. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata(1), iteracion 14. . . . . . . . . . . . . 89
4.14. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata(1), iteracion 21. . . . . . . . . . . . . 90
4.15. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata(1), iteracion 28. . . . . . . . . . . . . 90
4.16. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata Pepsi(5), iteracion 1. . . . . . . . . . 91
4.17. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata Pepsi(5), iteracion 3. . . . . . . . . . 91
4.18. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata Pepsi(5), iteracion 6. . . . . . . . . . 92
4.19. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Lata Pepsi(5), iteracion 9. . . . . . . . . . 92
4.20. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Jardın(6), iteracion 1. . . . . . . . . . . . . 93
4.21. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Jardın(6), iteracion 5. . . . . . . . . . . . . 93
4.22. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Jardın(6), iteracion 10. . . . . . . . . . . . 94
4.23. Resultados obtenidos para la recuperacion 3D a partir del Flujo
Optico de la secuencia Jardın(6), iteracion 15. . . . . . . . . . . . 94
4.24. Error promedio en funcion de la resolucion utilizada en las varia-
bles de entrada A, B, C, U , V y W . . . . . . . . . . . . . . . . . 98
4.25. Error RMSE de la recuperacion 3D en funcion de la resolucion de
las variables de entrada A, B, C, U , V y W . . . . . . . . . . . . . 99
4.26. Numero de LUTs utilizadas en el dispositivo en funcion de la re-
solucion de las variables de entrada A, B, C, U , V y W . . . . . . 99
4.27. Valores de la medida de error RMSE obtenida para la recupera-
ciones 3D con diferentes valores en las variables de entrada. . . . 100
A.1. Diagrama del modulo para la recuperacion 3D. . . . . . . . . . . 109
117
A.2. Diagrama de tiempo del funcionamiento del modulo para el pro-
ceso de lectura. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.3. Diagrama de tiempo del funcionamiento del modulo para el pro-
ceso de recuperacion 3D. . . . . . . . . . . . . . . . . . . . . . . 111
Indice de tablas
2.1. Trabajos relacionados. . . . . . . . . . . . . . . . . . . . . . . . 28
3.1. Primera etapa de pipeline. . . . . . . . . . . . . . . . . . . . . . . 49
3.2. Segunda etapa de pipeline. . . . . . . . . . . . . . . . . . . . . . 50
3.3. Tercera etapa de pipeline. . . . . . . . . . . . . . . . . . . . . . . 51
3.4. Cuarta etapa de pipeline. . . . . . . . . . . . . . . . . . . . . . . 51
3.5. Quinta etapa de pipeline. . . . . . . . . . . . . . . . . . . . . . . 52
3.6. Descripcion de pines del modulo Control. . . . . . . . . . . . . . 61
4.1. Secuencias utilizadas en las pruebas de la arquitectura . . . . . . . 78
4.2. Resultados de sıntesis para el modulo calculo de Flujo Optico. . . 95
4.3. Resultados de sıntesis para el modulo calculo de profundidad. . . 95
4.4. Resultados de sıntesis de la arquitectura completa. . . . . . . . . . 96
4.5. Porcentaje de consumo de recursos del dispositivo FPGA por los
modulos de la arquitectura propuesta. . . . . . . . . . . . . . . . 96
A.1. Descripcion de pines del modulo para la recuperacion 3D. . . . . 110
A.2. Caracterısticas de rendimiento. . . . . . . . . . . . . . . . . . . . 110
A.3. Resultados de sıntesis de la Arquitectura . . . . . . . . . . . . . . 112
118
Bibliografıa
[1] R. Koch and L. V. Gool, 3D Structure from Multiple Images of Large-Scale,
Springer-Verlag (European workshop SMILE’98), vol: 1506, 1998
[2] G. P. Martisanz y J. M. de la Cruz Garcıa, Vision por Computador: Imagenes
digitales y aplicaciones, Ra-Ma, 2001.
[3] V. H. Rosales Hernadez, Recuperacion 3D de la estructura de una escena a
partir del Flujo Optico, Tesis de Maestrıa, INAOE, 2003.
[4] A. Singh, Optical Flow Computation: A unified Perspective, IEEE Computer
Society Press, 1991.
[5] D. J. Fleet and Y. Weiss, Optical Flow estimation, Mathematical models for
computer vision: The Hadbook. N. Patagios, Y. Chen, and O. Faugeras (eds.),
Springer, 2005.
[6] H. G. Nguyen, Obtaining Range from Visual Motion Using Local Image Deri-
vatives, Technical Document 2918, NCCOSC RDT&E Division, San Diego,
1996.
[7] A. Burton and J. Radford, Thinking in Perspective: Critical Essays in the
Study of Thought Processes, Routledge,1978.
[8] David H. Warren and E. Strelow, Electronic Spatial Sensing for the Blind:
Contributions from Perception. , The Hague: Martinus Nijhoff, 1985.
[9] B. K. P. Horn and B. G. Shunk, Determining Optical Flow, Artificial Intelli-
gence Laboraory MIT, pp .185-203, 1981.
[10] K. Joy, C. Grant, N. Max, and L. Hatfield., Computer Graphics: Image Synt-
hesis, volume 19. Computer Society Press, Washington, 1985.
119
120
[11] J. L. Barron, D. J. Fleet and S. S. Beauchemin Performance of Optical Flow
Techniques., IJCV 12:1, pp. 43-77 , 1994.
[12] A. Hernadez Camarillo, Recuperacion en Tiempo Real del Flujo Optico de
una Secuencia de Video usando una arquitectura FPGA, Tesis de Maestrıa,
INAOE, 2007.
[13] B. Galvin, B. MaCane, et al., Recovering Motion Fields. An Evaluation
of Eight Optical Flow Algorithms, Proc. Briths Machine Vision Conference
BMVC98, 1998.
[14] R. Molina, Campo de movimiento en el plano de la imagen: Flujo Optico y
correspondencia, Departamento de Ciencias de la Computacion e I. A., Uni-
versidad de Granada, 2007.
[15] A. de la Escalera, Vision por Computador Fundamentos y Metodos, Prentice
Hall, 2001.
[16] S. E. Maya, C. Torres and M. Arias, A Real-time FPGA-based Architec-
ture for Optical Flow Computation, Lecture Notes in Computer, Science,
Springer-Verlag GmbH, Vol 2778/2003, 2003.
[17] P. Kunh, Algorithms, Complexity Analysis and VLSI Architectura for MPEG-
4 Motion Estimation, Kluwer Academic Publishers, 1999.
[18] R. Romero, Electronica Digital y Logica Programable, Universidad de Gua-
najuato Ed., 2008.
[19] Xilinx, Xilins: products and services, http://www.xilinx.com, 2008.
[20] B. Pudipeddi, A Configurable Computing Approach Towards Real-Time, Tar-
get Tracking, International Parallel and Distributed Processing Symposium.
2002.
[21] M. A. Nuno Maganda, Una Arquitectura FPGA para el Seguimiento de Ob-
jetos utilizando Procesamiento Piramidal, Tesis de Maestrıa, INAOE, 2003.
[22] A. R. Bruss and B. K. P. Horn, Passive Navigation, Artificial Intelligence
Laboratory, Massachusets Institute of Technology, 1981.
121
[23] J. W. Banch and G.Olague, La Vision por Computador una aproximacion al
Estado del Arte, DYNA, vol: 133, Universidad Nacional de Colombia, 2001.
[24] J. M. WaltonTerrain Mapping from a Mobile Platform Through Optical Flow
Techniques. Thesis for master grade, MIT, 1995.
[25] M. V. Correia and A. C. Campilho, Real-time Implementation of an Optical
Flow Algorithm, ICPR,vol: 4, pp. 40247, 2002.
[26] J. Dıaz, E. Rios, et al., Real-Time Optical Flow Processing System, Unive-
risdad de Granada, Espana, 2003.
[27] W. S. Fife and J. K. Archibald., Reconfigurable On-Board Vision Processing
for Small Autonomos Vehicles, Eurasip Journal, Vol. 2007, Hindawi Publis-
hing Copr., pp. 1103-1006, 2007.
[28] G. Sosa and M. Arias, 3D recovery with Free Hand Camara Motion,
ENC’05, pp. 145- 151, 2005.
[29] C. Yuan, G. Medoni, 3D Reconstruction of Background and Objects Moving
on Ground Plane Viewed from a Moving Camera, Institute of Robotics and
intelligent Systems, University of Southern California, CVPR’06, pp. 2261 -
2268 ,2006.
[30] C. Dıaz, L. Lopez, M. Arias, C. Feregrino y R. Cumplido, Implementacion
FPGA del calculo de profundidades en la recuperacion 3D usando luz estruc-
turada, ENC’03, 2003.
[31] C. Zach, A. Klaus, B. Reitinger and K. Karner, Optimized Stereo Reconstruc-
tion Using 3D Graphics Hardware, VRV research center, Graz and Vienna,
pp. 119-126, 2003.
[32] D. Viejo and M. Carzola, Construccion de mapas 3D y extraccion de pri-
mitivas geometricas del entorno, Depto Ciencias de la Computacion e I.A.,
Universidada de Alicante, Reporte tecnico, 2004.
[33] D. Nister, Automatic Passive Recovery of 3D from Images and Video,
3DPVT’04, pp. 438 - 445, 2004.
122
[34] RG, Handel-C Language Reference Manual, www.celoxica.com/support/,
2005.
[35] Agility, Software product description for DK Desing suite version 5.0 ,
www.agilityds.com, 2008.
[36] Electronic Industries Alliance, About EDIF, www.edif.org, 2005.
[37] Xilinx, ML403 Evaluation Platform, User Guide, www.xilinx.com, 2006.
[38] Matlab, MATLAB - The Language of Technical Computing,
http://www.mathworks.com/products/matlab/, 2008.
[39] http://of-eval.sourceforge.net/, Computer Vision Research Group Depart-
ment of Computer Science, University of Otago, New Zealand, 2007.
[40] B. McCane, K. Novins, D. Crannitch and B. Galvin, On Benchmarking Opti-
cal Flow, Computer Vision and Image Understanding 84, pp. 126-143, 2001.
[41] F. J. Banos., Guıas, principios y tecnicas para escribir aplicaciones escala-
bles con Microsoft .NET, http://dixi.members.winisp.net/, 2006.
[42] M. Barr, A Reconfigurable Computing Primer, Multimedia Systems Design,
pp. 44-47. 1998.