De vez en cuando grabo algún vídeo ó secuencia de fotos del que me gusta extraer fotogramas y crear/componer un GIF animado, muchos los he ido colgando por aquí. Un GIF animado es una pieza gráfica especial, singular, a medio camino entre la fotografía y el vídeo, sin la perfección y nitidez de una ni la toda la información visual/sonora del otro pero con un espacio propio dentro del cual funciona mejor y supera a ambos en simpleza y capacidad visual.
Llevaba tiempo queriendo integrarlos en el blog. Como galería independiente me parecía algo excesivo así es que finalmente he optado por modificar el código que gestiona la galería de Fotografías (alojadas en Flickr) para que integre ahora además los GIFS animados que alojados en Picasaweb. En adelante, la galería de fotos estará un poco más animada.

Un GIF es un formato de archivo de imagen reducido a 256 colores que contiene uno o varios fotogramas. Estos fotogramas son interpretados de forma nativa por cualquier navegador web y reproducidos de forma cíclica (normalmente, no tiene porqué ser así) sin necesidad de aplicaciones extras como pueden necesitar los archivos de vídeo.
Para realizar un GIF animado hay cienes y cienes de herramientas. En GNU/Linux podéis hacer un GIF animado directamente desde un vídeo con FFMPEG o MENCODER, pero para hacer un buen GIF animado, cíclico y optimizado en color y peso lo mejor es crearlos a partir de una pila de imágenes con IMAGEMAGICK.

Crear GIF animado desde consola

En una carpeta temporal vuelca las imágenes que componen los fotogramas. Si sólo tienes el vídeo puedes extraer los fotogramas con MPLAYER haciendo lo siguiente:mplayer -vf screenshot mipelicula.avi
Durante la reproducción pulsa «s» para tomar un fotograma instantaneo o pulsa «MAYUSCULAS+s» para comenzar a generar fotogramas a cada frame hasta que vuelvas a pulsar «MAYUSCULAS+s». (cuidadito! con dejar pulsado «MAYUSCULAS+s» con un vídeo de 1:30 horas porque producirás varios cientos de miles de PNG en un plis-plas).

Una vez tengas los fotogramas que compondrán el GIF animado ayudate de cualquier visor de imágenes ( yo uso VIEWNIOR ) y visualiza los frames extraidos para ir eliminado los primeros y últimos hasta conseguir una secuencia que cicle correctamente, es decir, que el último fotograma y el primero sean tan parecidos que den fluidez a la secuencia. Si por ejemplo con mplayer extrajiste una serie de fotogramas del shot00001.png -> shot0124.png, después de ir eliminado fotogramas te podría quedar una secuencia de 50 imágenes dek shot0010.png -> shot0060.png.
Ahora puedes convertir esta secuencia de 50 pngs en un GIF haciendoconvert -fuzz 5% -delay 1x12 shot*png -resize 720 -layers OptimizeTransparency secuencia.gif
Con delay 1×12 (mostrar cada frame 1/12 de segundo) controlas la velocidad de reproducción del GIF. Fuzz 5% indica cuanto color se puede perder en la comparación (cuanto más alto, menos calidad, menos peso del archivo). Resize reescala la imagen resultante (a más tamaño, más peso). OptimizeTransparency calcula y elimina aquellas partes de que repiten entre fotogramas y por lo tanto se puede optimizar.

Trucos

Si no queréis borrar fotogramas podéis hacer pruebas con segmentos de la secuencia de archivos haciendoconvert -fuzz 5% -delay 1x12 shot00{12..24}.png -resize 720 -layers OptimizeTransparency secuencia.gif
Esto produciría un GIF a partir de los fotogramas shot0012.png hasta el shot0024.png ignorando el resto.

Si tenéis muchos fotogramas y os sale un GIF muy lento y pesado probad a usar 1 fotograma de cada 2 haciendoconvert -fuzz 5% -delay 1x12 shot*[24680].png -resize 720 -layers OptimizeTransparency secuencia.gif

Si tenéis una animación que os gusta pero no es cíclica podéis hacer una animación tipo ping-pong (como la del zorro) haciendo convert -fuzz 5% -delay 1x12 shot00[12..24].png shot00[24..12].png -resize 720 -layers OptimizeTransparency secuencia.gif

Incluso si lo que tenéis es una secuencia de fotogramas en los que la cámara se ha movido, podéis estabilizarlos y entonces generar el GIF, lo expliqué en el apunte: Crear un gif animado estabilizando una imagen

In the good old days of sysvinit, if you wanted to run some extra code during start up, you were either (ab)using the sysconfig file or patching the init script itself. The init scripts in many packages are not as marked as configuration, which means in those cases your edits were lost. If it was marked as configuration then you have to merge your changes with those fixes manually. In either case … not ideal.

Getting started

Let’s say you want to have 3 instances of redis. One for each redis using app. Getting 3 instances app with systemd’s nifty Instantiated Services is easy.

[Unit]
Description=Redis
After=network.target
PartOf=redis.target

[Service]
Type=simple
User=redis
Group=redis
PrivateTmp=true
PIDFile=/var/run/redis/%i.pid
ExecStart=/usr/sbin/redis-server /etc/redis/%i.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target redis.target

“systemctl start redis@discourse” will launch us an instance with “discourse.conf”. Other systemctl commands just work as fine. “systemctl enable redis@discourse” , “systemctl status redis@discourse” . Now to stop all redis instances? “systemctl stop redis.target”

A couple of months ago, I was meeting colleagues of mine working on Docker and discussing about how much effort it would be to add support for it to SUSE OpenStack Cloud. It's been something that had been requested for a long time by quite a number of people and we never really had time to look into it. To find out how difficult it would be, I started looking at it on the evening; the README confirmed it shouldn't be too hard. But of course, we use Crowbar as our deployment framework, and the manual way of setting it up is not really something we'd want to recommend. Now would it be "not too hard" or just "easy"? There was only way to know that... And guess what happened next?

It took a couple of hours (and two patches) to get this working, including the time for packaging the missing dependencies and for testing. That's one of the nice things we benefit from using Crowbar: adding new features like this is relatively straight-forward, and so we can enable people to deploy a full cloud with all of these nice small features, without requiring them to learn about all the technologies and how to deploy them. Of course this was just a first pass (using the Juno code, btw).

Fast-forward a bit, and we decided to integrate this work. Since it was not a simple proof of concept anymore, we went ahead with some more serious testing. This resulted in us backporting patches for the Juno branch, but also making Nova behave a bit better since it wasn't aware of Docker as an hypervisor. This last point is a major problem if people want to use Docker as well as KVM, Xen, VMware or Hyper-V — the multi-hypervisor support is something that really matters to us, and this issue was actually the first one that got reported to us ;-) To validate all our work, we of course asked tempest to help us and the results are pretty good (we still have some failures, but they're related to missing features like volume support).

All in all, the integration went really smoothly :-)

Oh, I forgot to mention: there's also a docker plugin for heat. It's now available with our heat packages now in the Build Service as openstack-heat-plugin-heat_docker (Kilo, Juno); I haven't played with it yet, but this post should be a good start for anyone who's curious about this plugin.