Partiendo del servicio de Google Static Maps que nos ofrece la posibilidad de linkar a imágenes estáticas de GoogleMaps hice un script para generar un vídeo de aproximación a una localización cualquiera del mapa mundi.

Descargamos las 20 imágenes que brinda GoogleMaps correspondientes a 20 niveles de zoom.

20 imágenes

for n in `seq 1 20`; do nombre=`printf %0.3d00 $n`;wget "http://maps.google.com/maps/api/staticmap?center=Calle,0,Ciudad,Pais&zoom=$n&size=640x480&maptype=satellite&sensor=true" -O "satelite_"$nombre".png"; done

Esto produciría una serie de 20 JPGs para cada una de las escalas que sirve GoogleMaps, (satelite_00100.jpg, satelite_00200.jpg, satelite_00300.jpg …satelite_02000.jpg). Ahora interpolamos generando mediante un zoom unas 14 imágenes (elección arbitraria) entre fotograma y fotograma. Sigue leyendo…

Llevaba observando hace tiempo un comportamiento anómalo en Digikam pero que hasta el momento no había supuesto más problema que el de mera curiosidad, a saber: las fotografías se descargan de cámara sin respetar el orden en que fueron hechas. O mejor dicho: siguiendo otro orden al que fueron hechas.
Si descargamos una secuencia de fotografías numeradas desde la cámara con Digikam el programa descargaría dicha secuencia produciendo algo como: 2,1,3,5,4,7,6,9,8,11,10,12,14,13,16,15,18,17 (¿eres capaz de ver el patrón que sigue Digikam para desordenar las fotos?)

Hice un experimento para demostrar esto y publicarlo en KDEBugs.
Con imagemagick produje una secuencia de imágenes de números:
for n in $(seq 1 50); do \
convert -size 400x400 -background white -fill black -gravity center label:$n foto_$(printf %02d $n).jpg \
done
Esto produciría una secuencia de archivos foto_01.jpg foto_02.jpg foto_03.jpg … foto_50.jpg. Ahora los proyectamos en pantalla y los fotografiamos en orden.
mplayer -fps 1 mf://foto_*jpg
Ahora conecto la cámara y descargo las imágenes, lo que muestra Digikam para descargar es esto (nota que la secuencia empieza en el 2, no en el 1, estuve corto de reflejos)

Lectura desordenada de imágenes

Esto en condiciones normales apenas supondría un incordio, el problema surge si os ponéis a disparar timelapses, entonces el orden de los fotogramas es crítico y hay que recurrir a métodos de descarga alternativos.
Hay muchas maneras de descargar las imágenes respetando su orden. La más obvia (con ciertos límites*) es respetar el nombre del archivo con que lo generó la cámara. Para renombrar los archivos con la fecha de realización (y no verse limitado con la numeración máxima de 9999 de los cuatro dígitos) prefiero descargar las secuencias de fotografías con gphoto2:
gphoto2 -P --filename "/album/fotos/%Y%m%d/foto_%Y%m%H%M%S_%04n.jpg"

La criminalización del intercambio de archivos parece que va dando sus frutos, aunque no estoy seguro que sean las dulces manzanitas que alguno esperaría sino auténticos pepinillos del diablo, de esos que los tocas y te estallan en las narices.

El otro día Piratebay.org anunció que abandonaba el protocolo Torrent a favor del más reciente protocolo Magnet, que en cuanto a uso cotidiano viene siendo lo mismo que los archivos Torrent (de hecho la mayoría de los programas que estéis usando para descargar Torrents también trabajarán ya con Magnets) pero con la particularidad de que ahora la distribución de un documento no necesita un servidor que centralice las descargas.
Desde hace ya un par de semana que llevo descargando exclusivamente vía Magnet (usando Transmission bajo KDE) e ignoro si es por el efecto colateral de la caída de Megaupload, pero va echando leches y algo que antes era raro (películas de 1Gb en 3 horas) empieza a ser lo normal. Impresionante.

Los enlaces a Magnet se escriben del modo magnet:// y para que funcione correctamente la descarga automáticamente la descarga desde el navegador es necesario definir en KDE (en mi caso tanto en KDE3 como KDE4) el protocolo Magnet para vincular este con el programa de descargas (en mi caso Transmission).
Crea un archivo de texto con el siguiente contenido:exec=transmission "%U"
protocol=magnet
input=none
output=none
helper=true
listing=false
reading=false
writing=false
makedir=false
deleting=false
Icon=magnet
Class=:internetReemplaza en la primera línea transmission por el programa que quieras usar y guárdalo como /opt/kde3/share/services/magnet.protocol para kde3 ó /usr/share/kde4/services/magnet.protocol para kde4.
Listo, ya teneis registrado el protocolo magnet y cualquier URL que empiece por magnet:// será pasada a Transmission automáticamente.

Nota: aunque esta vinculación se puede hacer directamente en Firefox asociando protocolo-programa es necesario registrar el protocolo en el escritorio para que los enlaces funcionen en G.Chrome ó Konqueror/Dolphin.

Hay varias herramientas para crear GIF animados de un modo rápido y sencillo desde una consola. Probablemente la más simple y rápida sea Imagemagick, la herramienta estrella y más versátil para manipulación de imágenes desde un terminal.

Por ejemplo para hacer el GIF con el que el otro día os comentaba el origen del nombre de la boca de Dragón habría bastado con copias las imágenes a una carpeta y escribir en un terminal:convert secuenciaFotos*jpg -delay 10 resultado.gif

12 fotogramas del gif

El problema es que como la secuencia de fotografías la tomé sujetando la cámara con una mano (sin trípode) y la otra sujetando la flor, el movimiento, si bien no es muy perceptible en fotogramas fijos producía un tembleque muy antipático en el gif animado, así es que manipulé algo las imágenes antes de generar el gif buscando estabilizar algo es movimiento.

Sigue leyendo…

Pues básicamente porque uso GQview, un visor de imágenes tan viejo como simple y tan eficaz como rápido.

Pero si tuviera que cambiar una de mis últimas opciones sería un visor de imágenes como Qiviewer que se piensa durante un segundo la orden de abrir la imagen para acto seguido mostrar semejante mensaje:
«No puedo, abro ó aceptas?«. Manda cojones el diálogo y manda cojones que no pueda abrir un simple TIF, a estas alturas… momento Yepes-Nopes

No sé, me estaré haciendo viejo, pero cada vez soporto menos estas chorradas.
Hace cosa de un mes mandé también a KDEBug en forma de wishlist otra «joya» en este campo del diseño de interfaces.
Blending exposure es una herramienta perteneciente al paquete KipiPlugins y que acompaña a Digikam y cuya función principal es coger N número de fotografías y combinarlas fusionando sus exposiciones para obtener una imagen (algo así como un PseudoHDR). El problema es que para seleccionar las fotografías y mostrar un simple checkbox «Alinear imágenes» el paquete se marca nada más y nada menos que cinco ventanas de diálogo en las cuales básicamente tenemos que hacer «Siguiente >> Si >> Siguiente >> ok >> si».

Mockup propuesto en KDEBug

Señores desarrolladores: la función por antonomasia de un ordenador personal es realizar tareas tediosas y repetitivas para evitar que estas las hagan humanos y conseguir que estos dediquen su tiempo a oficios más espirituales y creativos que apretar-un-puto-botón-que-dirige-a-otro-botón.
Por favor!! no añadan diálogos del tipo «¿Que prefiere? Sí ó también?.«. Gracias