Ya lo he comentado por aquí muchas veces, para el archivo/clasificación de mis fotografías/vídeos soy fans incondicional de Digikam, gestor y editor de fotografías especialmente desarrollado para GNU/Linux y KDE pero también exportado desde unos años a MAC y Windows.
Los motivos son muchos, a continuación os demuestro como explotar dos de sus características más fundamentales: la clasificación por etiquetas y el uso de bases de datos SQLite.

La clasificación por etiquetas (tags) está muy extendida y popularizado y podéis verla en funcionamiento en casi cualquier servicio de gestión de álbumes fotográficos online como Picasaweb, Flickr ó mi propia galería de fotos/vídeos.
Consiste básicamente en asignar un término/expresión/clave a la imagen para posteriormente poder filtrar las búsquedas y de esta manera localizar rápidamente una imagen entre un millar.
La utilidad salta a la vista. En mi caso que vengo clasificando fotografías en Digikam desde que tengo cámara digital (2002) me permite encontrar cualquier foto en unos segundos entre las casi 60.000 fotografías que tengo clasificadas.

Digikam implementa desde sus inicios de un completísimo conjunto de herramientas desde los cuales el etiquetado de imágenes (y vídeos) es tremendamente fácil con un buen montón de funciones para etiquetado masivo, por jerarquías, anidadas, renombrar, mover, copiar, asignación/desasignación, automatización de tareas, búsqueda, filtrado, repetición, etc… Cada semana entre 100-300 fotografías/vídeos procedentes de las cámaras de fototrampeo entran en mi base de datos. Todos perfectamente etiquetadas por la especie/s de que se trate y el identificador de la cámara que lo grabó. De este modo puedo cuando quiera ver todos los vídeos que tengo de ginetas ó todos los grabados por la Cámara22A.
Arrancando Digikam podemos encontrar casi cualquier foto en segundos a base de filtrar por etiquetas, o por fecha, o por nombre, o por todo a la vez… pero ¿y si no queremos ni siquiera iniciar Digikam?

Acceso externo a la base de datos

Ventajas de software libre, Digikam guarda todos los datos en bases de datos en formato sqlite. Con algunos conocimientos de bases de datos sqlite y unos pocos de Firefox podemos en segundos hacer consultas a la base datos (ya hace tiempo expliqué por aquí con acceder a la base de datos para consultar la última fotografía alterada en la base de datos y generar con ella un splash dinámico).
Pero se puede hacer todavía más sencillo y en entorno gráfico dejando que sea Firefox y Bash quienes hagan el trabajo. A continuación os comento como activar un protocolo en Firefox que nos permita explorar las fotografías etiquetadas en Digikam desde una página web local que se generan de forma dinámica, de tal manera que en segundos podamos consultar/compartir alguna foto/vídeo sin siquiera salir del navegador web.

Protocolo para Firefox

Lo primero es pensar un nombre único para nuestro nuevo protocolo en Firefox. No valen ni http, ni ftp, ni file… :D Por motivos obvios mi protocolo se va a llamar digi://.
Lo que pretendemos hacer es que se nos muestre en Firefox las fotografías etiquetadas bajo una palabra simplemente escribiendo en la barra de dirección digi://gorrion

Abrimos Firefox y en la barra de dirección nos dirigimos a about:config (prometo no ser un manazas). Cliqueamos en el listamos y creamos tres claves nuevas booleanas (si/no las llama Firefox) (sí, una más de las que aparece en imagen).

Las tres claves a crear y sus valores son:(tipo si/no) network.protocol-handler.expose.digi -> false
(tipo si/no) network.protocol-handler.external.digi -> true
(tipo si/no) network.protocol-handler.warn-external.digi -> true
Donde digi es el nombre que hemos elegido para protocolo, podéis cambiarlo a vuestro antojo (claro, sin espacios ni símbolos especiales y preferiblemente corto)

A continuación, si tratamos de utilizar el recién creado protocolo escribiendo en la barra de dirección algo como digi://etiqueta el navegador nos preguntará qué programa queremos ejecutar para este protocolo. En el diálogo elegimos el script que vamos a crear a continuación.

Script BASH de búsqueda

Desglosar por partes el script sería muy extenso. Os comento de forma esquemática su funcionamiento y os pego el contenido del que yo mismo estoy usando para que los destripéis a gusto.

Cuando escribimos en la linea de dirección de Firefox una url con formato digi://cualquier-cosa se ejecuta este script.
Como variable $1 al script le llega la url completa (digi://cualquier-cosa). Descomponemos y nos quedamos con cualquier-cosa. Con este término realizamos una consulta a la base de datos de nuestra instalación de Digikam (si aún no tenéis instalado necesitareis instalar sqlite3). La orden sqlite3 que podéis ver en el script es sqlite3 "$bd" "SELECT b.relativePath || '/' || a.name FROM images AS a JOIN albums AS b ON a.album = b.id WHERE a.id IN (SELECT imageid FROM imagetags WHERE tagid IN (SELECT id FROM tags $condicional))" | sort
Esta orden nos devuelve una lista ordenada de archivos con PATH ABSOLUTO de todas las imágenes que Digikam tiene catalogados bajo la etiqueta cualquier-cosa (en realidad la orden es algo más compleja pero para no aburrir).

Una vez tenemos la lista de archivos construimos y generamos un HTML en /tmp y mandamos a Firefox que abra este archivo. Las imágenes son ampliables cliqueando y los vídeos reproducibles directamente en Firefox (mp4 embebido con tag VIDEO)

Limitaciones y extras

Como veis en realidad es proceso es muy sencillo ahora bien, tiene algunas limitaciones:
paginación: Hay que paginar (sí o sí) y limitar el número de imágenes/vídeos que se muestran por página. Tened en cuenta que los vídeos e imágenes se muestran tal y como los tenéis guardados. En mi caso fotos pueden ser fotos de 8000 pixels y vídeos MP4 de 1920 pixels. En cuanto le metáis a Firefox un página con muchos de estas imágenes y vídeos le va a venir un calentón de agarrate y no te menees (probado ayer: una página con 1600 fotos/vídeos de Garduñas lo dejan colgado cargando sin responder durante varios minutos).
Esta necesidad de paginar enfanga un poco el contenido del script que de no ser por así sería mucho más “limpio”.

Caracteres especiales: Todavía no me he puesto a arreglarlo, pero no debería ser muy complicado de arreglar. Caracteres especiales como ñ generan archivos con la codificación de caracteres erronea que no encuentra Firefox. Temporal. Por ahora lo soluciono buscando GARDU en lugar de GARDUÑA.

Busqueda condicional: Podéis buscar dos etiquetas al mismo tiempo usando la coma. Por ejemplo digi://gineta,tejon devolverá fotografias etiquetadas con alguna (condición OR) de estas etiquetas.

Formato de vídeo: Los vídeos se reproducen en Firefox siempre y cuando sean de formato compatible con la etiqueta HTML5 VIDEO. Con el plugin mplayerplug para Firefox/Linux los mp4 se reproducen perfectamente redimensionados y a pantalla completa.

CSS, en las primeras líneas del script tenéis las líneas de CSS para personalizar la presentación de las fotografías a vuestro gusto. No hay grandes florituras, pero bueno si queréis poner el fondo de color rojo es fácil.

velocidad, a cada solicitud se hace una consulta MYSQL y se generan uno o varios html en /tmp. Esto le puede llevar desde unas decimas a varios segundos. Haciendo búsquedas de varias miles de fotografías (2800) se demoró unos 11-12 segundos. Esto claro, varía entre una máquina y otra.

Descargar script bash

Podéis descargar y personalizar el script desde aqui.
Lo copiáis a vuestro ~/bin y lo haceis ejecutable (chmod +x ~/bin/digi.protocol). Cuando Firefox os pregunte con qué abrir el protocolo digi:// lo dirigís a este archivo. Y a jugar.

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

Bueno, esto es una pequeña ayuda de escritorio especialmente útil cuando tienes que manejar decenas ó centenas de vídeos en batería.
Periódicamente salgo al monte a recoger los vídeos/imágenes de las cámaras de fototrampeo que tengo repartidas. Depende del tiempo que pase entre visitas, de la configuración de las cámaras, de lo animado que esté el monte, etc.. pero habitualmente me suelo traer de vuelta en el teléfono tranquilamente 200 o 300 vídeos de 10-30 segundos. Toca visionarlos tranquilamente en el ordenador, por si se me hubiese escapado algo y clasificar/desechar el material. Normalmente descarto casi el 70%-80% de los vídeos que se graban.
La rutina de trabajo sería “por defecto” algo como: abrir la carpeta contenedora, reproducirlos en batería, memorizar nombre, volver a la carpeta, borrar, continuar con la lista de reproducción. Gracias a MPLAYER podemos hacer esto tan fácil como: reproducir lista de vídeos, borrar vídeo, pasar al siguiente.

MPLAYER, es un reproductor de vídeos/audio que dispone en su configuración de un modo esclavo que es tremendamente útil. Este modo esclavo (slave) permite a otras aplicaciones/scripts interactuar con la reproducción en curso de MPLAYER. El reproductor “escucha” este archivo y ejecuta los comandos recibidos tal y como haría desde su propia interfaz. Esto permitiría por ejemplo pausar/silenciar una película cuando se reciba un correo electrónico, o como en nuestro caso borrar el archivo que se esté reproduciendo tan solo como pulsar la tecla DEL.

Activar modo esclavo

Lo primero es activar el modo esclavo en MPLAYER. Para esto editamos (o creamos si no existe) el archivo config ubicado en la carpeta local de Mplayer ( ~/.mplayer/config ).
Añadimos las siguientes dos líneas: slave=1
input=file=/home/tu-usuario/.mplayer/tuberia

A continuación abrimos un terminal y creamos la tuberíamkfifo /home/tu-usuario/.mplayer/tuberia

Con esto basta para que cada vez que se inicie MPLAYER permanezca “a la escucha” de este archivo. Ahora durante la ejecución de una película podríamos pararla escribiendo en un terminal:echo "pause" > /home/tu-usuario/.mplayer/tuberia

Asignar función a la tecla

Edita el archivo de MPLAYER acceso rápidos de teclado ( /home/tu-usuario/.mplayer/input.conf ) y añade la línea:DEL run /home/tu-usuario/.mplayer/borrarActual

Script de eliminación de archivo en reproducción

Ahora creas el script que se ejecutará cada vez que pulsemos la tecla DEL durante la reproducción de un video/audio en MPLAYER, crea un archivo de texto en /home/tu-usuario/.mplayer/borrarActual con el siguiente contenido:#!/bin/sh
mplayerPID=$(pidof mplayer)
if [ "$(echo ${mplayerPID}|wc -w)" -ne 1 ] ; then exit 1; fi
IFS=$'\n'
for archivo in $(lsof -p ${mplayerPID} -Fn | grep -i -E -w 'avi|mp4|mp3|mov|mpg|ogg|3gp' | sed 's/^n//g') ; do
tuberia="/home/tu-usuario/.mplayer/tuberia"
if test -w "${archivo}" ; then
if [ -p "$tuberia" ]; then
echo "pt_step 1" > "$tuberia"
else
mkfifo "$tuberia"
fi
kioclient move "${archivo}" trash://
fi
done

Haz ejecutable el archivo con chmod +x /home/tu-usuario/borrarActual

El script busca el PID de mplayer en ejecución (sale si no hay solo 1 PID). Con este PID averiguamos la ruta del archivo en reproducción. Pasa al siguiente de la lista y mueve el archivo a la papelera (mejor que hacer RM, por si metemos la pata).

 
qRAE 0.4.2 es la primera versión que está disponible para los sistemas operativos Windows y Mac OS X. Está en fase experimental, sobre todo en Mac. La versión de Windows viene sin instalador; es un archivo comprimido en plan portable.

En relación a las anteriores versiones, viene con pequeñas mejoras y autocompletado de términos previamente consultados.

Os podéis bajar esta versión en la zona de descargas.

Nota: Si usas ONO, puede que no resuelva lema.rae.es. Como solución temporal, cambia tus DNS (ej: OpenDNS). Gracias a Eduardo Bohoyo por depurar el problema.

Una fotografía/vídeo estereoscópica es aquella técnica que permite reproducir la sensación de relieve y volumen de los objetos en quien contempla la imagen. La técnica básicamente consiste en hacer llegar a cada ojo del espectador dos imágenes ligeramente diferentes de tal manera que al procesarlas el cerebro recree la sensación de profundidad de la escena original.
Para conseguir esto hay multitud de técnicas más o menos exitosas, desde un simple GIF animado realizado con una sola cámara que muestra alternativamente el ojo izquierdo/derecho, hasta modernas técnicas cinematográficas de imagen a todo color, a gran resolución de imágenes perfectamente visibles con gafas especiales o sin ellas.
La técnica más primitiva consistiría por tanto en grabar dos imágenes al mismo tiempo y proyectarlas en paralelo para hacer llegar mediante un dispositivo a cada ojo la imagen que le corresponde. Sin embargo hacer llegar dos imágenes con calidad fotográfica y diferentes a cada ojo no es fácil (ni barato si se aspira a cierta calidad). Con el abaratamiento de la electrónica los cascos de realidad virtual se han vuelto razonablemente accesibles en los últimos años, pero aún siguen siendo raros y poca gente dispone de ellos habitualmente, pero lo que sí tiene mucha gente hoy en día es un smartphone, y aquí es donde entra el ingenio de algún ingeniero de Google ¿porqué no usar la pantalla del teléfono móvil y transformarla en un casco de realidad virtual? solo hace falta un poco de cartón, dos lentes y una tijeras y ya tenemos unas Google Cardboard.

Las Google Cardboard son básicamente un recortable de cartón dentro del cual instalamos el teléfono móvil que proyecta un vídeo partido en dos frames, uno para cada ojo (además de un ingenioso sistema de imán para transmitir “clicks” ar una aplicación en nuestro Android). Google distribuye los susodichos planos/instrucciones para construir tu propio casco de realidad virtual en casa y en Ebay las podéis comprar por 3-4 euros. Una vez tenemos nuestro casco de realidad virtual ya solo falta generar nuestro vídeo estereoscópico para el casco.

Vídeo estereoscópico

Como ya he contado muchas veces tengo en casa varias cámaras tipo CCTV. Desde que conseguí mis Google Cardboard llevo queriendo experimentar a juntar dos de estas cámaras y producir mis propias películas 3D caseras, y eso es lo que hice estos días pasados.
La conexión del hardware no tiene más truco, se cogen dos cámaras conectadas al ordenador con idéntico objetivo (6 mm en mi caso) se sitúan en paralelo (teóricamente con una separación de 63 mm entre el centro de ambos objetivos, que es la separación media entre pupilas) y se graban dos vídeos al mismo tiempo de todo lo que se quiera.

Problemas de calidad

La calidad de estas cámaras no es para tirar cohetes como os podéis imaginar, dan para un vídeo de 640×480 px y poco más. No lo que no me esperaba es que dos cámaras idénticas con idéntico objetivo y ubicadas en el mismo sitio dieran imágenes tan sorprendentemente distintas, no ya en nitidez/saturación/contraste (estos miniobjetivos si se les aprieta mucho la rosca del enfoque podemos hacer saltar hacer saltar las lentes por los aires con mucha facilidad. Ya he tenido que montar los cristalitos de algunos de estos objetivos varias veces.)… sino pura y simplemente en encuadre. Me explico: si situamos las dos cámaras una al lado de otra y grabamos a una persona a 2 metros con un encuadre tipo busto/retrato, si la cámara A la encuadra bien, la cámara B la encuadra de los ojos para abajo.

Esto es, como si una de las cámaras tuviera un ligero cabeceo hacia abajo y viera una porción de espacio por debajo de lo que veía la otra. Deduje que esto es muy probablemente producido por ligeras variaciones en la posición del sensor y en el cono de luz que proyecta el objetivo. Una variación de 1-2 mm produce un desplazamiento enorme en la imagen capturada (y no vale con “levantar” ó “agachar” algunas de las cámaras porque al cambiar la altura del centro del objetivo se produce un cambio en las perspectiva/paralelaje que desbarata cualquier intento de 3d).
Estuve probando diversas cámaras pero el resultado era siempre el mismo, no tengo dos cámaras que situadas de forma contigua graben lo mismo a la misma altura.

Después de diversas pruebas, incluida el intento de reajustas la posición del sensor interno de las cámaras opté por un solución salomónica: recortar la salida de ambas cámaras al área compartida por ambas, de tal manera que el fotograma válido por ambas cámaras pasaba de 640×480 a 640×332, se desechaba una franja de 148 en ambas cámaras, en una por arriba y la otra por abajo. Bueno, siempre me han gustado las panorámicas.

Software FFMPEG

Para la grabación y composición de la panorámica de vídeos he usado ffmpeg, un potente editor/conversor de vídeo en linea de comandos pero que ha traído otro pequeño problema: al tomar dos dispositivos y codificarlos a mp4 para producir la composición final producía un ligerísimo retardo (apenas 4-5 frames) en uno de los vídeos de manera que cualquier movimiento en la imagen se producía un poco antes en el ojo izquierdo que en el derecho. Aunque era un retardo muy pequeño, había que fijarse mucho para descubrirlo pero en cambio producía un efecto muy incomodo de falta de sincronía. Nada especialmente grabe que no se pudiera arreglar con la opción itsoffset desde el propio FFMPEG.

Estas son algunos de las líneas de comandos ffmpeg utilizadas para producir el vídeo estereoscópico:

Comando básico para reproducir un dispositivo conectado a la capturadora del ordenador
ffplay -s 640x480 -f v4l2 /device/video4

Capturar, componer y mostrar en tiempo real dos dispositivos de vídeo
ffmpeg -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -i /dev/video8 -filter_complex "[0]pad=iw*2:ih[a];[a]overlay=w" -b 2200k -f mpegts - | ffplay -

Retardar ligeramente el “ojo derecho”
ffmpeg -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -itsoffset 0:0:00.08 -i /dev/video8 -filter_complex "[0]pad=iw*2:ih[a];[a]overlay=w" -b 2200k -f mpegts - | ffplay -

Recortar (crop) fotogramas, corregir luminancia en ojo derecho y guardar a mp4
ffmpeg -y -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -itsoffset 0:0:00.08 -i /dev/video8 -filter_complex "[0]crop=640:340:0:140[a];[1]mp=eq2=0.8:1:0:2[b];[a]pad=iw*2:ih[a];[a][b]overlay=w" video_final.mp4

Todavía quiero hacer algunas pruebas, desplazando cámaras cambiando objetivos, etc.. pero ya se puede ver algo. Si tenéis las Google Cardboard o similar podéis ver el vídeo en grande en esta dirección.

Creo estar hace tiempo curado de versionitis informática, a saber: esa manía/costumbre/way-of-life de andar instalando/actualizando programas y sistemas operativos constantemente, de forma compulsiva y (sobretodo) innecesaria.O al menos yo lo intento, el problema es que los programas avanzan independientemente de lo que tu quieras hacer con tu consumismo informático y lleva un día en que si quieres probar algo que no existía dos años atrás no puedes porque directamente el mínimo exigido para funcionar está muy por arriba de donde tu te quedaste. Digikam, GIMP, etc.. hace ya tiempo que habían dejado de ser actualizables. Los repositorios oficiales de openSuse 11.4 fueron cancelados hace tiempo, aunque gracias a repositorios independientes y compilando por mi cuenta puede ir soluciando cuestiones.
A principios de Diciembre para probar ya no recuerdo que cosa, decidí que actualizarías las KDE y a partir de ahí ir actualizando hasta resolver todas las dependencias que surgieran. Todo bien hasta que llegó el momento de reiniciar y llegaron los problemas llegó el problema. Después del reinicio el sistema no arranca, ni produce pitido alguno, ni era posible acceder al SETUP de la BIOS. Con el polímetro mido la fuente de alimentación, que funcionaba correctamente. Quité todo los módulos de memoria (no pita), desconecté los discos duros (no pita), a la placa base parecía darle lo mismo que hubiera o no memoria y discos duros. Placa base muerta. Sospecho que el problema podría venir por la pila botón de la placa. Este ordenador, salvo que ocurra algo raro no se apaga nunca y prácticamente se reinicia una vez cada tres meses. Está montado sobre un SAI de 600W con lo que ni los cortes de luz lo apagan. Tengo el pálpito indemostrable de que la pila estaba agotada y fué responsable de que en el momento del reinicio se dañase el arranque de la BIOS. Probé a cambiar la pila, a resetear con hardware con los jumper de la placa pero con nulo éxito.
Nueva placa…, y claro, casi todo los adosados a ella. La nueva motherboard solo trae conexiones SATA, a mis discos ATA/IDE les dió la risa. La memoria RAM ya no es DDR2 con muesca en el pin 32 (es un decir) sino DDR3 con muesca en el pin 34. El socket del procesador también cambia. En fin, pude conservar la propia torre ATX, la fuente de alimentación, gráfica Nvidia y la capturadora. Todo lo demás es nuevo. Afortunadamente los discos duros están como nuevos y funcionan perfectamente por lo que en las últimas semanas ha tocado recuperar configuraciones y archivos al nuevo sistema y reconfigurar todo.

Ahora este servidor web de Cuaderno de campo corre un openSuse 13.2 a 64bits con ATHLON de cuatro núcleos a 4.3Ghz, 8Gb RAM, la misma Nvida de antes (GT630) y tres discos duros (2 SATA y IDE+Adaptador) que suman unos 2,3 Tb, mas su correspondiente DVD, lector de tarjetas, tarjeta TV de ocho canales para las webcams, USB 3.0, etc…

Lo nuevo en openSuse 13.2

Obviamente si vienes de openSuse 11.4 los cambios en el sistema son poca cosa pero algunos si que me han pillado por sorpresa.
Por ejemplo la distribución por defecto de las particiones de instalación del sistema han cambiado bastante. Ahora / se instala por defecto separado de /home (algo que ya hacíamos muchos antes de forma manual) y se pasa del sistema Ext2 ó Ext3 a BtrFS para root y XFS para /home

Xorg.conf también ha cambiado. De hecho es que ahora mismo ignoro completamente donde está mi viejo /etc/X11/xorg.conf donde se definía el entorno gráfico y periféricos del ordenador. Pero mira (y esto también es una novedad, y de las buenas) el reconocimiento de gráficos y auto-configuración ha funcionado de perlas. Ha reconocido tarjeta integrada y PCI-Express NVIDIA, 2 Monitores LCD con Twinview tan bien que no se ni donde está el archivo de configuración, ale!! a-lo-windows!! :)
Eso sí, tuve que instalar los drivers propietarios de NVIDIA porque los drivers libres de Nvidia-Nouveau no han cambiado, igual que antes siguen fallando.

El sorpresón de los buenos a sido comprobar que la capturadora TV de 8 canales de EBay que usaban en mis anteriores 32 bits sigue funcionando en 64bits. La daba casi seguro por muerta ya entonces el módulo BTTV del Kernel estaba muy obsoleto y abandonado, con lo cual las posibilidades de que siguiese vivo eran mínimas. Pero ahí sigue, vivo y funcionando igual de bien. Otra cuestión es MOTION, el programa de detección de movimientos, que también está abandonado desde 2011 y que no soy capaz de compilar con soporte FFMPEG por lo que ahora las cámaras ahora no graban vídeo, solo foto. Tendré que investigar más.

Ha cambiado también la ubicación donde se montan los dispositivos. Desaparece el /media/xxxxx a donde iba el pendrive/dvd y ahora se monta todo en /var/run/media/xxxx. Parece una tontería pero estos cambios en la ubicación de archivos comunes en el proyecto openSuse personalmente me crispan los nervios. No es /usr/local/bin sino /usr/bin, no es /usr/share sino /opt/kde. Si el programa viene de Debian probablemente se instale en /usr/share/, los de Google en /opt/google y los de Fedora en /usr/local/share. Ahora probablemente haya vuelto a cambiar. Conviene tenerlo en cuenta especialmente cuando se instalan librerías procedentes de otros sistemas ó “genéricas” y con las que acabas teniendo el disco duro con las librerías de Python repartidas como si las hubieses lanzado sembrando alfalfa.

He observado también cambios en archivos de sistema como syslog, la integración de UDEV y otros, pero que apenas he tenido tiempo de probar.

A tortas con KDE4

Ahora que para susto el primer inicio del KDE4. La configuración estética por defecto (nunca mejor traído lo de “defecto”) deja mucho que desear. OpenSuse necesita contratar algún director de arte de manera urgente, feo de cojones.
Ojo, no digo que openSuse/KDE4 sea en sí mismo feo sino el primer arranque, lo que uno se encuentra si deja al instalador solo trabajando 2 horas. Por suerte openSuse/KDE4 es suficientemente flexible como poder arreglarlo sin mucha dificultad en profundidad y a muchos niveles (espantoso color de las sombras de ventana, fuentes muy pequeñas, distribución del escritorio sosa y fea, fondo de escritorio pa-matar-a-alguien, etc…). Lamenté en su día dejar KDE3 y pasar a KDE4 y conforme avanza su desarrollo no termino de abandonar esa idea. KDE4 da sensación frágil e inestable. Ese follón escritorios virtuales llamado actividades soy incapaz de entenderlo y verle utilidad. Los widgets fallan si falla el escritorio y viceversa, ni te cuento como se te ocurra mover widgets entre dos monitores o la cantidad de veces que he tenido que escribir Cartagena en el Widget del clima, el panel de control de KDE4 (systemsettings) tiene organizadas las herramientas de una manera que no consigo memorizar o comprender por más años que pasen. En general el aspecto gráfico y ergonómico de KDE4 es muy mejorable, pero se salva porque sigue siendo el mejor (al menos de los que yo he probado: Gnome, XFCE, LXDE, FVWM, Windowmaker, IceWM )

Kwin (gestor de ventanas) a variado poco (afortunadamente) unicamente para integrar mejor los efectos con el sistema y hacerlos más estables. Funcionan realmente bien sin hacer nada.

Por fín ha exterminado aquel engendro del demonio que era Stigri/Nepomuk. Un proyecto muy ambicioso de búsqueda semántica en el escritorio pero que realmente convertía KDE4 en una puñetera locura de fallos, preguntas, molestias constantes al usuario y sobre todo un consumo de recursos bestial.
Lo viene a sustituir Baloo, que pretende los mismo pero con una configuración simplificada a un simple ¿Activar/Desactivar Baloo?.
Bueno, ni lo uso ni me usa, no me puedo quejar.

Bluetooth funciona perfectamente tal y como se instala. Conecta el teléfono con el PC y podemos enviar/recibir archivos con un click ó escuchar la música del teléfono por los altavoces del PC. Sin tocar ningún HCITOOL, Rfcomm ni configuración ninguna.

Cosas que hacer inmediatamente después de instalar openSuse 13.2

Instalar los repositorios de Packman (http://packman.inode.at/suse/openSUSE_13.2/Extra/). De los fundamentales donde encontraremos casi de todo.

Y Kaffeine sigue existiendo. Sip. Increíble pero cierto: el reproductor por defecto de KDE4 después de una instalación standard del sistema no es capaz de reproducir un MP4 ni un AVI/Divx sin emitir error con los codecs. Así es que lo primero es desinstalar Kaffeine e instalar un reproductor serio de vídeo sin florituras, MPLAYER, es perfecto. Lo abre todo sin pestañear. Basta definirlo como reproductor por defecto y listo. Solo vídeo.

Tres/cuartos pasa con el visor de imagen, no es normal que para ver un triste JPG haga doble click y se abra por defecto Gwenview (un navegador de álbumes multimedia), ó peor Showfoto/Gimp (editores) que se llevan 6-7 segundos en arrancar cuando lo que quiero en un 99% de los casos es simplemente ver la foto en grande.
Antés usaba GQview un visor para Gnome muy rápido y potente. Ahora me he pasado a Viewnoir, prácticamente igual. Muy rápido, abre cualquier formato de imagen y puedes configurarlo para que muestre únicamente la imagen, sin interfaz. La rueda del ratón y las teclas habituales permiten desplazarse por el resto de imágenes del directorio en que te encuentras, hacer zoom, rotar, etc…

Miniaturas de vídeos. Para mi gusto es fundamental que el icono de un vídeo permita identificar su contenido sin siquiera reproducirlo. Increíblemente KDE4 no instala ningún thumbnailer para vídeos a pesar de que hay dos que funcionan perfectamente y están en los repositorios habituales Mplayerthumbs y Ffmpeg-thumbnailer. En mi caso prefiero instalar una versión embellecida del primero que ya os enseñé por aquí hace la tira de tiempo.

Instalar SPOTIFY para hacer todo lo anterior con música es ahora mucho más fácil que antes que había que andar trampeando con un DEB de Debian para instalarlo, ahora se instala directamente desde los repositorios y YAST sin problemas.

Seguir leyendo →

Hace un tiempo en mis listado de aplicaciones fundamentales para Android os comentaba el servicio PushBullet. Para quien todavía no lo conozca es un servicio online que permite la compartición de archivos, fotos, enlaces y texto entre un servidor y varios clientes. Este servicio se instala como plugins (Firefox/Chrome), programa de escritorio (Windows) ó App (Android) en todos aquellos dispositivos que queramos que formen parte de una “red privada” y desde ese momento es absurdamente fácil enviar un PDF desde nuestro PC a nuestro teléfono, un ZIP al teléfono de un amigo, o un POWERPOINT lleno de malware al escritorio de nuestro jefe. Y viceversa.
Faltaba una aplicación de escritorio para GNU/Linux, pero puesto que los desarrolladores de PushBullet han tenido a bien habilitar el acceso al servicio con una sencilla API de acceso veréis como integrar PushBullet en el menú de contexto del ratón en KDE4 (y por extensión en cualquier otro escritorio Linux) es coser y cantar.

La idea es activar una acción en el menú de contexto del ratón en KDE4 que permita mediante un simple click enviar un archivo de cualquier tipo a nuestro móvil.

1. Regístrarse e instalar app

Obviamente lo primero es estar registrado en el servicio. Gratuito.
Después de registrarte instala la applicación oficial para Android. Asegúrate de que todo funciona correctamente y puedes enviar/recibir archivos desde tu escritorio al móvil usando la página https://www.pushbullet.com y viceversa.

Una vez tienes todo instalado y funcionando correctamente necesitas obtener dos datos: tu token de Acceso y el Identificador de dispositivo en Pushbullet del móvil al que quieres enviar los archivos desde el escritorio. El token de acceso lo tienes aquí (guárdalo para usarlo más adelante).
El Identificador de dispositivo de tu móvil en Pushbullet lo obtienes en la página principal de Pushbullet.
A la izquierda verás la lista de dispositivos que tienes conectados (uno ó varios), cliquea sobre uno de ellos y verás que la url del navegador cambia a algo como
https://www.pushbullet.com/?device_iden=asdf1234asdf1234
lo que va después del signo igual (en negrita) es el ID de tu dispositivo. Apuntalo para usarlo más adelante.

Ninguno de estos dos datos deberías compartirlos públicamente.

2. Script bash de subida

El script es muy sencillo. Con las credenciales obtenidas anteriormente sube cualquier archivo al servidor PushBullet en Amazon. Después de subirlo obtiene la url del archivo y la envía al móvil. Al teléfono entonces nos llega un aviso con un enlace a dicho archivo, ó la imagen (caso de tratarse de un GIF, PNG, JPG) ó archivo de audio, etc, etc…

Descarga el script bash desde aquí, guárdalo y edita.
Donde pone:tokenA="1234asdf1234asdf1234"
Reemplaza y pon tu token de Acceso que obtuviste anteriormente
Donde pone passwordPushBullet="12345678"
Pon tu contraseña de acceso a Pushbullet
Donde pone dispositivo="12345678qwerty"
Reemplaza y pon tu Identificador de dispositivo obtenido anteriormente.

Guárdalo en (p.ejem) /home/tu-usuario/bin/pushbullet.sh y hazlo ejecutable (chmod +x /home/tu-usuario/bin/pushbullet.sh).
Listo, ahora puedes abrir un terminal y escribir pushbullet.sh /home/tu-user/Desktop/imagen.jpg
Si el primer argumento es un archivo el script lo sube al servidor de PushBullet e inmediatamente te lo envía al teléfono. Si no es un archivo porque por ejemplo has escrito pushbullet.sh "Hola amigos, esto es una prueba" el script lo envía al teléfono directamente como si fuese una anotación. Esto es especialmente útil para enviar largos párrafos de texto al móvil.

3. Personalizar menú de contexto KDE4

Para insertar Pushbullet en el menú de contexto del ratón de KDE4 y que aparezca sobre cualquier archivo.

Abre un editor de texto y pega el siguiente contenido:[Desktop Entry]
X-SuSE-translate=true
Encoding=UTF-8
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=pushbullet
Name=Enviar
Icon=web
[Desktop Action pushbullet]
Name=Móvil via PushBullet
Exec=pushbullet.sh "%f"
Icon=pushbullet
Guardalo en /home/tu-usuario/.kde4/share/kde4/services/pushbullet.desktop. En adelante basta hacer click derecho sobre un icono de archivo y seleccionar Acciones > Móvil via PushBullet para que casi de forma inmediata aparezca en tu teléfono el archivo. (el menú de contexto puede requerir algunos reintentos sobre iconos para que se actualice la caché de KDE4 y aparezca el nuevo menú).

4. Cosas a mejorar

– Barra de progreso: No hice ninguna barra de progreso para la subida porque el envío es tan inmediato y rápido que casi se tarda más en abrir/cerrar el diálogo que en recibir el archivo. Pero quizás si estáis pensando en enviar archivos muy grandes si sería interesante añadir algún diálogo de subida.
– Errores: Idem de lo anterior. Si algo no funciona el script no avisa ni advierte. Tocará examinar en consola donde está el fallo. Normalmente algún token/password mal escrito.
– Subidas múltiples. Actualmente el script solo procesa un archivo en cada ejecución. Si se seleccionan varios se lanzarán varias instancias al mismo tiempo y en este punto ignoro cuales son las limitaciones del servicio de PushBullet. Si no os da por enviar 10 películas de 600Mg al mismo tiempo no debería haber problemas.