A propósito de un mensaje antiguo y otras con similares características he recibido en más de una ocasión consultas para saber como lograr dichas fotos. La mayoría directamente a mi casilla electrónica y hace poco a través de un comentario respecto a un tema completamente distinto a la pregunta. Así es que he decidido publicar un mensaje general explicando como se logra.

Antes de partir, debo aclarar que sólo soy aficionado a la fotografía y lo que a continuación escribo para muchos amantes de la fotografía no será nada nuevo, para otros puede ser de utilidad.

Una de las fotografías en cuestión es:

Vista nocturna del obelisco, Buenos Aires.

Lo importante aquí es la velocidad de obturación. Ha de ser una velocidad lenta, lentísima. Se trata de una fotografía nocturna y lo que se pretende es mostrar los objetos inhertes (como los edificios y el obelisco) de forma nítida y a la vez mostrar vida (las luces de los vehículos formando esas siluetas).

Si la velocidad elegida no es suficientemente lenta dada las condiciones de luz, sólo se obtendrá un imagen congelada de un instante. Donde los autos se verán estáticos y bien definidos. Es lo más típico que pueda suceder. Es más, incluso podría ocurrir que la fotografía resulte demasiado oscura.

A saber, la velocidades en las cámaras son del tipo: 1/1000, 1/500, 1/250, 1/125, etc. que denota una fracción de segundo. Así, 1/1000 es el doble más rápido que 1/500. Hay que imaginarse, ¿qué cosas suceden en una milésima de segundo? Ciertamente, un vehículo no alcanza a desplazarse en esa cantidad de tiempo, por lo que en la fotografía aparecerá «congelado». Si no hay mucha luz (como sucede en la noche), no se alcanza a captar suficiente luz y la imagen aparecerá más oscura. A diferencia de lo que sucede en el día, en donde puede haber demasiada luz.

Las velocidades lentas comienzan en 1/15, 1/8, 1/4, 1/2; las cuales siguen siendo lentas para el propósito de la fotografía del Obelisco. En 1/2 segundo «no alcanza a pasar nada». Luego tenemos 1 seg, 2 segs, 4 segs, 8 segs, 30 segs y BULB. Dependiendo de la cámara se puede contar con esos tiempos. Con BULB, uno mantiene presionado el obturador por todo el tiempo que uno desee.

Cuando las velocidades son lentas, se corre el riesgo que se mueva la cámara; por lo que la fotografía aparecerá totalmente borrosa. Es necesario utilizar un trípode o una base estable donde apoyar la cámara.

La fotografía del Obeliso fue tomada con una exposición de 8 segundos. Para ello, esperé el instante en que cambiara el semáforo y los vehículos comenzaran a desplazarse. Con 8 segundos fue suficiente para lograr dicho efecto y es lo máximo que me permite mi cámara digital. No utilicé trípode, pero si apoyé la cámara en la ventana del cuarto del hotel.

Otros «efectos»

También es posible jugar con velocidades lentas de día. Por ejemplo, la siguiente fotografía:

Tren en movimiento, El Tigre.

Al verla se obtiene la impresión que el tren iba en movimiento. Sin embargo, el objetivo de la foto se muestra bien definido. Es decir, el motivo de la fotografía aparece definido, y el ambiente proporciona más información del momento. Esta fotografía la tomé con un exposición de 1/15 seg. De haber tomado la fotografía con una menor exposición (velocidad más rápida), se podría ver con mayor detalle el fondo (los árboles, quizás alguna casa, etc.).

Una fotografía de similares características, pero viendo al «tren» desde la estación. Ahora es el tren el que se ve en movimiento manteniendo el resto de cuadro más definido. Esta fotografía tuvo una exposición de 1/3 seg.

Tren en movimiento, Estación de metro, Montrèal.

También hay situaciones en donde puede resultar necesario utilizar una exposición lenta para poder captar la escencia de la imagen. Así por ejemplo, y si nos olvidamos que el encuadre es malo, ¿de qué otra forma se podría mostrar que la esfera está girando? Con una velocidad normal (1/250 ó 1/500) la esfera aparecería inherte y habría que explicar la fotografía. Con una velocidad de 1/8 seg se alcanza a apreciar el movimiento.

Esfera en movimiento, Stuttgart.

Así como estos ejemplos hay otros. Son típicas las fotografías de afluentes de agua o pequeñas cascadas. También es el caso de fotografía de deportes, en donde se elige una velocidad lenta y luego se mueve la cámara junto al motivo (el deportista); de esta forma se puede lograr capturar al deportista en movimiento (centro definido, bordes difusos y fondo borroso).

Todo es cuestión de experimentar y aplicar los conceptos teóricos en los que se fundamente la fotografía. Las cámaras digitales contribuyen a esta tarea, porque no hay costo de revelado. Sin embargo, es necesario que la cámara permita controlar la abertura del lente y la velocidad del obturador en forma manual (aparece como M en el modo de selección). Si la cámara es completamente automática, no es mucho lo que se puede hacer para lograr estos «efectos».

En ocasiones uno no se encuentra con grandes ventanas de tiempo para dedicarse a algunas tareas que resultan atractivas; en mi caso: programar (entre otras cosas). Y cuando hay esas ventanas de tiempo, uno puede preferir dedicarlas a la distracción u otras actividades. Cuando se está atiborrado de actividades, ¿cuántas veces uno se dice «cuando tenga tiempo haré tal o cual cosa»?. Pero cuando llega el tiempo, ya no se tiene la misma motivación, o lo único que uno quiere, es cambiar de sintonía y dedicar ese tiempo a otros asuntos.

No obstante, siempre es posible encontrar pequeños espacios de tiempo. O cuando uno requiere cambiar de actividad para despejar la mente o bajo cualquier otra circunstancia.

Es así, como a falta de un espacio de tiempo para dedicarse a programar aunque sea algo sencillo, uno estima que no alcanzará a terminar y finalmente uno se dedica a otras cosas. Para evitar caer en ese círculo, es que comencé a revisar los fallos reportados en Bugzilla de GNOME. Ciertamente, antes lo había utilizado; reportando fallos principalmente. Y ha sido entretenido.

Lo primero fue comenzar a clasificar fallos («triaging»), así como revisar aquellos que tenía pendientes en el buzón de correo. Lo mejor de todo vino cuando comencé a etiquetar algunos fallos con «gnome-love», que es la etiqueta que permite identificar aquellos fallos que pueden ser resueltos sin tener un conocimiento profundo en la aplicación o en programación en GNOME. Es decir, orientado a permitir que se acerquen nuevos contribuyentes al proyecto. Incluso para aquellos que no disponen de mucho tiempo y desean continuar contribuyendo.

Al día siguiente de marcar un par de fallos, apareció un nuevo contribuyente enviando un parche. Para ser más precisos, 17 horas después que yo marqué un fallo como de una tarea para un nuevo desarrollador, ya tenía una parche disponible. Sirvió para corregir el fallo, como también para ayudar a un nuevo desarrollador a integrarse e interiorizarse en pequeños detalles que marcan la diferencia.

He recibido más parches desde entonces, desde Alejandro Andrés y ahora sólo quedan 6 fallos por resolver. Y aunque gnome-nettool es una herramienta pequeña, al menos ha servido como introducción a nuevos desarrolladores.

También comencé a revisar fallos en algunos programas que estaba usando (Banshee y Sound Juicer), y a reportar errores. Luego de llegar los parches, probarlos y enviar comentarios. Algunos de ellos, aunque aún no han sido aplicados en alguna versión oficial, resuelven un problema... (me resuelven un problema :-) Algunos fallos me han derivado a seguir fallos en otros programas y hasta darme un poco de tiempo para enviar parches.

¿Qué hacer cuando no me parece nada interesante a revisar? Sucede que uno puede intentar utilizar Bugzilla pero no sabe que hacer. Para evitar esos casos, utilizo una de las bondades de este programa, y que es me envíe una copia de cada reporte o comentario que realice algún desarrollador. Seguirle la pista. Por el momento, sólo con desarrolladores que si bien son activos, no lo son tanto de forma de poder manejar cada día un conjunto acotado de fallos.

Así es que prefiero leer algunos fallos en Bugzilla y quitarle tiempo a seguir algunas listas de correo.

La moraleja es que se puede contribuir a un proyecto como GNOME sin contar con tanto tiempo.