El cómputo moderno tiene muchos pros pero uno que otro contra y es que en muchos casos nos han convertido en usuarios que utilizamos programas pero que no podemos salirnos de ellos para hacer algunas cosas extras. Esto mismo se ve en quienes conducen un automóvil. Por ejemplo, ¿Quién sabe cómo funciona un motor de combustión interna? ¿Cuántos de nosotros podríamos arreglar nuestro coche si se descompone a la mitad de la calle? Y este quizás es el punto. Nos estamos convirtiendo en una especie de “analfabetas funcionales” y sin verlo como insulto, es algo común hoy en nuestros días.
En el cómputo, sin embargo, bien podríamos resolver algunas cuestiones de automatización de manera quizás sencillas si supiésemos programar. El caso del que hablo me ocurrió hace un tiempo. Quería convertir unas 60 mil imágenes de alta resolución en color a su equivalente a tonos de gris. Cabe señalar que el proceso para hacer esto es relativamente sencillo. Se trata de leer pixel por pixel de la imagen original, la cual está formada por tripletas de números que van de 0 a 255. Esto forma un pixel de 24 bits (y 32 bits si consideramos el canal de transparencia, que es de 8 bits, pero que podemos omitir en este momento). El pixel en gris equivalente se forma básicamente de la siguiente fórmula:
Gris = (R + G + B) / 3
Donde R, G y B son los tres valores enteros del Rojo, Verde y Azul. La división es entera (sin fracciones pues) y entonces se escribe el pixel en cada componente como (Gris, Gris, Gris). Existen pues 256 tonos de gris en donde cada tono se forma por los componentes R, G y B y que deben ser iguales, es decir R = G = B. Así entonces, si recorremos la imagen original en color y leemos cada punto de la misma, podemos sacar sus componentes R, G y B y pasar cada uno a un tono de gris. Pero este proceso puede ser lento pues cada imagen a procesar tiene alrededor de 800 x 600 puntos. Piénsese por ejemplo que si me tardo 1 segundo en leer, procesar y guardar la imagen procesada, estamos hablando de alrededor de 60 mil segundos, equivalente a unas 16 horas.
También se pueden poner valores específicos a las componentes de color de acuerdo a como el ojo puede ver y distinguir colores. Por ejemplo, la siguiente fórmula es más precisa que el usar el promedio:
Gris = 0.299 * R + 0.587 * G + 0.114 * B
Es curioso que el ojo ve casi por el doble mejor el verde que el rojo. Evolutivamente uno podría pensar que el rojo es el color que más vemos pues la sangre, por ejemplo, es roja y el sangrar nos pone en alerta de inmediato porque eso en general no es normal. De todas maneras el color que menos vemos es el azul y eso podría explicar la razón por la cual hay pocas bebidas con es color.
Escribir un programa que haga esto para todas las imágenes en color dentro de una carpeta no es una tarea particularmente complicada y me llevó una media hora en Delphi. Usé un par de trucos para procesar más rápidamente los pixeles y puse el programa a prueba. Tengo hoy día una máquina AMD de 8 núcleos que es muy rápida y esto ayudó en el asunto a resolver. De hecho, en pruebas hechas a “ojímetro”, encontré que el software pasa de color a tonos de gris a razón de 5 a 6 imágenes por segundo. El software hace la tarea con relativa eficiencia y quizás debería buscar la manera de hacerlo aún más rápido, por ejemplo, leyendo la imagen a procesar sin necesidad de mostrarla en pantalla, porque eso obliga al sistema a usar las rutinas de Windows para desplegar la información y eso va en demérito de la velocidad en la ejecución del software.
A quien le interese este software, puede pedírmelo a [email protected] y a vuelta de correo lo tendrá listo para instalarlo y usarlo.