Final
43
Facultad de Ingeniería, Universidad de la Republica
-
Upload
pablo-chiesa -
Category
Documents
-
view
429 -
download
0
Transcript of Final
Facultad de Ingeniería, Universidad de la Republica
Cual es el problema a resolver?•Alta competencia del deporte y del futbol moderno.
•Mercado que mueve millones de dólares.
•Exponencial uso de la tecnología.
Surge la necesidad de obtener información objetiva sobre el rendimiento de un
equipo o jugadores.
Como se pude lograr?
•La idea es medir y cuantificar eventos.
La técnica utilizada para obtener algunos de estos datos, es utilizar un conjunto de cámaras fijas instaladas en el estadio.
Soluciones comerciales existentes
Objetivos:
•Crear un prototipo software que prueba la viabilidad técnica de una solución en el dominio de interés.
•Generar un conjunto de datos de prueba propio, con el apoyo económico de la Fundación Ricaldoni.
•Obtener una estimación del grado de incertidumbre del resultado obtenido.
Procesamiento por cámara
La entrada es el video que
llega de la cámara, la
salida es un conjunto de
datos que describen la
posición y categoría de
cada uno de los objetos
detectados.
Jugadores, goleros, jueces
Procesamiento unificado
La entrada es el conjunto
de datos de la primera
etapa, la salida es otro
conjunto de datos que
describen la posición y
categoría de los objetos
en un modelo único del
campo de juego.
Software. Características
•Diseño modular, que hace fuerte uso de los patrones de diseño : Singleton y Strategy
•Cada Modulo resuelve un problema particular y colabora para obtener la solución global.
•Utilizando Singleton, logramos que la única instancia de cada Modulo sea fácilmente accesible y además que tenga bajo acoplamiento.
•Utilizando Strategy, pudimos intercambiar, distintas versiones de un mismo algoritmo durante las pruebas al sistema.
Software. Características
•El prototipo se implemento utilizando Matlab R2009b .
•Java jdk1.6.0_12 , IDE Eclipse para la comunicación con la API de VIPER GT.
Componentes de la primera etapa
Componentes de la segunda etapa
Conjunto de datos de prueba ISSIA DATASET• 6 cámaras• Calibración, puntos en
el piso• Datos Ground Truth
SCEPTRE DATASET• 8 cámaras• Calibración,
constantes TSAI
Datos obtenidos por el grupo PARQUE CENTRAL• 1 cámara
MÉNDEZ PIANA• 4 cámaras
FRANZINI DATASET• 4 cámaras• Calibración, puntos de
la cancha
PROBLEMAS:
• Sombras• Ubicación de las cámaras • Sincronización de las cámaras• Configuración de las cámaras
Datos obtenidos por el grupo
18 /11/2010: Partido amistoso Uruguay-Argentina sub 17 , Parque Central
126/03/2011: Estadio Luis Franzini
Datos obtenidos por el grupo
Generación de datos de Ground Truth con VIPER GT
Modelado del fondo Método: Mixture of
Gaussians
Distinguir entre puntos estáticos y en movimiento (los valores bajos de energía son utilizados para construir el fondo mientras que los altos se descartan por la probabilidad de pertenecer a objetos móviles).
Procesamiento multicamaraCada cámara arroja: estimación + incertidumbre sobre la posición y categoría de cada “Target”.
Se busca “combinar” de manera adecuada cada una de las medidas, para incrementar la precisión global del sistema.
El resultado es enviado a un proceso que utiliza la restricción de cantidad de elementos por categoría para condicionar la salida del sistema. (este dato viene de una fuente externa al sistema)
Procesamiento multicamaraNuevamente se utiliza el fitro de Kalman, pero ahora en el plano de la cancha.
Tyxyxx ''
Tyxz
Vector de estados, posición y velocidad sobre el plano de la cancha:
Observaciones:
1000
0100
010
001
T
T
Aw
0010
0001wH
Procesamiento multicamaraSe construye una matriz de asociación (binaria) para cada cámaras: Targets X Observaciones
10
00
01
10
00
01
10
00
01
10
00
01
1 indica una asociación entre el Target y la observación.
0 no hay asociación.
Se calcula utilizando la mínima distancia de Mahalanobis y el algoritmo del vecino mas cercano
Procesamiento multicamara
Pero… nosotros conocemos el numero “correcto” de elementos que el sistema debe retornar.
Hasta aquí, seria la salida de una aplicación típica de seguimiento.
Podemos “condicionar” la salida global para usar esta información. => MAP
Procesamiento multicamara
Creación y muerte de los targets
Las observaciones que no son asociadas con ningún target activo, son potenciales nuevos targets.
Se utiliza el numero de cámaras esperado que “observan” el nuevo target para decidir y la “antigüedad” en cuadros.
La creación o muerte de Targers , una vez que el sistema llega al numero esperado, es un evento que no debe ocurrir con frecuencia.
Performance SingleView
A los videos de entrada, los etiquetamos manualmente mediante el ViperGT en sus posiciones y categorías correctas y lo comparamos con el XML salida del sistema utilizando ViperPE. La presentación de resultados se da mediante Presicion & Recall.
Precision & Recall
Algunos números….
ISSIA DATASET
La “Precision" es de 60/69 es decir un 86 %
esto se podrá interpretar como que de los 69 objetos a testear en el archivo xml de salida del sistema, se pudieron “matchear” o encontrar correspondientes a 60 de ellos con objetos en el archivo de GT.
El “Recall" es de 37/76, es decir que de los 76 objetos test registrados como
verdaderos en el archivo de GT solamente se asignaron 37 de ellos (es decir para 37 de esos objetos test se encontró correspondiente en el archivo xml de salida del sistema).
Para que mostrar un resultado intermedio ?
1) Necesidad de investigar como esta evolucionando la performance por cámara al modificar parámetros de diseño.
2) Comparar como afectan los esquemas de clasificación de categorías a los esquemas de localización espacial.
3) Tener una idea mas precisa sobre como mejora la performance final al integrar todas las cámaras, mediante la sencilla comparación de la performance intermedia y la final.
Esto nos demuestra que efectivamente tener varias cámaras distribuidas espacialmente de forma conveniente nos facilita la resolución del problema, pudiendo integrar información proveniente de varias cámaras y ponderando dicha información entre ellas para resolver los principales problemas (falsas detecciones, oclusiones mal resueltas, etc..) y así aumentar la performance final del problema propuesto.
Resultados de MultiviewHablar de los resultados de esta etapa es hablar del rendimiento del sistema en general.
La idea es:
Contar el numero de elementos detectados en cada categoría cuadro a cuadro y compararlo con el esperado.
El numero de objetos detectados en un buen indicador del rendimiento del sistema.
Resultados de Multiview3000 cuadros del dataset ISSIA
Cuadro1 12,8453Cuadro2 12,8225Abrbitros 2,2460Golero1 0,8977Golero2 1,1140
Resultados de MultiviewUn numero levemente superior al esperado en la cantidad de jugadores, se explica porque el sistema tiende a “continuar” los tracks.
Los líneas no son tomados por las cámaras.
En esta secuencia, uno de los arqueros es mal clasificado, dada su similitud con la camiseta de los jugadores de cancha.
Conclusiones
Se adquirió experiencia y conocimiento en las técnicas utilizadas, hasta llegar a dominarlas y poder integrar las soluciones parciales a la solución global.
El prototipo construido nos permitió probar que una solución al problema es técnicamente factible y realizable.
Creemos que el conocimiento adquirido en el área del problema, los obstáculos y problemas que tuvimos que sortear para llegar a este punto, son en definitiva, el real valor de proyecto
Que cosas identificamos como futuras mejoras a la solución ?
1) Flujos de datos:
Problema actual:
El principal problema es que el “parser" de los archivos XML no accede secuencialmente a la información, sino que carga en memoria todo el archivo. Esto se traduce en cientos de MB en memoria RAM !!!.
Posible solución:
La primera solución para este problema es sustituir el “parser" que utiliza VIPER por alguno que acceda secuencialmente a la información.
Otra solución mas comprometida, seria eliminar completamente el uso de archivos XML y utilizar una base de datos en la que la primera etapa inserte y la segunda etapa acceda a leer.
Que cosas identificamos como futuras mejoras a la solución ?
2) Movimiento de cámara y sombras:
Problema actual:
El principal problema con el movimiento de la cámara es la falsa detección de las líneas del campo de juego.Mientras que las sombras de los jugadores producen una mala segmentación (la sombra también se mueve ! )
Posible solución:
Crear un bloque del sistema que se encargue de la estabilización total del video y que elimine las sombras de los jugadores.
Que cosas identificamos como futuras mejoras a la solución ?
3) Otras mejoras identificadas a implementar:
3.1) tracking al balón .
3.2) clasificación de categorías SingleView mas inteligente ( no en todos los frames del video para un mismo objetivo)
3.3) Automatización en el proceso de modelado de fondo (extracción periódica y automática del Background)
3.4) Aspectos de arquitectura global que nos permitan acercarnos aun mas al limite de tiempo real.
Entre otros….
