He querido hacer la prueba de una función en C usando la API de GNU Octave. Ésta debe devolver un vector columna luego de calcular los valores de una serie cuya longitud no se conoce de antemano. Por tal razón, hay que construir primero una lista mientras se calculan los valores de la serie, y terminada la secuencia, convertir la lista a un vector columna. Desafortunadamente no encontré ninguna función que hiciera esta conversión, y tuve que hacerlo con la ayuda de un ciclo.
La función en cuestión obtiene la sucesión de Collatz, que se obtiene de manera iterativa comenzando por cualquier número entero n aplicando la operación siguiente:

- Si n es par, f(n) es n/2;
- si n es impar, f(n) es 3*n + 1

…y aplicando la misma función f al resultado de la operación precedente. Obviamente la manera más natural de escribir una tal función en C es de manera recursiva; sin embargo opté por la forma iterativa equivalente. La conjetura de Collatz establece que esta sucesión alcanzará siempre el valor 1, condición que se usa como salida del bucle while:

ctam@dirac:~/c$ cat collatz.cc
#include
#include

DEFUN_DLD (collatz, args, nargout, “Collatz”)
{
int a = args(0).int_value();
int i;
octave_value_list retval;
retval.append((octave_value)a);
while (a > 1)
{
if (a % 2 == 0)
a = a / 2;
else
a = 3*a + 1;
retval.append((octave_value)a);
}

int l = retval.length();
ColumnVector c(l);
for(i=0; i < retval.length(); i++)
{
c(i) = retval(i).int_value();
}

// octave_stdout << retval(0).int_value() << "\n";
return octave_value(c);
}

Luego compilamos este archivo fuente C++ con la ayuda del comando mkoctfile. Debe estar instalado el paquete que contiene los encabezados de GNU Octave; en mi caso, es octave3.2-headers (Debian Sid).

ctam@dirac:~/c$ mkoctfile collatz.cc

Seguidamente, movemos el binario .oct generado a un directorio que Octave tomará en cuenta al momento de invocarlo:

ctam@dirac:~/c$ mv /home/ctam/c/collatz.oct /usr/lib/octave/packages/3.2/test/

Este último directorio está en el camino de búsqueda de Octave; esto se logra incluyendo esa cadena en el archivo .octaverc en el argumento de la directiva addpath.

Así, y ya dentro de GNU Octave, al invocar la función con un argumento numérico entero, obtenemos la respuesta en forma de vector columna:

octave:1> collatz(20)
ans =

20
10
5
16
8
4
2
1

Se justifica escribir esta función en C ya que es mucho más rápido ejecutar
un binario obtenido de esa forma que programar la misma función en
Octave. De esta forma, ya podemos usarla para investigar las propiedades de esta intrigante conjetura.

Muchas veces, al tomar una fotografía, observamos que la imagen final presenta cierta distorsión; las líneas que sabemos que son rectas, aparecen ligeramente curvadas, la imagen parece más abultada en el medio que en los bordes, y posiblemente veamos que detalles cercanos a éstos se perciben un tanto alargados.

En el mundo del software libre existe una biblioteca escrita con el fin de rectificar estos y otros artefactos introducidos por el lente; se trata de lensfun, la cual provee una base de datos de lentes y sus características. Esta biblioteca es capaz de aplicar algoritmos de corrección de imagen basándose en tales datos, a saber, las propiedades del lente y datos de calibración. La biblioteca lensfun está diseñada para corregir la distorsión, aberraciones cromáticas transversales, viñeteo y la contribución de color del lente. Mayor información sobre esta biblioteca escrita en lenguage C puede encontrarse aquí.

Afortunadamente, y para menor esfuerzo de nuestra parte, Sebastian Kraft se ocupó de escribir un complemento para GIMP llamado GimpLensfun, el cual toma en cuenta la corrección de la distorsión. La implementación en este plug-in de otras características de lensfun queda a la tarea del lector

Para instalar este complemento, remitimos al lector, si éste no usa Debian, a la página del enlace anterior. En caso de usar esta distribución -al menos en su rama inestable- basta con ejecutar como root

aptitude install gimp-lensfun

…y reiniciar GIMP para que el complemento se encuentre instalado y operativo.

El acceso a GimpLensfun se obtiene mediante el menú contextual

Filtros->Realzar [Enhance]->GimpLensfun...

Para usarlo, elegimos una imagen distorsionada por el lente usado para tomarla, y al hacer clic sobre ella con el botón derecho del ratón, escogemos GimpLensfun, el cual hace desplegar una ventana similar a la siguiente:

El primer parámetro solicitado es el fabricante de la cámara. En el caso de la imagen que usaremos, se trata de Canon. Seguidamente viene el modelo de la cámara; desafortunadamente nuestro modelo PowerShot SX10IS no está listado en la versión usada (0.1.1). Sin embargo, al elegir un modelo parecido (S1 IS) y un lente “Standard” como tercer parámetro, obtenemos un resultado aceptable. El cuarto parámetro es el más importante, y se trata de la longitud focal del lente utilizado en la toma; cinco milímetros en nuestro caso. La opción “Scale to fit” permite escalar la imagen de tal manera que llene el lienzo original.

Presentamos la imagen original; basta con pasar el cursor encima de ésta para visualizar el resultado. Para los curiosos, fue usado el complemento de WordPress llamado “IMG Mouseover”.

Si alguna vez deseamos instalar en GNU Octave el paquete de funciones WAVELAB 850 de Matlab, desarrollado en la Universidad de Stanford, y dedicado al procesamiento de señales, aprovechando la compatibilidad parcial entre estos dos lenguajes de cálculo científico, podemos proceder como sigue:

- Descargamos el archivo WAVELAB850.ZIP:

# cd ~
# wget http://www-stat.stanford.edu/~wavelab/Wavelab_850/WAVELAB850.ZIP

- Descomprimimos dicho archivo en el directorio donde se encuentran los paquetes de funciones de GNU Octave, en nuestro caso (Debian Sid, versión de GNU Octave 3.2.4), /usr/share/octave/packages/3.2:

# cd /usr/share/octave/packages/3.2
# unzip ~/WAVELAB850.ZIP

- Ya como nuestro usuario, procedemos a agregar en el camino de búsqueda de GNU Octave los nuevos directorios creados, y que contienen las funciones que nos interesan:

$ octave
GNU Octave, version 3.2.4
Copyright (C) 2009 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
Octave was configured for "x86_64-pc-linux-gnu".
Additional information about Octave is available at http://www.octave.org.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html
Report bugs to  (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).
For information about changes from previous versions, type `news'.
octave:1> addpath("/usr/share/octave/packages/3.2/Wavelab850/Biorthogonal/")
octave:2> addpath("/usr/share/octave/packages/3.2/Wavelab850/Books/")
octave:3> addpath("/usr/share/octave/packages/3.2/Wavelab850/Browsers/")
octave:4> addpath("/usr/share/octave/packages/3.2/Wavelab850/Continuous/")
octave:5> addpath("/usr/share/octave/packages/3.2/Wavelab850/Datasets/")
octave:6> addpath("/usr/share/octave/packages/3.2/Wavelab850/DeNoising/")
octave:7> addpath("/usr/share/octave/packages/3.2/Wavelab850/Documentation/")
octave:8> addpath("/usr/share/octave/packages/3.2/Wavelab850/FastAlgorithms")
octave:9> addpath("/usr/share/octave/packages/3.2/Wavelab850/Fractals/")
octave:10> addpath("/usr/share/octave/packages/3.2/Wavelab850/Interpolating/")
octave:11> addpath("/usr/share/octave/packages/3.2/Wavelab850/Invariant/")
octave:12> addpath("/usr/share/octave/packages/3.2/Wavelab850/Median/")
octave:13> addpath("/usr/share/octave/packages/3.2/Wavelab850/MEXSource/")
octave:14> addpath("/usr/share/octave/packages/3.2/Wavelab850/Meyer/")
octave:15> addpath("/usr/share/octave/packages/3.2/Wavelab850/Orthogonal/")
octave:16> addpath("/usr/share/octave/packages/3.2/Wavelab850/Packets/")
octave:17> addpath("/usr/share/octave/packages/3.2/Wavelab850/Papers/")
octave:18> addpath("/usr/share/octave/packages/3.2/Wavelab850/Pursuit/")
octave:19> addpath("/usr/share/octave/packages/3.2/Wavelab850/TimeFrequency/")
octave:20> addpath("/usr/share/octave/packages/3.2/Wavelab850/Utilities/")
octave:21> addpath("/usr/share/octave/packages/3.2/Wavelab850/Workouts/")
- Procedemos a grabar de manera permanente los caminos agregados:

octave:22> savepath
warning: savepath: current path saved to ~/.octaverc

- Salimos del interpretador GNU Octave y descargamos algún archivo de serie temporal para probar alguna de las funciones recientemente añadidas:

octave:23> exit

$ wget http://robjhyndman.com/tsdldata/data/kobe.dat

Este archivo contiene una serie temporal de la aceleración vertical en nm/s^2 del terremoto de Kobe, registrada en la Universidad de Tasmania, Hobart, Australia, el 16 de enero de 1995, y que comienza a las 20:56:51 (GMT), grabada durante 51 minutos a intervalos de 1 segundo. Fuente: Centro de Manejo de Datos, Universidad de Washington.

$ octave

[...]

octave:1> load kobe.dat

octave:2> spectrum(kobe)

La llamada a esta función calcula la densidad espectral de la señal contenida en el archivo bajo forma de serie temporal, graficándola al mismo tiempo:

Una llamada a la ayuda sobre esta función nos da más información acerca de ésta:

octave:3> help spectrum
`spectrum' is a function from the file

/usr/share/octave/packages/3.2/Wavelab850/spectrum.m

SPECTRUM Power spectrum estimate of one or two data sequences.
P=SPECTRUM(X,NFFT,NOVERLAP,WIND) estimates the Power Spectral Density of
signal vector X using Welch's averaged periodogram method. The signal X
is divided into overlapping sections, each of which is detrended and
windowed by the WINDOW parameter, then zero padded to length NFFT. The
magnitude squared of the length NFFT DFTs of the sections are averaged
to form Pxx. P is a two column matrix P = [Pxx Pxxc]; the second column
Pxxc is the 95% confidence interval. The number of rows of P is NFFT/2+1
for NFFT even, (NFFT+1)/2 for NFFT odd, or NFFT if the signal X is comp-
lex. If you specify a scalar for WINDOW, a Hanning window of that length
is used.

[P,F] = SPECTRUM(X,NFFT,NOVERLAP,WINDOW,Fs) given a sampling frequency
Fs returns a vector of frequencies the same length as Pxx at which the
PSD is estimated. PLOT(F,P(:,1)) plots the power spectrum estimate
versus true frequency.

[P, F] = SPECTRUM(X,NFFT,NOVERLAP,WINDOW,Fs,Pr) where Pr is a scalar
between 0 and 1, overrides the default 95% confidence interval and
returns the Pr*100% confidence interval for Pxx instead.

SPECTRUM(X) with no output arguments plots the PSD in the current
figure window, with confidence intervals.

The default values for the parameters are NFFT = 256 (or LENGTH(X),
whichever is smaller), NOVERLAP = 0, WINDOW = HANNING(NFFT), Fs = 2,
and Pr = .95. You can obtain a default parameter by leaving it out
or inserting an empty matrix [], e.g. SPECTRUM(X,[],128).
[...]

A veces necesitamos conocer datos como nuestra posición, altitud y velocidad en una medición puntual. Gracias a los sensores GPS integrados a la mayoría de los teléfonos inteligentes actuales, esto se vuelve muy fácil, en particular con dispositivos Android. Dos aplicaciones que me han resultado simpáticas a este respecto son GPS Test y GPS Status, que, como sus nombres lo indican, sirven para probar el GPS integrado, obteniendo así los datos que nos interesan, y algunas otras cosas más.

La primera de estas aplicaciones que probé fue GPS Test, de Chartcross Ltd., versión 1.2.1, cuya pantalla de presentación es la siguiente:

En su pantalla inicial, muestra el estado del sensor GPS (encendido o apagado), la precisión en metros, (o en pies, si elegimos unidades imperiales en la configuración), así como un diagrama SNR (relación señal/ruido) de los satélites GPS visibles al sensor. Cada barra representa un satélite, etiquetado por su número del sistema GPS correspondiente en la parte inferior, siendo la cifra en la parte superior de la barra la relación señal/ruido de dicho satélite. La barra horizontal debajo del mencionado diagrama representa la leyenda de la relación señal/ruido, ilustrada mediante colores, yendo del rojo (ninguna señal) hasta el color verde (de 40% hasta 99% de SNR). Debajo de esta barra se encuentran cuatro botones táctiles que llevan a otras tantas pantallas.

El primer botón táctil cambia la pantalla entre la vista inicial descrita y la vista de la ubicación de los satélites GPS en el mapa del cielo visible. La brújula de hardware asiste a la aplicación para orientar en la dirección Norte-Sur el mapa del cielo, el cual está compuesto de círculos concéntricos: el de mayor diámetro representa el horizonte del observador, mientras que en el centro del mapa se sitúa el cenit (el punto justo sobre el observador, siendo la recta que los une perpendicular al plano tangente a la Tierra en ese punto). Cada satélite se representa por un círculo, siendo válida la leyenda arriba descrita. Es de notar que el color gris denota el hecho de que el satélite es visible para el dispositivo, pero no habiendo efectuado todavía el GPS fix, su señal no es aún aprovechable. En la parte superior izquierda, se muestran cuántos satélites están visibles, y en la parte superior derecha, cuántos están en uso por el dispositivo. En la imagen de ejemplo, el programa muestra ocho satélites visibles y 6 en uso real, siendo la relación señal/ruido no muy buena, ya que se encuentra entre 20% y 40% (color amarillo), pero que sin embargo es suficiente para obtener las coordenadas espaciales 2D (mínimo tres satélites) y 3D (mínimo cuatro satélites), siendo la tercera dimensión la altitud sobre el nivel cero del elipsoide considerado, o nivel del mar teórico.

 

El segundo botón táctil sirve para cambiar entre la pantalla del mapa de la constelación GPS y la que muestra las coordenadas y el mapamundi. En esta última, las coordenadas (latitud y longitud) se muestran en la parte superior, mientras que en el centro se encuentra el mapa de las regiones del planeta iluminadas por el Sol (día) así como las áreas de plena oscuridad (noche) para el momento de la adquisición de los datos. También se ubican la posición en la que el Sol está perpendicular a la Tierra (mediodía) y la posición del observador, representada por un punto rojo, y el sistema de coordenadas utilizado (WGS84).

El tercer botón cambia entre la pantalla anterior y la de velocidad, dirección (rumbo) y altitud. La velocidad en km/h con una precisión de un decimal es mostrada en un recuadro grande, mientras que la dirección del dispositivo con respecto al Norte en grados sexagesimales y la altitud en metros se muestran en dos recuadros más pequeños debajo del primero:

Por último, el cuarto botón cambia entre la anterior y la pantalla de fecha y hora, la cual muestra en tres filas de dos recuadros cada una los datos siguientes: fecha y hora UTC (Universal Time Coordinate, antiguamente llamada hora de Greenwich o GMT), fecha y hora local, y las horas de salida y puesta del Sol:

En el menú Settings, accesible desde el botón Menú del dispositivo, pueden cambiarse algunos parámetros, tales como el esquema de colores usado, los formatos de coordenadas y las unidades de fecha, hora, velocidad, altitud y rumbo. No se puede cambiar el datum (el modelo de elipsoide usado) en la versión gratuita de la aplicación, que queda fijada a WGS84 (World Geodetic System 1984).

Pasamos ahora a GPS Status, una aplicación a nuestro juicio un poco más completa. En una sola pantalla, a pesar de carecer de un mapa de regiones iluminadas, proporciona tanto el mapa de la constelación de satélites GPS, la relación señal/ruido cuya leyenda es muy similar a la de la aplicación anterior: el diagrama SNR aparece como una barra delgada transversal en la mitad de la pantalla, el color amarillo denota un satélite no usado, el color verde un satélite usado por el dispositivo. Aparecen igualmente una pequeña brújula central cuyas agujas roja y azul apuntan respectivamente al Norte magnético y al Sur magnético, y una brújula más grande cuyas flechas apuntan al Norte y al Sur reales. Se indican en las esquinas del mapa las magnitudes siguientes: rumbo en grados, orientación en combinación de puntos cardinales, el error o precisión en la posición de la medición mediante GPS, y el número de satélites usados con respecto al número de satélites vistos por el dispositivo.

Superpuesto al mapa de los satélites, aparece un círculo amarillo ocre que indica la inclinación/ladeo del dispositivo con respecto al plano horizontal, y que por tanto hace las veces de nivel. Este círculo desaparece al adoptar el dispositivo una posición totalmente vertical, coincidiendo la pequeña circunferencia verde con el centro del mapa.

Debajo de la barra SNR aparecen los datos siguientes: inclinación y ladeo en grados, luego tres cifras separadas por / que indican la magnitud del campo magnético medida, la magnitud del campo magnético según el modelo geomagnético usado por la aplicación en la ubicación del observador (ambas en microteslas), y la declinación del vector campo magnético medida con respecto al norte magnético. Siguen en otra fila: la aceleración expresada en g (g=~9,81 m/s^2), la velocidad en km/h, la altitud en metros y la hora de la última medición. En la fila siguiente se encuentran las coordenadas, latitud y longitud, y finalmente en la cuarta línea, la carga de la batería junto con su temperatura y tensión, así como la iluminancia al cual está sometido el sensor de brillo, expresada en lux (1 lx = 1 lumen/m^2).

Nota: La versión gratuita de esta aplicación viene con una barra de publicidad en la parte inferior de la pantalla. En el menú de configuración, se encuentra una opción para proporcionarle al programa la clave para eliminar dichos anuncios, una vez efectuado el pago para obtener la versión sin anuncios, tal como se ilustra en la captura de pantalla siguiente:

Pero sin embargo la función más útil de esta aplicación quizás sea la de compartir la ubicación adquirida por GPS, mediante las opciones estándar del sistema Android. Dicha ubicación puede compartirse mediante código QR, copiarse al portapapeles, o ser compartida a través de utilitarios como Facebook, Gmail, mensajería de texto SMS y Twitter, en mi caso particular, por hallarse instaladas tales aplicaciones. Para ello, pulsamos el botón de menú de Android, y seleccionamos “Compartir posición”, lo cual nos lleva a la pantalla siguiente:

Si se selecciona la primera opción, aparece la lista de las acciones posibles:

De tal forma, si por ejemplo, seleccionamos Gmail para compartir nuestras coordenadas con un destinatario de correo (en este caso, yo mismo), nos aparece la ventana de redacción de correo con las coordenadas GPS, así como un enlace de Google Maps con dichas coordenadas:

Nota: las coordenadas que aparecen en estas captura de pantalla no son reales; sin embargo tuve cuidado de que fueran las mismas en todas ellas.

Entre los menúes disponibles se encuentra el de “Tools” (herramientas), el cual propone las tres siguientes: calibración de brújula, calibración de ladeo e inclinación, y el manejo del estado A-GPS. No detallaré las dos primeras por ser bastante obvias; la tercera permite descargar de Internet datos de asistencia GPS que podrán acelerar el GPS durante unos días, y requiere una conexión a Internet activa:

Siempre es útil poder capturar la pantalla en nuestro teléfono (o tableta) Android preferido. La mayoría de las aplicaciones que hacen esto necesitan tener acceso de administrador; ¿qué hay si no nos hemos aventurado a hackear nuestro dispositivo aún? Existe una solución: el Dalvik Debug Monitor, herramienta de depuración de la VM Dalvik que viene con el SDK de Android.

Para obtenerlo, descargamos primero el SDK de la página oficial:

http://developer.android.com/sdk/index.html

En el caso que nos interesa, descargamos el archivo android-sdk_r10-linux_x86.tgz (última versión a la fecha). Nos aseguramos que en nuestro sistema esté instalado el Sun Java Environment (en Debian, aptitude install sun-java6-jre sería suficiente), y descomprimimos el archivo .tgz en un directorio perteneciente a nuestro usuario (tomemos la variable “DIR” para hacerle referencia).

cd $DIR

tar xvfz  android-sdk_r10-linux_x86.tgz

cd  android-sdk-linux_x86/tools

En este directorio se encuentran las herramientas que necesitamos. Primero, ejecutamos el emulador de Android:

../android

…e instalamos el SDK que convenga mejor a nuestro dispositivo, según la versión de Android que tengamos instalada, la cual seleccionamos de la lista de paquetes obtenida en el menú “Available packages”, en la sección izquierda de la ventana. El programa descargará el  o los paquetes seleccionados al pulsar el botón “Install Selected”. No olvidemos que si obtenemos un error de conexión de tipo “Network is unreachable”, aparte revisar nuestra conectividad con Internet, debemos colocar, como root, la siguiente línea en el archivo /etc/sysctl.conf:

net.ipv6.bindv6only = 0

y luego,

# sysctl -p

…para que el sistema tome en cuenta el cambio.

Una vez instalado el SDK de la misma versión que el sistema Android de nuestro dispositivo, salimos del emulador, y ejecutamos DDM:

usuario@maquina:~/$DIR/android-sdk-linux_x86/tools$ ./ddms

Si previamente hemos colocado nuestro Android en modo de depuración USB, encontraremos nuestro dispositivo listado a la izquierda de la pantalla de DDM. El el caso de mi Motorola Milestone, he tenido también que configurar la conexión USB en “Sincronización de Windows Media” para que apareciera en dicha lista. Al seleccionar el dispositivo, se activa la opción “Screen capture…” en el menú Device, también accesible con Ctrl-S:

 

Una ventana con la captura deseada aparecerá, con las opciones de refrescar, rotar, guardar y copiar la imagen. El formato que utiliza DDM para guardar la imagen es el PNG (compresión sin pérdida).

Un ejemplo de pantalla capturada de mi Motorola Milestone pueden verlo aquí:

 

Hoy, día 19 de marzo de 2011, además de ser día de fiestas patronales en las localidades de Maracay y  Cagua, en el Estado Aragua,  Elorza, Estado Apure, (Venezuela) y muy probablemente otras que se me escapan, tenemos el fenómeno del perigeo lunar: es cuando la Luna se encuentra en su punto más cercano a la Tierra, en su órbita elíptica alrededor de ésta. Así pues, nuestro único satélite natural estará hoy a unos  356.577 km de nosotros, la distancia más cercana en décadas pasadas y futuras, un poco menos de su distancia media a la Tierra, que es de unos 384.400 km. De esta forma, la luz solar que nos llega reflejada de la Luna tardará hoy aproximadamente 1,19 segundos en alcanzarnos, en lugar de los 1,28 segundos habituales en promedio (que generalmente redondeamos a 1,3 s). Debo aclarar que ocurre un perigeo y un apogeo (distancia máxima Tierra-Luna) cada vez que el satélite le da una “vuelta” a nuestro planeta, vuelta que no es circular sino elíptica, y de allí que haya una distancia máxima y otra mínima, por cada vuelta, pero esta distancia mínima en particular será de las más pequeñas en bastantes años, ya que la órbita lunar no describe exactamente la misma elipse todo el tiempo. También, por una coincidencia que sólo ocurre una vez cada 19 años aproximadamente, el perigeo precederá la fase de Luna llena en una hora solamente, por lo que para nuestros efectos ocurrirán casi al mismo tiempo. De tal manera, nuestra Luna se verá no solamente con un diámetro 14% más grande que lo habitual, sino 30% más brillante. Impresionante, si se mira cuando el astro está cerca del horizonte: por un efecto no muy entendido aún por los científicos, y que parece tratarse de una ilusión óptica, la Luna parece más grande allí que cuando está en el cenit, es decir, encima de nuestras cabezas.

Un video magníficamente compuesto por la NASA, y que explica gráficamente lo que aquí exponemos, puede ser visto acá, y aunque no entienda el inglés el lector, no dejo de recomendarlo:

He observado que organismos como NASA se esfuerzan en afirmar que el perigeo no ocasiona catástrofes naturales. Sin embargo, esta afirmación es un tanto relativa. Siendo la fuerza de atracción gravitacional entre dos cuerpos inversamente proporcional al cuadrado de la distancia, es harto conocido el efecto que tiene esto sobre la marea alta, llevándola a un nivel aún más alto, cuando ocurre el perigeo; no solamente la marea existe para el agua, sino también para la tierra, en particular la corteza terrestre. En menor grado, por supuesto, ya que al ser sólida, la corteza del planeta no se deforma tan fácilmente como el agua, pero se deforma un poco… Si por casualidad alguna zona de roce entre placas tectónicas se halla en estado de alta criticalidad, no es imposible que se desaten temblores, o incluso algún terremoto. Ya conocen aquello del efecto mariposa, que en Física llamamos sensibilidad a las condiciones iniciales, y que es válido para los sistemas dinámicos que se encuentren en régimen crítico. Es más que probable que la corteza terrestre se halle en muchas de sus zonas de tensión entre placas en un estado crítico, dada la distribución de potencias verificada en la ley de Gutenberg-Richter (¿les suena este último?), y que describe la distribución estadística de los tamaños de los terremotos. Por lo cual, una configuración Tierra-Luna que aumente la marea terrestre podría ser un factor de activación de movimientos bruscos de terreno. Un factor entre muchos otros, y desgraciadamente, esto no hace los terremotos más predecibles, sino únicamente por vía estadística, lo cual no ayuda mucho a la hora de preguntarse si va a temblar.

Esta noche trataremos, en fin, de fotografiar la Luna, si las nubes nos dejan, con la ayuda de un telescopio y de una cámara digital convencional usando el método afocal (que consiste en colocar el objetivo de la cámara en el ocular acoplado al telescopio), y si tenemos suerte, con una cámara CCD especializada, en foco primario (directamente en el portaocular). Así, que, quizás, este artículo no esté del todo terminado

No dejen de fotografiar la Luna estos días.

–

Luego de fotografiar la Luna con una cámara Canon SX10IS usando el método afocal con un ocular de 20 mm en un telescopio de 650 mm de distancia focal, notamos que el diámetro aparente del satélite es un 7% más importante que el de  seis días antes. Una imagen ilustrativa puede ser vista aquí:

La imagen más clara, de la Luna llena, representa el satélite en su perigeo del 19 de marzo de 2011, mientras que la fase creciente, más oscura en la composición, es de seis días antes, el 13 de marzo. Para más detalles, o ver la foto de otros tamaños, dar click en la imagen.

Alguna vez nos habremos preguntado cómo hace, en Linux, nuestro manejador de archivos preferido para darse cuenta de los cambios que sufre un archivo en atributos como el tamaño o el nombre, o incluso si aparece o desaparece un archivo en un directorio, reflejando tales cambios casi instantáneamente. En épocas pasadas, de haber investigado sobre esto, nos habríamos topado con mecanismos como dnotify o FAM  (File Alteration Monitor), los cuales llevaban a cabo la tarea de notificar  de los cambios en los archivos que se quería monitorizar a la aplicación que los invocaba. Sin embargo, debido a razones de rendimiento, un mecanismo similar fue integrado directamente en el núcleo Linux a partir de la versión 2.6.13, llamado inotify y utilizado actualmente por los manejadores de ventanas más populares (al menos Gnome y KDE).

Según el manual de inotify, este subsistema del kernel Linux provee un mecanismo para monitorizar eventos en un sistema de archivos, en particular en archivos o directorios. Existe una API de inotify, disponible para ciertos lenguajes de programación, tales como C, C++, Perl, Python, Ruby, Haskell, OCaml, etc. De tal manera, podemos escribir un programa o script que haga un llamado a dicha API, y mantenerlo corriendo permanentemente como demonio (en el sentido Unix) para que reaccione ante un cambio en el sistema de archivos y ejecute una acción en consecuencia.

Sin embargo, ya existe una herramienta de muy sencillo uso, denominada incron, que aprovecha un conjunto de las funcionalidades de la API de inotify, integrándolas en un sistema de tipo cron, aunque dirigidas por eventos del sistema de archivos en lugar de intervalos de tiempo. Este sistema contiene dos programas, un demonio llamado “incrond” y un manipulador de tablas, incrontab, análogos ambos a crond y a crontab, respectivamente. Según se puede leer en la FAQ del proyecto incron, el demonio incrond lee reglas de las tablas de usuario y del sistema, crea “watches” apropiados en archivos y se coloca a la espera eventos.  En el momento de la ocurrencia de uno de éstos, el demonio ejecuta el comando especificado en la tabla que lo invoca; cualquier cambio en las tablas es tomado en cuenta inmediatamente. Las tablas se guardan en el directorio /var/spool/incron, pero no se supone que sean modificadas directamente, sino por medio del comando incrontab.

Ilustraremos el uso de incron mediante un ejemplo práctico.

Instalemos incron. En Debian:

# aptitude install incron

…y editemos la tabla de incron para nuestro usuario:

$ incrontab -e

Si, por ejemplo, quisiéramos que en un directorio determinado, al copiar o mover allí un archivo de imagen la resolución de éste sea limitada a un máximo predeterminado, añadimos la línea siguiente en el editor que aparece invocando el comando anterior:

/home/<usuario>/Desktop/Images IN_CREATE,IN_MOVED_TO /usr/local/bin/reduce.sh $@/$#

Luego de grabar el archivo, podemos verificar que en la bitácora del sistema (/var/log/syslog) aparece la línea siguiente:

<fecha> <hora> <nombre de máquina> incrond[<pid>]: table for user <usuario> changed, reloading

La línea que escribimos en la tabla contiene tres partes, separadas por espacios. La primera es el camino absoluto hacia el archivo o directorio que será vigilado. El segundo es una máscara de eventos que contiene todos los eventos que serán considerados, separados por comas; el tercero es el comando a ser ejecutado una vez que alguno de los eventos especificados se active. En el caso que nos interesa:

• /home/<usuario>/Desktop/Images: En este directorio, contenido en el escritorio, quisiéramos agregar, por ejemplo, archivos .JPG obtenidos de una cámara digital con mucha resolución, y que sean automáticamente llevados a una resolución menor a la original, además de ser cambiado su nombre a minúsculas.
• IN_CREATE,IN_MOVED_TO: Éstos son los dos eventos que deseamos sean considerados, a saber, si se crea un archivo (producto, por ejemplo, de una acción de copiar/pegar) en el directorio mencionado, o si se mueve un archivo de otro directorio hacia éste.
• /usr/local/bin/reduce.sh $@/$#: Aquí colocamos el camino absoluto hacia un script, seguido de un argumento. El símbolo $@ significa “el directorio que está siendo vigilado”; análogamente, el símbolo $# se refiere al archivo asociado al o a los eventos especificados en el segundo punto; en nuestro caso, el archivo que fue creado o movido al directorio  mencionado en el primer punto. El conjunto $@/$# es pasado como parámetro al script reduce.sh, que será el que al final ejecute la acción deseada.

Otros símbolos de eventos son los siguientes (tomado de “man 5 incrontab”):

• IN_ACCESS: Se activa si el archivo tuvo un acceso de lectura.
• IN_ATTRIB: Cambio en los metadatos (permisos, marcas de tiempo, atributos extendidos,…)
• IN_CLOSE_WRITE: El archivo abierto para escritura fue cerrado.
• IN_CLOSE_NOWRITE: El archivo no abierto para escritura fue cerrado.
• IN_CREATE: Un archivo o directorio fue creado en el directorio vigilado.
• IN_DELETE: Fue borrado un archivo o directorio en el directorio vigilado.
• IN_DELETE_SELF: Fue borrado el archivo o directorio que está siendo vigilado.
• IN_MODIFY: El archivo fue modificado.
• IN_MOVE_SELF: El archivo o directorio siendo vigilado fue movido.
• IN_MOVED_FROM: Archivo movido fuera del directorio que está siendo vigilado.
• IN_MOVED_TO: Un archivo fue movido al directorio que está siendo vigilado.
• IN_OPEN: El archivo fue abierto.

Excepto en el caso de IN_MOVE_SELF, los eventos listados pueden ocurrirles a archivos ubicados en el directorio que está siendo vigilado, en cuyo caso el símbolo $# retorna el nombre del archivo (contenido dentro de tal directorio) al cual le ocurre el evento. Una lista exhaustiva de eventos y de símbolos puede encontrarse en la sección 5 de la página del manual de incrontab.

¿Qué hay del script reduce.sh mencionado anteriormente? Pues bien, ya que a alguien puede serle útil, lo transcribiré aquí. Tan sólo deben estar instalados los paquetes coreutils, imagemagick y bc (llamados así al menos en Debian), de tal manera que se puedan invocar los comandos basename, dirname, convert, mv, identify, cut, echo, bc y convert.

1 #!/bin/sh

2 FILE=`/usr/bin/basename $1`

3 DIR=`/usr/bin/dirname $1`

4 NAME=`/bin/echo $FILE | /usr/bin/tr 'A-Z' 'a-z'`

5 CONVERT=/usr/bin/convert

6 MV=/bin/mv

7 IDENTIFY=/usr/bin/identify

8 CUT=/usr/bin/cut

9 ECHO=/bin/echo

10 BC=/usr/bin/bc

11 RES=`$IDENTIFY $1| $CUT -d ' ' -f 3`

12 RESX=`$ECHO $RES | $CUT -d 'x' -f 1`

13 RESY=`$ECHO $RES | $CUT -d 'x' -f 2`

14 RESMAX=800

15 $ECHO $RESX $RESY

16 if [ $RESX -ge $RESY ]

17 then

18   if [ $RESX -ge $RESMAX ]

19   then

20     VAR=`$ECHO "scale=10; $RESY/$RESX*$RESMAX" | $BC`

21     VAR=`$ECHO $VAR | $CUT -d '.' -f 1`

22     $CONVERT $1 -resize ${RESMAX}x${VAR} $1 &>/dev/null 23   fi

24 else

25     VAR=`$ECHO "scale=10; $RESX/$RESY*$RESMAX" | $BC`

26     VAR=`$ECHO $VAR | $CUT -d '.' -f 1`

27     $CONVERT $1 -resize ${VAR}x${RESMAX} $1 &>/dev/null

28 fi

29 $MV $1 $DIR/$NAME &>/dev/null

La magnitud más importante manejada en este script está contenida en la variable $RESMAX (a nuestros efectos, usada como constante), que es la resolución lateral máxima de la imagen pasada como parámetro, de tal forma que si la imagen es más ancha que alta, le coloque tal número de pixeles en resolución horizontal, y en el caso contrario, sea ésa la resolución vertical. En nuestro caso concreto, hemos optado por una resolución lateral máxima de 800 pixeles: para las imágenes con una razón de 1:1,33 (usada en la mayoría de las cámaras digitales para sus imágenes JPEG), el otro lado de la imagen mediría 600 pixeles.

El video siguiente ilustra gráficamente un uso práctico de lo anterior:

En este ejemplo se muestra el efecto de una tabla de incrontab en la que se invoca un script de reducción de resolución para imágenes; copiar una imagen de un tamaño inicial de 4,4 MiB al directorio que está siendo vigilado por incron (en este caso $HOME/Desktop/Images) resulta automáticamente en la reducción de la resolución de la imagen allí copiada, tomando un nuevo tamaño de sólo 223,1 KiB. El archivo también es renombrado para contener sólo minúsculas en un proceso prácticamente inmediato.

Quien posea una cuenta en Flickr y haya subido contenido en forma de imágenes o videos a este excelente sitio de fotos en línea, habrá usado casi con seguridad las interfaces que se ofrecen por defecto para este fin, a saber, el viejo Uploader básico, así como el flamante Uploader en Flash.

El primero nos permite subir hasta seis fotos a la vez, previamente seleccionadas, y es de uso apropiado para aquellos usuarios cuyos navegadores no tienen el plugin de Flash instalado.

El segundo uploader -que deberíamos denominar “cargador” por cuidado del lenguaje- permite una carga concurrente de un número mucho mayor de imágenes, las cuales pueden seleccionarse de manera múltiple dentro de un directorio común. Ambos métodos dependen del uso de un navegador Web, y hay que señalar que si la carga se ve interrumpida, no es posible continuarla, sino que la imagen deberá ser cargada desde el principio.

Pero, ¿qué sucede si nos encontramos con una conexión extremadamente lenta, poco fiable, intermitente, como la que puede ofrecernos la red 2G celular en alguna playa apartada? Al tiempo de intentar una y otra vez subir  la foto de la que estamos orgullosos, ya nos decimos que estaríamos contentos si esa sola foto subiera a nuestra cuenta Flickr, dejando las demás para otro día. Pero sucede que la conexión no nos ayuda, de la imagen sube un 25%, quizás hasta llegue al 80% en algún fallido intento, cuando vuelve a caerse la conexión y por enésima vez hay que comenzar desde el principio.

No deja uno de preguntarse: “¿Por qué Flickr no soporta el resume?” Es decir, la posibilidad de subir parte de un archivo, y continuar en otro momento favorable con la carga si ésta se interrumpe.

Por otro lado, y aunque en estos días ya es cada vez más difícil encontrarse con alguna máquina poco potente que no soporte un buen navegador Web, siempre cabe esta posibilidad, bien sea por falta de memoria suficiente o por poseer un procesador relativamente lento. Esta situación hace que sea deseable trabajar por medio de nuestra amiga la consola, que pocos recursos requiere para lograr nuestros cometidos, siempre y cuando sepamos usar las órdenes correctas.

En el mismo orden de ideas, al usar comandos, siempre será posible agrupar o ordenar dichas órdenes en algoritmos que nos ayuden a ejecutar tareas repetitivas. Nos viene inmediatamente a la mente el etiquetado de una imagen cada vez que se sube a Flickr: títulos, descripciones, tags… Aunque, ciertamente, los dos métodos de carga descritos anteriormente proveen un medio de aplicar etiquetas a un conjunto de imágenes cargadas en bloque, esto no significa que podamos ahorrarnos el trabajo si el conjunto de las descripciones, etiquetas y títulos de cada imagen se encuentran íntimamente asociadas con el tipo de ésta: si, por ejemplo, queremos asociar los nombres científicos, nombres vernaculares, lugares de avistamiento, y otras características, a cada una de las especies animales que hemos fotografiado durante el día, no podemos valernos de la herramienta de Flickr para ahorrarnos trabajo, sino que habríamos de introducir manualmente todos estos datos para cada una de las fotos. Entonces, ¿habrá algún método que permita usar la línea de comandos, o mejor aún, scripts preprogramados, para subir fotos a Flickr? Afortunadamente sí los hay.

La API de Flickr.

Según la ayuda de Flickr: ‘API es la sigla en inglés de “interfaz de programación de aplicaciones”, que permite a aplicaciones externas (“de terceros”) o sitios Web comunicarse con Flickr e intercambiar información. Este intercambio permite a los desarrolladores crear programas o servicios geniales que usan datos de Flickr’.

La utilización de esta API abre un mundo de posibilidades al programador, como también al usuario final, para “mejorar su experiencia”, de tal forma que pueda utilizar “herramientas o funciones que Flickr no ofrece directamente”. En el caso que nos interesa, la conjunción de un lenguaje de programación con dicha API perfectamente puede ayudarnos a resolver el problema planteado al principio, a saber, reemplazar los cargadores tradicionales por otro mucho menos ávido de recursos y que permita entre otras cosas, subir fotos a nuestra cuenta sin, incluso, estar los archivos de imágenes presentes en nuestro ordenador, sino ejecutar la carga desde un computador remoto.

Flickr::Upload

Como ya el título de este artículo lo anticipaba, nuestra atención se enfoca en el uso del módulo Flickr::Upload, presente en el repositorio de módulos del lenguaje de programación Perl, la navaja suiza de los lenguajes modernos, y herramienta indispensable para los administradores de sistemas Unix (y no Unix también). Siendo este módulo una subclase de la API de Flickr, representada en Perl por el módulo Flickr::API, contiene su función de carga de una imagen a una cuenta especificada como argumento; usaremos dicho módulo para fabricar una aplicación que cargue fotos a nuestra cuenta.

Para desarrollar una tal aplicación (“de terceros”) en Perl o en cualquier otro lenguaje, es necesario contar con tres datos esenciales aparte el nombre del usuario y su contraseña, a saber: una clave API para nuestra aplicación, el código secreto asociado, y el token obtenido a partir de los dos objetos anteriores. La obtención de la clave API está reseñada aquí; en cambio, para obtener el llamado token se debe recurrir a un fragmento de código, que obtendremos del excelente artículo de Teodor Zlatanov en la sección ”Listing 4. Authentication and authorization”, siguiendo las instrucciones que allí se encuentran. Tal como se señala, es un procedimiento que ha de seguirse una sola vez, y una vez obtenido el token, podrá ser usado por siempre en nuestro código.

upload.pl

--

#!/usr/bin/perl

use Flickr::Upload;

my $image = shift;

my $title = shift;

my $description = shift;

my $tags = shift;

my $ua = Flickr::Upload->new(

{

'key' => '<nuestra llave API>',

'secret' => '<secreto asociado>',

});

$auth_token = '<el token>';

$ua->upload(

'photo' => $image,

'title' => $title,

'description' => $description,

'auth_token' => $auth_token,

'tags' => $tags,

'is_public' => 1,

'is_friend' => 1,

'is_family' => 1

) or die "Failed to upload $image: $!";

Usando el código propuesto contenido en el archivo upload.pl, basta entonces con volverlo ejecutable:

$ chmod +x upload.pl

…y con invocarlo con los argumentos esperados, a saber, el nombre del archivo imagen, el título de la foto, su descripción y las etiquetas asociadas, el contenido de cada uno de dichos argumentos entre comillas simples; de esta forma permitimos escribir etiquetas individuales de varias palabras entre comillas dobles. Por ejemplo, para subir la foto “Alcaravan.jpg” de un alcaraván (V. chilensis), escribimos, en una sola línea, el comando siguiente:

$ ./upload.pl Alcaravan.jpg 'Alcaraván [Southern Lapwing] (Vanellus chilensis)'

'Lugar: Ocumare de la Costa, Estado Aragua, Venezuela.'  'Alcaraván

"Southern Lapwing" "Vanellus chilensis" "Ocumare de la Costa"

"Estado Aragua" Venezuela'

Si el comando anterior lo hemos ejecutado dentro de un screen en un servidor remoto, al cual hemos cargado previamente la imagen ‘Alcaravan.jpg’ por medio del comando rsync (que sí soporta cargas remotas con interrupciones sin tener que volver a subir el archivo desde el principio), entonces habremos sido capaces de subir nuestra foto sin usar ningún navegador, con un mínimo de ancho de banda, con una conexión que se cae a cada momento, y en un abrir y cerrar de ojos tener publicada nuestra foto: