Convertir TIFF a BMP

No hay ningún argumento de calidad de imagen a favor de esta conversión. El TIFF es el formato más capaz en todos los aspectos —más modelos de color, más profundidades de bit, más páginas, opciones reales de compresión— y el BMP es un formato de Microsoft de 1987 que guarda un rectángulo de píxeles y poco más. Si estás aquí, algún equipo o programa te ha dicho qué acepta, y no lo has elegido tú.

Es una situación legítima y frecuente. Aplicaciones de laboratorio e inspección, herramientas de visión artificial, pantallas empotradas, controladores de punto de venta o de proceso industrial, y una larga lista de programas de Windows de los años noventa leen BMP y solo BMP, precisamente porque es trivial de interpretar: una cabecera, luego los píxeles, sin códec que licenciar ni biblioteca que enlazar. Esta conversión existe para cumplir ese requisito sin estropear la imagen por el camino.

Un BMP de 24 bits sin comprimir, con una BITMAPINFOHEADER: la variante básica que entiende cualquier lector jamás escrito. Tres detalles del formato merecen conocerse si vas a escribir el código que lo consume: las filas se guardan de abajo hacia arriba, los canales se ordenan azul, verde, rojo en vez de rojo, verde, azul, y cada fila se rellena hasta un múltiplo de cuatro bytes.

Los tres están en la especificación y no son decisiones tomadas aquí, y los tres son la causa habitual de que una imagen llegue del revés, con el azul donde debería ir el rojo, o desalineada en diagonal. El campo de resolución se escribe como 2.835 píxeles por metro, es decir 72 ppp, y no se toma del TIFF de origen. Casi nada lee ese campo, pero dejarlo en cero hace que algunos visores antiguos rechacen el archivo, así que se escribe un valor real.

Ambos formatos van sin comprimir tal como se escriben aquí, así que el peso del archivo es aritmética y no una apreciación. Las muestras propias de este sitio a 480 por 320 dan 615.400 bytes como TIFF y 460.854 como BMP, siempre, sea cual sea la imagen.

La diferencia es el canal alfa: el TIFF que se escribe aquí guarda cuatro canales de 8 bits cada uno y el BMP guarda tres, así que una cuarta parte de los bytes desaparece junto con la transparencia. Frente a un TIFF que venía comprimido con LZW o Deflate —que es la mayoría de los que salen de un escáner real— la relación se invierte con fuerza y el BMP puede ser varias veces más grande. No es un problema que resolver: es el formato haciendo lo suyo, que es leerse sin ningún trabajo de descodificación.

El BMP producido aquí no lleva alfa, así que cualquier transparencia tiene que convertirse en algo. La imagen se compone sobre un color de fondo sólido primero, en la misma pasada que cualquier reescalado, lo que evita el borde de píxeles semitransparentes que dejaría aplanar después de escalar.

El color es blanco por defecto y hay un control para cambiarlo. Elígelo con intención cuando el destino sea una máquina: una rutina de inspección que umbraliza la imagen, o un controlador de pantalla que trata un color como clave, se comportarán de forma completamente distinta frente a blanco que frente a negro o magenta. Si la transparencia era en sí misma la información —una máscara, una segmentación, un recorte— el BMP no puede llevarla en absoluto, y TIFF a PNG sí puede.

Buena parte del material de instrumentos se captura a 16 bits por canal, y ahí suele vivir la medición más que la imagen. Este proceso descodifica a 8 bits conservando el byte alto de cada muestra: medido sobre un TIFF en escala de grises de 16 bits, un valor almacenado de 30.000 vuelve como 117.

Para cualquier cosa que vaya a mirar una persona, eso es invisible; una pantalla muestra ocho bits. Para cualquier cosa que vaya a medir un software —densitometría, intensidad de fluorescencia, un mapa de profundidad, un ráster de elevación guardado como TIFF— es una pérdida silenciosa y catastrófica, y el BMP no podría haber llevado esos bits de más de todas formas. Si el software de destino necesita de verdad 16 bits y de verdad solo lee BMP, esos dos requisitos entran en conflicto y merece la pena releer bien la documentación de ese software.

El TIFF es un contenedor y admite varias imágenes por archivo; el BMP admite una. El lector de aquí toma la primera página y se detiene, sin ningún error y sin nada en la interfaz que avise de que había más. Los escáneres, las pasarelas de fax y los sistemas de expedientes producen TIFF multipágina como cosa normal, así que conviene comprobarlo antes de un lote y no después.

Dividir primero es la solución —ImageMagick, IrfanView o el propio software del escáner lo hacen— y luego cada página se convierte a su propio BMP. Las capas van por el mismo camino y se aplanan en la composición, que suele ser lo que se buscaba. TIFF a PDF no resuelve esto: convierte igualmente solo la primera página, así que un TIFF con varias páginas hay que dividirlo antes sea cual sea el destino elegido.

Un TIFF en escala de grises se convierte limpio: el valor de gris se escribe en los tres canales, así que el BMP sale en gris y pesa tres veces más de lo necesario. Un escaneo en blanco y negro de un solo bit hace lo mismo y es el peor caso en tamaño, porque una página de fax que ocupaba 40 KB como Group 4 se convierte en varios megabytes de píxeles de 24 bits.

Un TIFF en CMYK —del tipo que produce un flujo de imprenta— se convierte a RGB con una fórmula fija en vez de a través del perfil ICC incrustado en el archivo. La imagen se reconoce y los colores no son exactos, típicamente planos en las sombras profundas. Como el BMP tampoco tiene concepto de perfil de color, no hay dónde guardar la respuesta correcta aunque se calculara. Para cualquier cosa donde el color importe, haz esa conversión en software que respete el perfil y trae aquí el resultado como un TIFF en RGB.

Los lectores de TIFF discrepan entre sí más que los de cualquier otro formato, así que la cobertura de aquí se comprobó contra archivos reales y no contra la especificación. Se descodifican sin comprimir, LZW, Deflate, PackBits, JPEG dentro de TIFF y fax Group 3 y Group 4, en color, en gris y en blanco y negro de un bit, en mosaico o por tiras.

Eso cubre prácticamente todo lo que produce un escáner de documentos, una cámara conectada por cable o un archivo. Lo que no cubre es un TIFF que en realidad es otra cosa disfrazada con esa extensión —un archivo raw de cámara, que estructuralmente es un TIFF y necesita demosaico en vez de simple descodificación. Esos tienen sus propias páginas bajo su propia extensión. Si un archivo se rechaza aquí, suele ser por eso.

Porque un BMP se lee sin necesitar ninguna biblioteca de imagen. Un microcontrolador que gobierna una pantalla pequeña puede saltarse la cabecera y copiar bytes directamente al búfer con un bucle sencillo; admitir TIFF en el mismo dispositivo implicaría enlazar un analizador de etiquetas y varios códecs de compresión distintos a algo que puede tener muy poca memoria disponible.

La misma lógica cubre a controladores industriales antiguos, aplicaciones de laboratorio escritas hace veinte años y bancos de pruebas que comparan imágenes byte a byte sin ningún códec de por medio. En cada caso el formato se eligió por previsibilidad, y el peso del archivo es el precio que se paga por ella.

Las dos mitades se ejecutan en la pestaña: utif2 lee el TIFF, y el BMP se escribe a mano en pocas líneas porque el formato es una cabecera y un bloque de píxeles y no justifica cargar una biblioteca de imagen entera. Nada se sube, lo cual importa cuando las imágenes son historiales clínicos, resultados de inspección o cualquier cosa bajo un acuerdo de confidencialidad.

El límite gratuito es 100 MB por archivo, y la salida en BMP no tiene un techo propio de tamaño —a diferencia del WebP, que se detiene en 16.383 píxeles por lado. Los lotes funcionan: suelta una carpeta, cada archivo se convierte con su propia fila de progreso, y el resultado vuelve como un ZIP. Como la salida en BMP son exactamente tres bytes por píxel, un lote de escaneos grandes produce un ZIP muy pesado, algo que conviene saber antes de empezar.