Si haces uso de estos programas este artículo te puede interesar, y en caso contrario te parecerá la típica batallita de programación que sólo interesa a los frikis del software libre.
Tengo publicado un artículo en el cual presenté un script ‘dir2avi.py’ que procesaba todas la imágenes ‘*.jpg’ de un directorio y obtenía un vídeo avi, pero he descubierto que no siempre funciona bien, lo curioso es que no es por un problema de mi script y el bug está muy repartido entre diversas aplicaciones.
He usado aquel script y en determinadas ocasiones generaba unos vídeos con ciertas anomalías cromáticas, apareciendo manchas de colores. Incluso he publicado algún vídeo en youtube que presentaba este problema ante la impotencia de localizar el problema, pero esta vez me afectaba a un proyecto que quiero que tenía mucho interés en que quedara perfecto así que he dedicado bastante tiempo a investigarlo.
El vídeo siguiente de sólo 8 segundos muestra el efecto que tiene el bug en un vídeo.
Hice varias pruebas haciendo toda clase de variaciones posibles para hacer vídeos a partir de imágenes y para mi sorpresa resultó que de una forma o de otra en algunos casos concretos reaparecía siempre el mismo problema fuera cual fuera el método empleado.
Las imágenes jpeg de partida aparecían perfectas, pero el vídeo que producían determinadas colecciones de imágenes presentaba problemas y era difícil saber la razón. Intenté un montón de cosas:
- Para descartar un bug en ffmpeg probé a generar el vídeo con mencoder, pero no tuve suerte.
- Para descartar un bug en algún codec probé con distintos codecs de vídeo en ffmpeg, igualmente sin éxito.
- El problema también apareció pasando un vídeo de formato ogg a un formato avi con ffmpeg, lo cual parecía descartar totalmente el problema en mis imágenes. Este ogg lo generé capturando vídeo desde el escritorio con recordmydesktop así que el problema parecía burlarse de mi sentido de la lógica.
- Quizás fuera el formato de vídeo y probé a generarlo en varios formatos (avi, mp4, mpeg, ogg, flv), pero tampoco.
- Quizás a ffmpeg no le gusta que yo redimensione con la opción -s y use simultáneamente -sameq, así que probé a no redimensionar, a redimensinar con el mismo tamaño de la imagen, a no indicar la dimensión para que la tomara de las imágenes originales, pero nada de eso tuvo éxito.
Fueron varios días insistiendo sin éxito. El problema sólo aparece usando algunas colecciones de imágenes, pero no lograba descubrir en que se diferencian los jpegs que daban problemas de los restantes que no los daban. Por fin llegó mi primer éxito y una posible solución. Si las imágenes que daban problemas al pasarlas a vídeo eran convertidas previamente a otro formato, por ejemplo png, el problema desaparecía confirmando el problema con el formato de las imágenes de entrada.
Decido entonces investigar un poco más los jpegs y verificando una de estas imágenes usando el comando identify -verbose de ImageMagick descubro que aparece una información contradictoria en la cabecera exif respecto al ColorSpace. En la misma imagen figura lo siguiente:
- exif:ColorSpace: 1
- jpeg:colorspace: 2
Uno de los dos valores debe de ser incorrecto, y los campos exif son meramente informativos.
Una breve aclaración sobre exif:Exchangeable image file format (abreviatura oficial Exif) es una especificación para formatos de archivos de imagen usado por las cámaras digitales. Las etiquetas (tags) de metadatos definidas en el estándar Exif cubren un amplio espectro de valores. Los programas antiguos no tienen en cuenta estos valores, y los modernos los manejan como información de usuario final principalmente.
Una imagen sin información exif es perfectamente funcional, así que no parecía muy lógico que un dato erróneo en un campo exif tuviera consecuencias en el software, pero tratándose de un caso rarito y existiendo el dato contradictorio me construyo un script que elimine todos los campos exif de mis imágenes jpeg, y … ¡Eureca!
Quitar la información exif en la imágenes jpg solucionaba el problema para ffmpeg.
Esto puede que no resulte muy emocionante para la inmensa mayoría de los mortales, pero apuesto que son muchos a lo largo y ancho de Internet que han tropezado con este escurridizo bug sin sospechar de qué se trata. Para eliminar la información exif del jpeg recurrí a la librería de imágenes PIL en python, y lo que hago con cada fichero de imagen es simplemente esto:
import Image img=Image.open(fi) (x,y)=img.size img.resize(img.size) # Redimensinamos al mismo tamaño. Es un truco para suprimir toda la info de exif img.save(fi)
Después de hacer esto las imágenes quedan sin campo exif y ffmpeg ya genera el vídeo correctamente. (Me quedé muy sorprendido cuando esto funcionó y pensé que a pesar de que una historia de bugs no resulta muy emocionante merecía la pena comentarlo en un artículo). Publicaré en breve alguna solución que incluiré como parte de un paquete de utilidades. De momento solo tengo un parche poco presentable.
Conclusiones:
Es muy posible que ImageMagick bajo ciertas circunstancias cometa algún error en el mantenimiento de la información exif, y puede que la inconsistencia en los campos exif no sea algo tan raro, incluso podría considerarse como algo asumible porque donde tiene realmente sentido es en un fichero recién salido de una cámara de fotos.
También es muy posible que recordmydesktop genere un vídeo ogg con metainformación errónea o inconsistente y sería un bug independiente del anterior. En cualquier caso el hecho de que la información exif pueda provocar fallos en ffmpeg como mencoder, significa que ambos hacen un uso muy cuestionable de esta información, que debería ser ignorada. Sí estas se suprimen el vídeo se genera perfectamente. No tiene mucho sentido.
No descarto que todos estos programas que estoy mencionando estén haciendo cosas incorrectas y que sólo den problemas cuando se hace un determinado uso combinado de los mismos. Estaríamos ante una epidemia de bugs.
Que ffmpeg y mencoder compartan un mismo bug en la adquisición de imágenes jpeg no sería demasiado sorprendente ya que ambos son software libre y cabe la posibilidad de que uno copiara el bug del vecino.
Deja una respuesta