Archivo

Archive for the ‘Librerías de Visión’ Category

Captura exclusiva del video por reacTIVision

Un problema que presenta reacTIVision respecto a ARToolKit, es que al acceder a la cámara desde su propio ejecutable (que se comunicará con nuestra aplicación por medio de un socket) un segundo proceso (nuestra aplicación) no tendría acceso, en principio, a la imagen original por ya estar siendo consumida.

Poder utilizarla podría ser interesante por ejemplo para agregarla a la salida visual de nuestra aplicación, dibujando la interfaz de usuario “aumentada” sobre la imagen capturada original, en caso de no estar usando un proyector. Utilizando ARToolKit esto no es un problema, dado que la herramienta se presenta en forma de una librería cuya funcionalidad se accederá (básicamente) invocando a una función que recibe un frame de imagen como parámetro y devuelve la información sobre la ubicación de los fiducials. En este escenario, la imagen puede utilizarse posteriormente como se quiera.

Por esto, antes de continuar quisimos estudiar la factibilidad de poder acceder a esta imagen también desde nuestra aplicación. Investigando un poco, encontramos software como SplitCam para Windows, que crea una segunda cámara virtual con la misma imagen que captura la original. Si bien podríamos buscar aplicaciones similares para las otras plataformas que intentaremos soportar (Mac OSX, Linux) preferimos encontrar una solución que sea en cierta medida independiente de la plataforma.

Para esto, estudiamos los fuentes del reacTIVision y encontramos el lugar donde la imagen es obtenida de la cámara y comenzada a procesar. La idea sería entonces tomar esa imágen antes de continuar el procesamiento y hacérsela llegar una aplicación externa.

La primer idea fue enviar el frame de video a una aplicación de ejemplo en openFrameworks utilizando OSC, ya que este será el protocolo de comunicación utilizado por los distintos módulos de nuestra aplicación. Para eso, se extendió el addon ofxOSC de openFrameworks para soportar el tipo de datos blob y poder enviar información binaria. Debido a la restricción de tamaño de los paquetes UDP (protocolo sobre el que se implementa OSC en ofxOSC), fue necesario dividir cada frame en una serie de mensajes de OSC enviados por separado, uno para cada línea horizontal de imagen.

El resultado de esta implementación no fue positivo: un gran porcentaje de los paquetes se perdían y los frames llegaban a la aplicación con una velocidad mucho menor (unos 10fps) a la que se generaban:

Fue ahí que hicimos el siguiente cálculo: estábamos intentando enviar 640 * 480 (resolución) * 3 (bytes por pixel en color 24-bits) * 30 (fps) = 26,4 MB/s utilizando los servicios de red. Sin mucha esperanza, hicimos una prueba adicional intentando enviar esa información por TCP y obteniendo resultados también negativos: si bien los paquetes ya no se perdían por ser TCP un protocolo que resuleve este problema, los frames tampoco llegaban en tiempo real.

La tercer alternativa, que finalmente tuvo éxito, fue utilizar memoria compartida entre procesos para hacer una copia del frame obtenido y poder accederlo desde nuestra aplicación. Para esto, se utilizó la librería multi-plataforma POCO (ya incluida en openFrameworks y que agregamos al proyecto de reacTIVision) compartiendo un mismo segmento de memoria entre el módulo reacTIVision (que realizaría la escritura) y nuestra aplicación (que leería la información escrita). La implementación resultó ser eficiente, entregando los frames en tiempo real y prácticamente sin variar la utilización del CPU.

Anuncios

Trackmate

Trackmate es una de las opciones disponibles para utilizar como framework de visión, en la construcción de YARMI. Es un sistema de reconocimiento de fiducials desarrollado por el Tangible Media Group del MIT Media Lab, con el objetivo de ser económico y fácil de construir. Trackmate reconoce la posición, rotación e información de color de objetos etiquetados y dispuestos sobre una superficie. Envía toda esta información a las aplicaciones cliente mediante el protocolo LusidOSC (basado en OSC como su nombre sugiere), desarrollado por los autores.

El mayor fuerte de este framework, es la excelente documentación que posee y su presentación desde un sitio web muy bien diseñado y con un alto grado de usabilidad. En la página se puede ver distintos ejemplos de aplicaciones que utilizan el framework.

El sistema es capaz de reconocer una clase de fiducials especial, que permite manejar alrededor de unos  280 trillones de identificadores diferentes (códigos de barra circulares) de 1” (una pulgada) de diámetro.

Del sitio web, pueden descargarse las siguientes herramientas:

  • Tagger: permite generar las etiquetas que el sistema puede reconocer, exportándolas en formato PDF o PNG.
  • Tracker: es el módulo principal, que recibe la información de la cámara web especificada y publica un servidor dónde espera conexiones de clientes que hablen el protocolo LusidOSC. Además, tiene integrado el mecanismo de calibrado y testeo.
  • LusidOSC Bundle: conjunto de aplicaciones de ejemplo para ejecutar en Processing y probar el sistema fácilmente. Además, incluye una librería para Processing, que resuelve la comunicación entre programas desarrollados en este entorno y el servidor (Tracker).

El sistema prometía mucho, pero una vez iniciada la etapa de calibrado y testeo, se hicieron evidentes una serie de restricciones importantes.

Los parámetros más importantes a la hora de configurar el sistema son las dimensiones del área de trabajo, la resolución de la cámara y la cantidad de pixels (de cámara) por pulgada (de superficie).  La primer restricción que se observó, es que para un área de trabajo aplicable a nuestro proyecto, la taza de cuadros por segundo de información que el sistema puede generar no es suficiente. En la siguiente tabla puede verse su variación en función del área:

dimensión del área (pulgadas) cuadros por segundo
11.625 x 8.250 15
6.000 x 6.000 20
3.000 x 3.000 30

Se puede notar que recién para una relación fiducial-área de 1/9, el sistema provee una taza de cuadros por segundo razonable.

Otra restricción encontrada, es que el sistema es muy suceptible a cambios en la iluminación. Durante la etapa de calibrado, una vez que se fijan los parámetros arriba mencionados, es necesario realizar la “calibración de blancos”. Se puede notar como la imagen pre-procesada por el sistema se deteriora considerablemente por el más mínimo cambio en la iluminación, respecto a aquella con la que se realizó el calibrado.

Asociado a esto último, se notó que el sistema está construido para recibir una imagen formada solamente por el fondo blanco y los fiduciales. Cualquier otro objeto captado por la cámara dentro del área de trabajo (como un soporte para el fiducial, o una mano) hará que el sistema falle. En particular, el valor de las rotaciones de los fiducials es lo primero que se pierde por completo.

Tras el análisis del sistema, se concluye que éste está más orientado a un escenario con las siguientes características: libre de objetos que interfieran en la imagen (por ejemplo para flimarse desde abajo de la superficie, como se hace en la Reactable), con un área de trabajo relativamente chica, y en dónde tener tal cantidad de fiducials distintos pueda ser de utilidad.

El framework no cumple con los requisitos adecuados para nuestra aplicación, por lo que fue descartado.