Convertir HEIF a BMP

Esta página no va a fingir que BMP es una buena idea. No tiene compresión digna de ese nombre, no tiene metadatos y no aventaja al PNG en ningún eje que le importe a una persona. Microsoft lo publicó en 1987, la cabecera de cuarenta bytes que se escribe aquí llegó con Windows 3.0 y el mundo siguió adelante.

Lo que lo mantiene vivo es el software que no siguió. Paneles de control de instrumentación, pantallas de tótems y kioscos, pantallas de arranque de un equipo empotrado, cargadores de imágenes de firmware, herramientas internas compiladas una vez hace veinte años. Todos leen un mapa de bits porque un mapa de bits se interpreta sin ninguna librería. Si esa es tu situación, BMP no es una mala elección: es la única.

Una cabecera de archivo de catorce bytes que empieza con las letras BM, después una BITMAPINFOHEADER de cuarenta bytes que declara un plano de color y veinticuatro bits por píxel, y a continuación los datos. Tres bytes por píxel en orden azul, verde, rojo, que es el que pide la especificación y no un descuido. Las filas se guardan de abajo arriba, que también es la especificación.

Cada fila se rellena hasta un múltiplo de cuatro bytes. Para un ancho de 4.032 píxeles son 12.096 bytes y no hace falta relleno; para un ancho de 4.031 son 12.093 bytes más tres de relleno. Un analizador que dé por hecho que las filas son contiguas leerá torcida cada fila después de la primera, y ése es el fallo clásico de quien escribe su propio lector.

Como no se comprime nada, el resultado se puede saber antes de convertir: la longitud de fila ya rellenada, multiplicada por el alto, más cincuenta y cuatro bytes de cabecera. Una foto de doce megapíxeles a 4.032 por 3.024 da 36.578.304 bytes de datos, unos 36,6 MB, partiendo de un HEIF que probablemente pesaba dos o tres.

Un factor de quince es el resultado normal, y es la razón por la que el campo de anchura máxima importa aquí más que en casi cualquier otro par de este sitio. Si el programa al que alimentas muestra la imagen a 1.024 píxeles de ancho, convertir directamente a 1.024 le da lo que necesita en alrededor de 3 MB en lugar de 36.

El escritor produce píxeles de veinticuatro bits y ahí no cabe la transparencia. Lo transparente del origen se aplana antes de codificar, y sobre lo que se aplana es el color de fondo que hay encima de la zona de arrastre. Arranca en blanco, y si escribes un valor que no es un color válido, vuelve a blanco en lugar de fallar.

Ese aplanado ocurre antes del cambio de tamaño y no después, y el orden importa: rellenar y luego escalar mezcla el relleno en los bordes, y escalar y luego aplanar deja una orla oscura alrededor del contorno. Para una fotografía, que es lo que lleva casi cualquier .heif, no hay nada que aplanar y la cuestión es teórica. Importa si el origen es un gráfico exportado con un recorte.

Cada píxel que produjo el descodificador de HEIF se escribe literalmente en el BMP, así que esta dirección no añade ni un artefacto de compresión propio. Los valores de rojo, verde y azul son exactamente los que salieron del descodificador.

Y aun así este par no está etiquetado como sin pérdida, a propósito. Un canal que el origen podía llevar —el alfa— no está en la salida, y llamar «sin pérdida» a una conversión que descarta un canal entero es el mismo error que este sitio ya ha tenido que corregir una vez. Los colores sobreviven; la transparencia no. Las dos frases son verdad y la segunda es la que se olvida.

El BMP es enorme y esa es toda su relación con la calidad. La cámara comprimió la fotografía cuando escribió el HEIF, y aquellas decisiones están cocidas en los píxeles que entrega el descodificador. Un mapa de bits de 36 MB hecho a partir de una foto de 2 MB contiene exactamente la misma imagen, guardada de una forma mucho menos ingeniosa.

Es la confusión más frecuente en este par y merece decirse sin rodeos: no hay ningún control de calidad en esta página porque no hay nada que regular. Un formato sin compresión no tiene ajuste que ofrecer, y ninguna cifra habría mejorado lo que ya venía decidido desde el teléfono.

HEIF está especificado hasta diez bits por canal y puede llevar color amplio. Un BMP de veinticuatro bits guarda ocho bits por canal y no tiene ningún concepto de espacio de color: no hay en la cabecera ningún sitio donde decir qué significan esos números.

La imagen descodificada llega en un búfer de ocho bits por canal, y ocho bits por canal es lo que se escribe. El programa que lo reciba interpretará los valores como sRGB corriente porque es el único supuesto razonable. Para el tipo de programa que exige un BMP eso está bien invariablemente; solo importa si la imagen es una medición calibrada y no una fotografía.

El BMP no lleva EXIF, ni fecha, ni modelo de cámara, ni coordenadas. Convergen dos motivos distintos: la conversión descodifica hasta píxeles y vuelve a codificar, paso que ningún bloque de metadatos sobrevive, y además el formato prácticamente no tiene dónde guardar ninguno aunque lo hubiera.

A veces eso es justo la gracia. Para entregar una imagen a un sistema que la va a almacenar, indexar o mostrar en público, un mapa de bits es de los contenedores más inertes que existen: píxeles, dimensiones y nada que identifique a quien hizo la foto ni el sitio donde se hizo.

Un contenedor HEIF puede llevar varias imágenes dentro: una ráfaga, o los fotogramas que un teléfono guarda detrás de una foto con movimiento. De ahí se toma la primera, que es la que el móvil muestra y la que quien convierte quiere decir.

Convertirlas todas transformaría un archivo soltado en una tanda sorpresa, así que no se hace. Conviene saberlo antes de apuntar el conversor a una ráfaga y recibir una sola imagen, porque nada en el BMP resultante indica que hubiera más.

En los dos campos de resolución de la cabecera se escriben 2.835 píxeles por metro, que son 72 puntos por pulgada. Casi nada lee ese campo, y dejarlo a cero hace que algunos visores antiguos rechacen el archivo directamente, así que va un valor sensato en lugar de un hueco.

No lo interpretes como una decisión sobre el tamaño de impresión. Un BMP no lleva ninguna información de escala útil, y si el programa receptor imprime, el tamaño lo decide él a partir del número de píxeles. La anchura máxima es el único control de esta página que cambia de verdad las dimensiones.

Bastante gente que convierte a BMP está alimentando un analizador propio, porque un mapa de bits es el único formato de imagen que se lee en treinta líneas sin ninguna librería. Tres detalles explican casi todos los errores de esas treinta líneas, y los tres están en el archivo que produce esta página.

El salto entre filas es la longitud ya rellenada, no el ancho por tres: calcúlalo como el ancho por tres redondeado hacia arriba a un múltiplo de cuatro y avanza esa cantidad. Las filas van de abajo arriba, así que la primera del archivo es la última de la imagen. Y los canales están en orden azul, verde, rojo. Falla uno de los tres y la imagen sale torcida, del revés o teñida de azul, y parecerá un archivo corrupto en lugar de una suposición equivocada.

No hay camino de vuelta. Este sitio lee HEIF con libheif, publicada bajo LGPL-3.0, y no puede escribir el formato, porque eso exigiría un codificador de HEVC bajo una licencia que un sitio estático no puede cumplir. Es una decisión de licencia y no una función pendiente.

Como el mapa de bits pesa quince veces más y contiene estrictamente menos información, lo sensato es tratarlo como salida y no como copia: genéralo para la máquina que lo pide, úsalo, bórralo y conserva el HEIF, que puede producir otro cuando el programa antiguo lo vuelva a pedir. Todo ocurre además dentro de la pestaña, sin subir nada, con hasta cien archivos por tanda y 100 MB por archivo, lo que ningún HEIF va a rozar. Y merece la pena bajarse la tanda como ZIP: un mapa de bits sin comprimir se comprime muy bien dentro de uno.