Archive

Posts Tagged ‘artoolkit’

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.

Estado del Arte I

abril 20, 2010 1 comentario

Arrancando a ver un poco qué proyectos de temática similar a la de YARMI hay en la vuelta, encontramos la web de Martin Kaltenbrunner (uno de los creadores de la Reactable), que nos facilita una larga lista de proyectos relacionados con interfaces tangibles, realidad aumentada y música, a la vez. De esa lista, seleccionamos los más relevantes para nuestro proyecto.

Scrapple

Este sistema, desarrollado por Golan Levin en la School of Art de la Carnegie Mellon University en el 2005, es una instalación que consta de una superficie similar a la de un pizarrón de marcador, una cámara, una software corriendo sobre Windows y un proyector.

La interfaz proyecta algo similar a un espectrograma, sobre el cual se colocan (o dibujan) objetos que son “reproducidos” secuencialmente una y otra vez. La posición horizontal especifica el tiempo en el compás, mientras que la vertical define el tono del sonido, que se expande en un rango de 8 octavas. Un indicador se proyecta sobre el espectrograma indicando la posición actual de la reproducción en el loop, mientras que una especie de brillo se puede ver alrededor de los objetos reconocidos.

La superficie con los objetos y la proyección

La cámara y el proyector no están colocadas en ninguna posición particular: la imagen captada es transformada de forma que la superficie se vea desde arriba y en proyección ortogonal. Esta imagen es sobre la cual trabaja el algoritmo de reconocimiento de objetos. Para proyectar la interfaz sobre la superficie, se hace una transformación inversa.

Tal vez el aporte más importante que pueda hacer a YARMI, es del mecanismo utilizado para evitar la retroalimentación de la proyección hacia el sistema de visión de computadora (que puede llegar a ser un problema en este modo de funcionamiento). Éste consiste iluminar la superficie y los objetos con una fuente de luz infraroja, y utilizar una cámara con un filtro IR optimizado para dejar pasar luz de frecuencias algo mayores a 750 nanómetros. De esta forma se puede lograr, aprovechando el hecho de que los proyectores emiten muy poca luz en esa porción del espectro, que el sistema de visión de la máquina y la percepción visual del usuario no se vean afectados mutuamente.

El paper puede verse acá.

Un video:

Music Table

Desarrollado en el 2003 en el ATR Media Information Science Laboratories, en Japón, este secuenciador de música es más “portable” que el anterior. Consiste también en una cámara y un conjunto de fichas (fiducials en este caso) que se colocan sobre una superficie plana, a diferencia que en este caso la imagen se genera en un monitor, sobre el feed de video original.

Fue desarrollado utilizando la ARToolkit (uno de los frameworks de visión para realidad aumentada) y PD (un lenguaje de programación gráfica orientado a la creación musical interactiva), dos herramientas que seguramente nos serán de utilidad.

El sistema Music TableEl concepto más interesante viene por el lado del diseño de la interacción. Una ficha especial llamada copy card, puede ser usada para asignar el patrón musical creado y actualmente en reproducción a una phrase card. De esta manera, las fichas que lo conformaban y el espacio que ocupaba quedan libres para crear nuevos patrones, mientras la phrase card donde quedó salvado puede usarse en cualquier momento para reproducir el patrón original. Además, una phrase-edit card puede ser utilizada  para modificar distintos parámetros de las notas que componen el patrón almacenado.

Link al paper.