Entre las razones que desde hace mucho tiempo me motivaban a aprender Puredata están las posibilidades de tracking de movimiento que había ido leyendo por ahí que existían. Para ser exactos, desde que en 2010 experimenté con Animata y supe de las posibilidades de conectar ese software con Puredata a través de OSC para controlar títeres digitales. En aquel momento, sin embargo, no pasé de experimentar con patches elaborados por otros y usando sliders en lugar de tracking para controlar las coordenadas.
Por si es necesario aclarar el significado de tracking -aunque hay que tener en cuenta que es un término algo polisémico-, en el contexto al que ahora me refiero se trata de un análisis informático de una imagen en movimiento, con el fin de detectar cambios de posición de los objetos dentro de esta o incluso, a veces, el movimiento de la cámara que la captura.
En este caso usamos un tipo de tracking muy básico y algo rudimentario, pero que es perfectamente suficiente para testear la interactividad que ese tipo de aplicaciones nos pueden brindar. Como puedes suponer, encontrarás más información sobre eso en la página de Puredata de los FLOSS manuals.
Este patch consta de cuatro bloques de elementos interconectados. Uno de ellos es el que genera la ventana de GEM, ya lo hemos visto otras veces. Otro es el que contiene la cadena de render, que se inicia con [gemhead 0]. Ahí se carga una animación sencilla con un cubo que va de un lado para el otro.
El bloque de más a la derecha, que se inicia con [gemhead 2] es donde se procesa el tracking. A través del objeto [pix_video] se recibe la información visual de la webcam u otro dispositivo de captura de video. El objeto [pix_movement] es el que hace el tracking, usando un sistema que consiste en evaluar el frame del momento presente comparándolo con otro anterior en el tiempo. Por su inlet derecho podemos especificar un umbral en función del cual la detección será más fina o más basta. La información visual consistente en la diferencia cromática entre los dos frames se expulsa por el inlet y es [pix_blob] quien la convierte en coordenadas X e Y, que expulsa por su segundo y tercer inlet, respectivamente, junto a un valor de tamaño de la mancha (el blob) que se expulsa por el cuarto.
El bloque que se inicia con un [r x] (que podría escribirse también [receive x]) recibe la coordenada X que llega desde [pix_blob] a [s x]. En ese caso no usamos Y. El propósito de todos esos objetos es convertir esa información de coordenadas en un valor numérico de unas características y rango oportunos para lo que queramos usarla. En http://www.packtpub.com/books/content/motion-detection podéis ver contenido de muestra gratuito de dónde se han sacado algunas soluciones aplicadas aquí. En concreto el uso de un objeto [trigger f f b] y un float asociado que nos permiten determinar la dirección del movimiento, según el signo (positivo o negativo) del valor resultante. Ese valor lo multiplicamos y sumamos para que pueda gobernar el frame que se muestra de la película del cubo que tenemos cargada en [pix_film]. Ahora el movimiento de nuestro brazo o nuestra cabeza delante de la webcam puede hacer avanzar o retroceder la reproducción de ese clip de vídeo.