Convertir GIF a BMP

Los dos formatos son casi coetáneos, de 1987 y 1990, y resuelven el mismo problema en direcciones opuestas. Un GIF guarda un índice sobre una paleta de 256 entradas como mucho, es decir un byte por píxel, y encima le pasa LZW por encima. El mapa de bits que se escribe aquí guarda un valor completo de azul, verde y rojo para cada píxel, sin comprimir nada.

Así que el crecimiento no es un factor sino dos multiplicados. Tres bytes donde el GIF usaba uno, y ninguno de los ahorros de LZW que hacían pequeño al GIF de entrada. Un GIF de 40 KB se convierte con normalidad en un mapa de bits diez veces mayor, y con dibujo plano —material que el GIF comprime especialmente bien— la proporción es todavía peor.

La aritmética es corta y no tiene ninguna estimación dentro. Multiplica el ancho por tres para saber los bytes de una fila, redondea hacia arriba al siguiente múltiplo de cuatro, multiplica por el alto y suma 54 bytes de cabecera. Un GIF de 480 por 270 da 1.440 bytes por fila, sin redondeo, 388.800 bytes de píxeles y 388.854 en total.

Nada de lo que haya en el origen cambia ese número. El mismo mapa de bits de 480 por 270 sale de una fotografía tramada y de un rectángulo rojo liso, porque el formato escribe cada píxel literalmente en los dos casos. Esa previsibilidad es precisamente por lo que el hardware pide mapas de bits: un firmware que lee uno puede reservar su memoria leyendo solo la cabecera.

Dos convenciones de este archivo parecen errores y no lo son. Las filas se guardan desde la parte inferior de la imagen hacia arriba, y dentro de cada píxel los canales van en orden azul, verde y rojo en lugar del habitual. Ambas cosas están en la especificación original y son lo que cualquier lector de BMP espera encontrarse.

La cabecera son 54 bytes en total: 14 del encabezado de archivo y 40 del BITMAPINFOHEADER, con el ancho, el alto, un plano, 24 bits por píxel y el tamaño de la imagen. También lleva escrita una resolución de 2.835 píxeles por metro, que son 72 puntos por pulgada. No la lee casi nadie, pero dejarla a cero hace que algunos visores antiguos rechacen el archivo, de modo que va puesta a propósito.

Cada fila se rellena hasta un múltiplo de cuatro bytes. Una imagen de 101 píxeles de ancho escribe 303 bytes de píxeles seguidos de un byte de nada, 304 bytes por fila, y ese byte suelto no representa ningún color.

Un programa que lea el mapa de bits suponiendo que cada fila mide el ancho por tres produce una imagen que se desplaza en diagonal, un píxel más en cada fila. Es el fallo más frecuente en un lector de BMP escrito a mano, y si el aparato al que estás alimentando enseña la imagen inclinada, el relleno es el primer sitio donde mirar: el archivo está bien y quien lo lee no cuenta las filas como debe.

Nadie elige BMP. Lo elige algo que está más arriba y que lleva funcionando desde antes: el firmware de un panel LED de un rótulo, una impresora de etiquetas de almacén, una báscula de tienda que imprime el logotipo en el tique, un terminal de punto de venta, un equipo de laboratorio, un control heredado de Visual Basic o de Delphi dentro de un programa de gestión que sigue abriéndose todas las mañanas en una gestoría.

Todo eso comparte una propiedad: no hay a quién pedirle un cambio de formato. El fabricante cerró, el desarrollador se jubiló o el contrato de mantenimiento cubre averías y no funcionalidades. La conversión no es una preferencia estética sino la vía más corta para que un archivo entre por una puerta que se especificó en 1998 y no se ha vuelto a tocar.

Un BMP contiene una imagen. No tiene noción de secuencia, de retardo ni de bucle, así que un GIF animado que llegue aquí se queda en el fotograma con el que abre y el resto se descarta al descodificar.

Para los destinos que piden mapas de bits eso rara vez es un problema, porque un aparato que quiere un BMP quiere una imagen fija por definición. Sí conviene comprobar que el primer fotograma es el que querías: muchos GIF empiezan con un cuadro en blanco o con un rótulo antes de que aparezca el contenido, y ese es el que se va a quedar impreso en la etiqueta.

Es razonable esperar que una imagen con 256 colores distintos produzca un archivo pequeño, y con un formato de paleta así sería. La especificación de BMP incluso lo permite: un mapa de bits de 8 bits con su tabla de color, que encajaría con un GIF casi punto por punto.

Este conversor no escribe ese. Todos los mapas de bits que produce son de 24 bits, de modo que un GIF de seis colores cuesta los mismos bytes que una fotografía de las mismas dimensiones. Si el aparato al que vas a alimentar exige específicamente un BMP de 8 bits con paleta, y no simplemente «un BMP», este archivo no le va a valer, y eso es mejor averiguarlo antes de la conversión que después del rechazo.

Un GIF puede declarar transparente una de las entradas de su paleta. El mapa de bits que se escribe aquí no tiene canal alfa —24 bits, tres canales, no sobra nada—, así que esos píxeles necesitan un valor antes de codificarse.

La opción de color de fondo decide cuál, y por defecto es el blanco; un valor mal escrito también acaba en blanco en lugar de fallar. Elegirlo a conciencia importa cuando hay hardware de por medio: un icono destinado a una pantalla de interfaz negra se debe aplanar sobre negro y no sobre blanco para invertirlo después. Si el sistema espera una clave de color concreta, ponla ahí en lugar de confiar en que un paso posterior la encuentre.

En esta conversión no hay control de calidad, y no podría haberlo: sin comprimir es sin comprimir, y no queda nada que intercambiar. BMP comparte esa condición con PNG, ICO, GIF y TIFF, que también ignoran el ajuste de calidad por completo.

La única palanca es el ancho máximo, que redimensiona la imagen antes de escribir los píxeles y por tanto cambia el tamaño del archivo de forma cuadrática: la mitad de ancho es la cuarta parte de bytes. Suele ser además la decisión correcta cuando el destino es una pantalla pequeña, porque un panel de 128 píxeles no gana nada con una fuente de 640 y así el aparato no tiene que sostener el búfer grande.

Ninguna conversión de imagen de este sitio traslada metadatos, y no porque se borren a propósito: se descodifica a píxeles y el codificador recibe únicamente los píxeles, así que no hay nada que los lleve al otro lado. En este par esa regla tiene poquísimo trabajo que hacer, porque un GIF no tiene bloque EXIF, ni modelo de cámara, ni coordenadas.

Lo más que suele llevar es una extensión de comentario y otra de aplicación que dejó el programa que lo escribió. El mapa de bits tampoco tendría dónde ponerlas: su cabecera describe dimensiones, profundidad de color y poco más. Lo que sale son píxeles y geometría, y el nombre del grabador de pantalla que estampó su marca en el comentario no viaja.

El GIF lo descodifica el propio navegador y la cabecera y las filas de píxeles se escriben en JavaScript en la misma pestaña. No hay servidor en el camino, ni subida, ni cuenta de usuario, y el tope es de 100 MB por archivo, con hasta cien archivos por tanda.

Para este par eso vale más de lo que parece, porque lo que la gente convierte a BMP suele ser interno: el gráfico de un cuadro de mando, la etiqueta de un producto, la pantalla de arranque de un instrumento, el logotipo que sale en el tique de una tienda. Nada de eso necesita pasar por la infraestructura de un tercero para convertirse en un mapa de bits.