Y gracias a Stephane Cousot y Douglas Edric Stanley contamos con la implementación de OpenCV para processing y/o java.

INSTALACIÓN

Para instalarla tenemos que en primer lugar instalar opencv, lo bueno es que figura en la mayoría de respositorios así que bastaría usar el administrador de paquetes para instalarlo.
aptitude install opencv
urpmi opencv
pacman -S opencv
emerge opencv
....
dependiendo del sistema en el que estes.

Esto debiera instalar las librerías y cabeceras necesarias en las carpetas del sistema /usr/include y /usr/lib. Como estas ubicaciones ya hacen parte del PATH no vanos a tener los problemas que normalmente se presentan en windows. Al parecer en ubuntu algunas librerías se instalan por aparte, por si acaso esta es la lista de librerías que deberías tener instalada:
/usr/lib/libml.so
/usr/lib/libhighgui.so
/usr/lib/libcxcore.so
/usr/lib/libcvaux.so
/usr/lib/libcv.so
Si no es así seguramente es un paquete separado así que por medio del administrador de paquetes lo puedes buscar e instalar.

Ahora descargamos la librería para processing al momento la 01, aconsejable también los ejemplos para java y/o processing.

El procedimiento es el mismo que cualquier librería, descomprimimos el paquete y copiamos la carpeta dentro de processing-1.0.9/libraries/ y listo.

A este momento si tenemos un dispositivo v4l conectado y configurado correctamente (osea funcionando), debería estar funcionando los ejemplos de la librería, y ya se podría trabajar en ella. Pero los que usamos distribuciones de 64 bits encontraremos un problema como es ya habitual.

AMD64

Si corres algún ejemplo de opencv en processing sobre 64bits puedes encontrar un error del tipo:

!!! required library not found : /usr/lib/libOpenCV.so: /usr/lib/libOpenCV.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Si has visto mis post anteriores ya sabrás cual es el problema, tenemos que encontrar un libOpenCV.so compilado para 64bits, pero esta vez la solución fué un poco más “elaborada”, ya que este paquete no existe en los repositorios, fué un paquete compilado especialmente para la implementación de OpenCv en Processing.

Tendremos entonces que compilarlo de las fuentes que se incluyen en el paquete de lka librería que descargamos. Para una solución más sencilla subí el archivo compilado a mi servidor, así que lo pueden descargar de aquí: libOpenCV.so y reemplazar el existente en processing-1.0.9/libraries/OpenCV/library. Con esto queda solucionado y podrás utilizar opencv en 64bits sin problema.

Si quieres compilarlo estos son los pasos que yo seguí, para evitar compilar las clases, lo que hize fué extraer del archivo processing-1.0.9/libraries/OpenCV/library/OpenCV.jar los archivos Bob.class y OpenCV.class, con cualquier gestor de compresión de archivos lo puedes hacer, y los copié en processing-1.0.9/libraries/OpenCV/source/java/hypermedia/video luego desde consola

cd processing-1.0.9/libraries/OpenCV/source/java
javah -jni hypermedia.video.OpenCV

esto nos genera un fichero cabecera hypermedia_video_OpenCV.h, lo movemos a processing-1.0.9/libraries/OpenCV/source/cpp y compilamos la libreria libOpenCV.so
mv ./hypermedia_video_OpenCV.h processing-1.0.9/libraries/OpenCV/source/cpp
cd processing-1.0.9/libraries/OpenCV/source/cpp
g++ -shared OpenCV.cpp -o libOpenCV.so -I/usr/include/opencv/ -I/usr/lib/jvm/java-1.6.0-openjdk/include/ -lcv -lhighgui -fPIC

esto nos genera la librería libOpenCV.so que podemos copiar a processing-1.0.9/libraries/OpenCV/library reemplazando la anterior, y listo!! OpenCV funcionando.

Como recordarán para que funcionara processing en 64bits antiguamente teníamos que hacer una par de cosas, primero tocaba instalar jikes y reemplazar el que incluía processing con éste, esto ya no es necesario. Posteriormente tocaba reemplazar el java que venía incluído con uno nativo, cosa que permite usar el sun-jdk o el open-jdk, como lo mecioné anteriormente.

Ahora si descargas processing, que a la fecha su versión es la 1.0.9, verás que funciona perfectamente sin hacerle ningún cambio, lo cual es una muy buena noticia. Pero, como parte del combo yo instalo la librería GSVideo, verás que comienzan los problemas.

GSVIDEO 0.6

Al descargar e instalar la última versión (gsvideo-0.6-pre0.zip a la fecha), verás que processing nos vota un error del tipo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: Unable to load library ‘gstreamer-0.10′: /usr/lib/libgstreamer-0.10.so.0.22.0: wrong ELF class: ELFCLASS64

Como bien lo dice (o podrán intuir) el problema radica en la arquitectura de 64bits. Pero ¿porqué presenta este problema si GSVideo es una librería multiplataforma?, la respuesta es simple, en realidad el problema está en que gsvideo requiere de gstreamer instalado, es decir nativo, de 64bits, y cuando es llamado por processing lo procesa dentro de un java de 32bits lo cual genera la incompatibilidad.

Para solucionarlo volvemos a la opción de instalar un jdk y reemplazar el existente en processing por este. Para esto podemos seguir las instrucciones que escribí aquí. Tengan en cuenta que aunque las instrucciones son para el open-jdk, también son válidas para el sun-jdk si es de su preferencia.

Con esto volvemos a ejecutar nuestros ejemplos de GSVideo en processing y ya no tendremos ningún problema.

OpenGL

Podríamos pensar que ya está listo nuestro processing para trabajar, pero no es así, si volvemos a probar todo encontraremos un nuevo problema: lo que antes probamos con la librería OpenGL ya no funciona, ¿porqué?.

Si nos fijamos el error que ahora vota es muy similar al anterior de GSVideo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Como podremos observar es un error nuevamente de arquitectura, pero esta vez nos dice “wrong ELF class: ELFCLASS32″, es decir, que la librería que encontró (libgluegen-rt.so), es de 32 bits y que eso es incorrecto. Pues si analizamos el cambio que hicimos nos daremos cuenta fácilmente del problema, al reemplazar el java que traía processing que era de 32 bits por el que nosostros instalamos que es de 64bits, generó la incompatibilidad con el opengl de 32bits que traía processing.

Entonces ¿cómo lo solucionamos?, pues de un modo similar al caso anterior, instalamos el paquete de opengl para java que es llamado jogl, y reemplazamos los archivos de processing/libraries/opengl/library/* con estos.

Para el caso de gentoo el paquete jogl se encuentra en el java-overlay, para las demás distribuciones no sabría decirles si existe un paquete precompilado, pero googleando se darán cuenta o en último caso está la posibilidad de compilarlo desde las fuentes.

Yo manejo los overlays con layman, así que estos fueron mis pasos:
layman -a java-overlay
echo "dev-java/jogl ~amd64" >> /etc/portage/package.keywords
echo "dev-java/gluegen ~amd64" >> /etc/portage/package.keywords
emerge -av jogl

Con esto ya tengo instalado jogl en mis sistema, lo cual generó los archivos:

/usr/lib64/gluegen/libgluegen-rt.so
/usr/share/gluegen/lib/gluegen.jar
/usr/share/gluegen/lib/gluegen-rt.jar
para dev-java/gluegen, que instaló como dependencia, y:

/usr/lib64/jogl/libjogl_awt.so
/usr/lib64/jogl/libjogl.so
/usr/share/jogl/lib/jogl.jar
para dev-java/jogl.

Ahora lo único que tendremos que hacer es copiar estos archivos a processing-1.0.9/libraries/opengl/library/ reemplazando los que se encuentren allí.

Con esto ya deberíamos tener funcionando processing completo sobre amd64.

Ahora, la solución a usar la librería OpenGL. Como te habrás fijado cuando se intenta usar esta librería vota un error del estilo:

java.lang.UnsatisfiedLinkError: /self-installed/processing-0135/libraries/opengl/library/libjogl_drihack.so: /self-installed/processing-0135/libraries/opengl/library/libjogl_drihack.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Esto es claramente por usar librerías de 32 bits (wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)), para solucionarlo podemos bajar la librería de soporte OpenGL para java (JOGL) de su página oficial.

Al final de la página encontrarás los links de descarga, hay versión para tanto para linux amd64 como para windows 64bits.

Una vez lo descarges todo lo que tendrás que hacer es descomprimirlo y copiar todo el contenido de la carpeta  /lib  a  processing/opengl/library/ , sobreescribe lo que ya exista.

——————————————————————–

Actualización:
En gentoo se encuentra el paquete jogl en el overlay java-overlay. Para usarlo instalamos layman, añadimos el overlay e instalamos.
emerge -av layman
layman -a java-overlay
emerge -av jogl
Portage va a pedir que desenmascares algunos paquetes que se encuentran el la rama ~amd64.
Esto nos instala jogl y gluegen como dependencia, luego copiamos o hacemos un enlace simbólico de los archivos instalados dentro de processing/libraries/opengl/library/ re-escribiendo los archivos originales.

Yo instalé el paquete java-1.6.0-openjdk-devel, que como lo mencioné entre líneas difiere del de sun, en que este es un jdk opensource.

Una vez instalado el jdk, se ubica la carpeta donde se instaló, generalmente los gestores gráficos de paquetes, como synaptic y adept, permiten ver los archivos instalados por dicho paquete, así podremos ubicar la carpeta raiz del jdk, que, para el caso del java-1.6.0-openjdk-devel sobre un Mandriva Free 2009 x86_64, se instaló en ‎/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64. Dentro de dicha carpeta tendrá que haber mímino una carpeta bin, una lib y una del jre.

Procederemos a borrar o mover la carpeta java del processing y hacer el link simbólico, para ello desde consola y como root.

rm -R /opt/processing-1.0.1/javaln -s /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64 /opt/processing-1.0.1/java

y listo tendremos nuestro processing funcionando. No olvides que para ejecutarlo en caso de dar algún error prueba con:

cd /opt/processing-1.0.0 && ./processing

Como novedad trae la implementación del método GSCapture.list(), para listar los dispositivos de captura conectados. Este método asume que el elemento de fuente es v4l2src, pero se le puede pasar el parámetro v4lsrc, GSCapture.list(“v4lsrc”). Además incluye la posibilidad de definir pipelines con la clase GSPipeline que terminen en filesink, para hacer captura a disco, un paso más cerca de GSMovieMaker.

También incluye unas facilidades de sintaxis, ya no es necesario emplear un array para escoger el dispositivo de captura en el constructor del objeto GSCapture, por ejemplo:

de esto:
cam = new GSCapture(this, 320, 240, new String[] {“device”}, new String[] {“/dev/video1″},15);

se pasó a esto:
cam = new GSCapture(this, 320, 240, “/dev/video1″,15);

Lo que ven en la imagen es un ejemplo de captura simple + el ejemplo ASCII video en Processing 1.0.1 + gsvideo 0.4.5 sobre un sistema Linux Mint Felicia (prácticamente un Ubuntu Intrepid), capturando de mi tarjeta de radio y tv Kworld Plus Lite PCI. Para lograrlo simplemente inicié Processing, luego tvtime en el canal que deseé, cerré tvtime y arranque el ejemplo de processing, y así toma la señal del dispositivo con el último canal sintonizado.

El método GSCapture.list() aún no me ha funcionado, pero seguiré probando y posteándo.

PD: probado en Mandriva Free x86_64 2009 y funciona perfectamente, aunque el método GSCapture.list() presenta el mismo error que en 32 bits.

Este excelente software de producción digital audiovisual lanza su primera versión estable.

Según parece la descarga estuvo disponible desde el 24 de este mes, y hubo record de descargas a tal punto que se saturó varias veces el servidor, pero bueno yo hasta ahora me entero y aquí esta la captura de Processing 1.0 sobre Sabayón GNU/Linux. Los colores de la interfaz cambiaron, y si alcanzar a ver el panel inferior notarán que también cambió el icono, no he tenido tiempo de probarlo mucho aún, pero siempre me ha parecido feo que la versión para linux incluya la librería video la cual no funciona en linux, solo en windows y mac, en fin para eso está GSVideo.

Estamos comenzando con el wiki, donde planeamos tener toda la información de tutoriales, traducciones y demás de este gran software de creación multimedia. Digo estamos porque me he involucrado con el proyecto, e invito a todos a participar en esta excelente iniciativa.

Para utilizar este nuevo método tenemos que añadirle los parámetros a la linea que inicia el objeto de captura
video = new GSCapture(this, 160, 120, 15);
añadiéndole el dispositivo que queremos que reconozca, si no le añadimos nada reconocerá el primero
video = new GSCapture(this, 320, 240, new String[] {“device”}, new String[] {“/dev/video1″},15);
si tenemos errores por “v4l2src” podemos añadirle también
video = new GSCapture(this, 320, 240, “v4lsrc”, new String[] {“device”}, new String[] {“/dev/video1″},15);
donde /dev/video1 será la dirección del dispositivo que queremos trabajar.
Así mismo podemos suprimir el último parámetro que corresponde a los fotogramas por segundo a los que hará la captura, siendo el predeterminado 25.

Parece que todavía no soporta múltiples dispositivos, ya que cuando agrego otro vota NullPointerException, pero es un gran avance, y seguramente seguirá teniendo mejoras significativas para el delite de todos aquellos que trabajamos con video en tiempo real, o edición algorítmica.

Mis agradecimientos y felicitaciones a Andrés Colubri por compartir su trabajo con nosotros. ]]> http://www.gnu-media.org/2008/05/0-3-12-nueva-version-de-gsvideo.html/feed 20 http://www.gnu-media.org/2008/04/usando-gsvideo.html http://www.gnu-media.org/2008/04/usando-gsvideo.html#comments Wed, 23 Apr 2008 07:25:00 +0000 Sergio Esteban http://seromerol.wordpress.com/2008/04/23/usando-gsvideo/ Algunos tips que ayudan a la hora de usar el método de captura de gsvideo.

Tengo dos dispositivos v4l, una capturadora de tv Kworld PlusTV litePCI reconocida por el módulo saa7134 y una webcam Genius VideoCAM NB reconocida por el módulo sn9c102 aunque también se puede con el módulo gspca.

La libreria gsvideo aún no tiene un método para selección de dispositivos desarrollado, lo cual nos impide escoger entre los dispositivos que tenemos conectados, de manera que reconocerá únicamente /dev/video0, que para mi caso es la tarjeta de tv.

Entonces, si quiero usar la tarjeta de tv no hay problema, puedo poner a correr el programa y la reconocerá, pero algo curioso con la nueva versión (0.3.10) es que la reconoce de una con la entrada composite. En caso de querer trabajar con algún canal tengo que correr primero tvtime o xdtv y sintonizarlo, luego si abrir processing y listo a correr el código. A veces se traba, aún no logro determinar por qué, pero la mayoría de veces va bien.

Pero, como uso la webcam?, simple, solo tienes que hacer que la reconozca como primer dispositivo de video, para esto lo que puedes hacer es remover los módulos de la webcam y de la capturadora y luego cargar primero el de la webcam, es decir, para mi caso:

rmmod saa7134-alsa
rmmod saa7134
rmmod sn9c102
modprobe sn9c102

para que permita retirar el módulo saa7134-alsa, tengo que cerrar el kmix que por defecto se me carga como icontray, y naturalmente el kradio o demás programas que puedan estar usando algún módulo.

En caso de que bote algún error en la captura puedes provar a cambiar la línea que carga la cámara, la cual inicialmente sería algo así:
video = new GSCapture(this, width, height, 15);
y la podrías cambiar por algo así:
video = new GSCapture(this, width, height, “v4lsrc”); ]]> http://www.gnu-media.org/2008/04/usando-gsvideo.html/feed 3 http://www.gnu-media.org/2008/04/instalando-libreria-gsvideo.html http://www.gnu-media.org/2008/04/instalando-libreria-gsvideo.html#comments Tue, 22 Apr 2008 20:43:00 +0000 Sergio Esteban http://seromerol.wordpress.com/2008/04/22/instalando-libreria-gsvideo/ Gsvideo es una iniciativa que implementa el mismo API que la librería video de Processing que trabaja normalmente el windows y mac, pero utilizando el motor de gstreamer.

No había tenido tiempo de postear sobre esta, funciona bastante bien, la probé sobre mi sistema de mesa un gentoo amd64 2007.0, aunque no ha trabajado sobre amd64 sino en la jaula de 32bits. Tenía algunos problemas con el reconocimiento de algunas cámaras y el método loop para la reproducción de video, que parece fueron solucionados en su nueva versión.

Para poder trabajar con esta librería tuve que instalar gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-bad and gst-plugins-ugly, que eran los que mencionaban, y aparte tuve que instalar gst-plugins-v4l2, gst-plugins-v4l y gst-plugins-ffmpeg. Según los comentarios en la página para distribuciones como ubuntu y debian bastaría instalar libgstreamer0.10-dev .

En este momento voy a testear la nueva versión a ver si trabaja sobre 64bits. En fin, para los que trabajan video es una excelente opción, que se suma a la librería libCV que funciona con el API multimedia de java JMF, pero me pareció más práctica teniendo en cuenta que implementa los mismos métodos que la librería video y por ende funciona con la misma documentación. (aunque aún no tiene todos los métodos está bastante completa).