Un timelapse es una secuencia de fotografías tomas a intervalos regulares y procesadas posteriormente para componer con ellas una secuencia de vídeo. Hasta ahí todo claro. El problema es que para que la secuencia de vídeo tenga cierta continuidad, suavidad y aspecto “real” hay cumplir una serie de requisitos. La exposición fotográfica y el control del balance de blancos en la cámara debe ser dispuesta en modo manual de lo contrario los continuos ajustes que la cámara haga entre fotograma y fotograma provocarán una película llena de “saltos” en la luz de la escena, algunos muy sutiles y otros auténticas verbenas de luces.
El verdadero problema es que incluso estableciendo estos controles en manual estos saltos de luminancia, por otras cuestiones, siguen apareciendo. Es raro que una réflex haga en idénticas condiciones 250 fotos exactamente iguales y que no “salten” al verlas en formato de vídeo (parece que este defecto solo afecta a las réflex no a compactas por lo que muy probablemente se deba a pequeñas imprecisiones del diafragma del objetivo, reflejos internos de luz en el visor, etc… ).
Es el llamado “flickeo” de un timelapse, pequeñas variaciones de luz entre fotogramas contiguos que provocan que el vídeo “parpadee” muy sutilmente resultando extremadamente molesto.

Herramientas deflicker

Para evitar este “flickeo” aparecen las herramientas de “deflicker“. Básicamente son script muy sencillos que toman la secuencia de fotografías (ojo fotos originales, no vídeo resultante) analizan la luminancia de los fotogramas con sus “vecinos” y la alteran para amortiguar estos saltos de luz. Sigue leyendo…

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?

Sigue leyendo…

Cuando un dispositivo que funciona a pilas enciende la señal de “pilas agotadas/reemplace pilas“, lo normal es que le hagamos caso, quitemos las pilas usadas y pongamos otro paquete de pilas nuevas. Ahora bien, la pilas que acabamos de quitar están todavía muy lejos de “estar muertas“. Si hablásemos con corrección la mayor parte de las veces deberíamos decir que las pilas están casi nuevas o muy nuevas.

NotaAunque este apunte vaya dirigido hacia el caso concreto de las cámaras de fototrampeo esto es con toda probabilidad aplicable a muchos otros dispositivos caseros que funcionen a pilas.

Cuando jugando con el polímetro descubrí como “de frescas” salían las pilas después de que la cámara dijese que estaban agotadas me fui de cabeza al cubo de basura para las pilas que tenemos en casa y rescaté casi 70-80 pilas que allí tenía, las clasifiqué una a una por nivel de voltaje (±1.3v / ±1.0v) y desde entonces (va para 8-9 meses) que estoy viviendo de “pilas gastadas” (y lo que queda).

Cámara y cable de portapilas externo

Las cámaras de fototrampeo (al menos los cuatro modelos que estoy usando actualmente) usan 8 pilas AA repartidas en dos compartimentos (cámara y respaldo). Estas 8 pilas proveen de una autonomía teórica de aproximadamente 6 meses, en stand-by. Lógicamente lo normal es que la cámara no esté 6 meses a la espera (de lo contrario tu zona es realmente pobre en vida fauna) sino que detecte actividad y entre en funcionamiento mucho antes. Como puedes suponer entonces, la duración real de las baterías reduce de acuerdo a la cantidad de actividad y al modo de funcionamiento elegido para la cámara.

Consumo de las trailcam

De todos los modos que disponen estas cámaras (foto, vídeo, foto nocturna, vídeo nocturno, timelapse) el modo en que más consumen es el de grabación de vídeo nocturno (luces y grabación contínua). Según mi experiencia una cámara de trampeo como ACCORN LTL 5210 cargada 8 pilas AA nuevas de marca blanca puede generar alrededor de 500 fotos + 500 vídeos de 20 segundos antes de apagarse. A partir de ese momento, la cámara dejará de funcionar.

Sigue leyendo…

Desde que escribí el artículo del Arduino controlando el riego en el patio de casa se ha convertido en uno de los apuntes más visitados, y de los que más preguntas y confusión han generado, especialmente en lo referente a servir los datos de nuestra estación Arduino en una página web y desde ella dar órdenes a la placa.
Voy a tratar de explicar como y porqué lo tengo yo instalado sin enrollarme demasiado.

En la imagen una captura de pantalla de la página de control de mi CCCP (Centro de Control Centralizado Patiota, un poco de pitorreo siempre viene bien) desde donde puedo consultar el estado del patio y dar algunas órdenes (regar, pulverizar, alimentar peces y encender luz del patio – Interruptor 3).
Esta página contiene NO está generada por Arduino si no por mi propio ordenador (servidor web GNU-Linux) que es el que sirve los datos, realiza el control de visitas/autentificación, genera archivos de registro/log y estadísticas (temperatura, humedad, etc… ), compone la página y todo su código correspondiente (css/javascript/php), y permite dar órdenes sencillas al Arduino (p. ejem: riega 10 segundos) pulsando un botón pero siempre después de realizar comprobaciones de autentificación y funcionamiento (p. ejem: antes de ordenar a Arduino que riegue hay que comprobar que no está ya regando, o pulverizando o que por error no le hemos dicho “riega durante 3 días”).

Inconvenientes

Todo este trabajo si bien podría (teóricamente, aunque esto no es estrictamente cierto) hacerlo Arduino es del todo desaconsejable por varios motivos:
1/ Arduino carece de la potencia necesaria para atender un volumen bajo-muy bajo de visitas. Si trabajáis con la tarjeta Ethernet notaréis en seguida como sube la temperatura de esta en cuanto le solicitáis que haga algo muy sencillo.
2/ La estabilidad de Arduino cuando tienen que atender muchas visitas se resiente y la placa se resetea si el volumen de trabajo aumenta.
3/ Hacer que Arduino sirva todo el código HTML de la página de control, además del enorme volumen de trabajo que le supondría sería impracticable cada vez que quisiéramos realizar un cambio mínimo en la página. Imagina tener que cambiar algún detalle del código HTML tener que descolgar el Arduino del patio, conectarlo a tu ordenador, subir a la placa el nuevo código, probarlo, volver la placa a su sitio. Una verdadera locura.

Sigue leyendo…

Llevaba tiempo queriendo instalar un interruptor así y me ha costado lo mio, porque a mis nulos conocimientos de electrónica se suma la poca documentación que he encontrado sobre estos dispositivos, pero bueno, el que la sigue la consigue y probando conseguí hacerlo funcionar.
Estas son las tripas de mi circuito (otro día pongo el esquema y explico como funciona) al que le acabo de añadir un micro-interruptor con dos posiciones (esa cosilla azul-celeste del centro).

Tripas del sensor

La idea es la siguiente: una vez que me llevo el sensor de movimiento al monte poder alternar el funcionamiento del dispositivo entre varias opciones preseleccionadas y predefinidas en el código sin tener (como hasta ahora) que andar modificando y recargando el código en el ordenador antes de salir de casa de acuerdo a lo que fuese hacer en ese uso. Con este interruptor de dos posiciones se obtienen cuatro combinaciones posibles: interruptores ON/ON, ON/OFF, OFF/ON, OFF/OFF.
De este modo podemos precargar con cuatro modos de funcionamiento y alternar entre ellos en cualquier sitio y momento tan solo cambiando un interruptor (eso sí, muy pequeño, hace falta un boli para alcanzarlo).
El esquema es muy sencillo, solo necesitáis 1 resistencia de 1kΩ por cada interruptor (en el esquema he usado dos piezas cuando en realidad es una pieza+dos interruptores, para el caso esto es indiferente).

Esquema interruptor

Con esto instalado bastaría el código que lee los interruptores al inicio sería :int pinConmutadorA = 6;
int pinConmutadorB = 5;
void setup() {
int conmutadorAVal = digitalRead(pinConmutadorA);
int conmutadorBVal = digitalRead(pinConmutadorB);
if (conmutadorAVal == 1 && conmutadorBVal == 1) { int modoConmutadores = 1;}
if (conmutadorAVal == 1 && conmutadorBVal == 0) { int modoConmutadores = 2;}
if (conmutadorAVal == 0 && conmutadorBVal == 1) { int modoConmutadores = 3;}
if (conmutadorAVal == 0 && conmutadorBVal == 0) { int modoConmutadores = 4;}
}

Los interruptores los compré en Electrónica Embajadores a 0,6 €.