FING-UDELAR 2011

1. Facultad de Ingeniería, Universidad de la Republica

2. 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.

3. 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.

4. Soluciones comerciales existentes

6. 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.

7. 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

9. 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.

11. 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.

12. 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.

13. Componentes de la primera etapa

14. Componentes de la segunda etapa

16. 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

17. Datos obtenidos por el grupo
 PARQUE CENTRAL PROBLEMAS:
• 1 cámara
• Sombras
• Ubicación de las cámaras
 MÉNDEZ PIANA • Sincronización de las
• 4 cámaras cámaras
• Configuración de las cámaras
 FRANZINI DATASET
• 4 cámaras
• Calibración, puntos de
la cancha

18. Datos obtenidos por el grupo
18 /11/2010: Partido amistoso Uruguay-Argentina sub 17 , Parque
Central

19. Datos obtenidos por el grupo
126/03/2011: Estadio Luis
Franzini

20. Generación de datos de Ground Truth
con VIPER GT

22. 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).

23. D r1
D c1
D c2
D r2
Rc, Cc

25. Procesamiento multicamara
Cada 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)

26. Procesamiento multicamara
Nuevamente se utiliza el fitro de Kalman, pero ahora
en el plano de la cancha.
x = [x y ']
T
Vector de estados, posición y velocidad
sobre el plano de la cancha: y x'
z = [x y]
Observaciones: T
1 0 T 0
0 1 0 T
Aw =   1 0 0 0
0 0 1 0 Hw =  
   0 1 0 0
0 0 0 1

27. Procesamiento multicamara
Se construye una matriz de asociación (binaria) para
cada cámaras: Targets X Observaciones
1 indica una asociación entre el
1  0
1  0 Target y la observación.
1  0
0 10 0
0  0 0 no hay asociación.
0  0
0 01 0
0  1
0  1
0  1
Se calcula utilizando la mínima distancia de
Mahalanobis y el algoritmo del vecino mas cercano

28. Procesamiento multicamara
Utilizando la matriz binaria, todas las observaciones
que aplican a un “Target” son combinadas, ponderando
por la inversa de la covarianza de cada medida.

29. Procesamiento multicamara
Hasta aquí, seria la salida de una aplicación típica de
seguimiento.
Pero… nosotros conocemos el numero “correcto” de
elementos que el sistema debe retornar.
Podemos “condicionar” la salida global para usar esta
información. => MAP

31. Procesamiento multicamara

32. 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.

34. 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.

35. Precision & Recall

36. 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).

37. 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.

38. Resultados de Multiview
Hablar 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.

39. Resultados de Multiview
3000 cuadros del dataset ISSIA
Cuadro1 12,8453
Cuadro2 12,8225
Abrbitros 2,2460
Golero1 0,8977
Golero2 1,1140

40. Resultados de Multiview
Un 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.

42. 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

44. 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.

45. 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.

46. 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….