Convertir HEIC a BMP

Las búsquedas que llegan a esta página salen todas de la misma escena: una ventana de «Abrir archivo» que ofrece BMP, JPG y TIF y nada más. Suele ser el programa de una gestoría, el software de una óptica o de una ortopedia, la aplicación de una máquina de etiquetas o de tarjetas identificativas, un sistema de almacén, o algo que un informático externo escribió en Visual Basic hace veinte años y que sigue funcionando porque nadie se atreve a tocarlo.

Ése es todo el motivo de esta página. Si la lista incluye PNG, usa PNG y deja de leer: son los mismos píxeles en un tercio del espacio. Si la lista de verdad se acaba en BMP, JPG y TIF, entonces BMP es la opción que no vuelve a comprimir tu fotografía, y el resto de esta página va sobre lo que eso cuesta.

Un BMP es una cabecera seguida de píxeles. Cincuenta y cuatro bytes describen el ancho, el alto y la profundidad de color, y todo lo que viene detrás es la imagen, en orden. Un programa puede leerlo sin ninguna biblioteca, y por eso el formato ha sobrevivido a cuatro décadas de Windows.

Un HEIC es otra clase de cosa por completo. Es un contenedor ISO —la misma estructura de cajas que un MP4— con la imagen comprimida en HEVC, que es un códec de vídeo. Abrirlo significa incorporar un descodificador de HEVC y lidiar con el consorcio de patentes que hay detrás, y de ahí que el soporte llegara tarde incluso a los productos de Microsoft y que no llegara nunca a la larga cola del software de escritorio pequeño. No es dejadez: es una dependencia real que un mapa de bits no tiene.

Tres bytes por píxel, una fila detrás de otra, cada fila rellenada hasta un múltiplo de cuatro bytes, más 54 bytes de cabecera. Una foto de iPhone de 12 megapíxeles a 4.032 por 3.024 necesita 12.096 bytes por fila, que ya es múltiplo de cuatro, así que salen 36.578.304 bytes de píxeles y 36.578.358 en total: 36,6 MB. El HEIC del que venía pesaba con toda probabilidad entre 1,5 y 2,5 MB.

Ese factor de veinte es a la vez el sentido del formato y su precio. Una toma de 48 megapíxeles a 8.064 por 6.048 se va cerca de los 146 MB. Cualquier cosa de ese tamaño se moverá con torpeza por un programa que esperaba un formulario escaneado, y varios importadores viejos tienen sus propios topes bastante por debajo, que es justo el argumento para fijar un ancho máximo durante la conversión en vez de descubrir el techo después.

Una cabecera de archivo de 14 bytes, una BITMAPINFOHEADER de 40, y después los píxeles: 24 bits cada uno, primero el azul, luego el verde y luego el rojo, con las filas escritas de abajo arriba. Las tres cosas parecen errores y las tres están en la especificación: el BMP se diseñó alrededor de cómo quería que se le alimentara una tarjeta gráfica de la época, y la disposición no cambió nunca.

Los dos campos de resolución se escriben con 2.835 píxeles por metro, que son 72 puntos por pulgada. Casi nada los lee, pero un cero ahí hace que algunos visores antiguos rechacen el archivo de plano, así que va un número de verdad. No hay tabla de colores, no se usa ningún campo de compresión y no hay perfil ICC, porque el formato tal como se escribe aquí no tiene dónde ponerlo.

Un HEIC puede llevar diez bits por canal y el iPhone aprovecha ese margen, sobre todo en los degradados suaves donde ocho bits enseñan sus escalones: un cielo despejado, una pared iluminada de lado, la piel con luz blanda. Lo que devuelve el descodificador en esta página es un búfer de ocho bits por canal, así que esos niveles adicionales se cuantizan por el camino.

En una fotografía destinada a una impresora de etiquetas o a un programa de gestión esto es invisible y da igual. Sólo importa si el programa que la recibe va a estirar mucho los tonos, porque un bandeado que no se veía en el original puede hacerse visible cuando el rango se separa. Si ése es el trabajo, guarda también el HEIC: el mapa de bits de ocho bits es la copia que le das a la máquina, no la copia que editas.

El iPhone etiqueta sus fotografías con el espacio Display P3, bastante más amplio que sRGB en los rojos y los verdes saturados. Un BMP no tiene campo para un perfil de color, así que esa etiqueta no viaja, y lo que lea el archivo tratará los números como si fueran sRGB.

El efecto práctico es un color saturado algo más apagado, no un desastre, y la mayoría del software industrial o de gestión habría ignorado el perfil de todos modos. Importa si el color tiene que ser exacto —cotejar un producto contra una carta de colores, documentar una lesión, fotografiar una montura—, y en ese caso esta ruta no es la buena y hace falta un formato que lleve el perfil dentro.

Un HEIC puede llevar canal alfa y algunos flujos de trabajo alrededor del iPhone lo producen. El mapa de bits no puede: el escritor emite 24 bits por píxel sin alfa alguno, así que todo lo transparente se compone sobre un color de fondo antes de escribir los píxeles.

Ese color es una opción de la página, y por defecto es el blanco. El aplanado ocurre sólo si la imagen de origen tiene transparencia de verdad, y el relleno se aplica antes de redimensionar, no después, porque rellenar y luego escalar mete el color de fondo dentro de los bordes y escalar antes de aplanar deja un halo oscurecido alrededor del recorte. Si un valor de color está mal escrito, se usa blanco. En una foto de cámara corriente nada de esto se nota, porque no hay nada transparente en ella.

El ancho máximo es el único ajuste de este par que cambia el resultado en un orden de magnitud, porque el peso del archivo es directamente proporcional al número de píxeles. Pasar de 4.032 píxeles a 1.024 deja los 36,6 MB en unos 2,4, y para una tarjeta, una etiqueta, una ficha de catálogo o un adjunto de un formulario eso es resolución de sobra.

Decide el número por lo que el programa hace con la imagen y no por lo que saca el teléfono. Una fotografía que se muestra a 300 píxeles en pantalla no gana nada con 4.032, y el BMP es precisamente el formato donde cada píxel de más se paga entero cada vez que el archivo se abre o se copia. El ajuste actúa sobre el ancho y el alto sale de él manteniendo la proporción.

De un HEIC se descodifica la primera imagen que contiene y sólo ésa. Un contenedor de iPhone puede llevar más de una —una ráfaga, los fotogramas de una Live Photo, un mapa de profundidad en los retratos— y el mapa de bits recoge una única fotografía fija.

Con ella se queda fuera todo lo que rodeaba a la imagen. Los datos EXIF, la fecha, los ajustes de cámara y las coordenadas del lugar de la toma no llegan al BMP, porque la conversión descodifica la imagen a píxeles y el escritor sólo escribe píxeles. Para publicar algo eso juega a favor, ya que la ubicación es el campo que la gente comparte sin darse cuenta. Para un archivo personal es una pérdida, y es la razón por la que los HEIC originales no se borran.

Suelta la selección completa en lugar de ir de una en una: hasta cien archivos por tanda, cada uno con su propio progreso, y los mapas de bits terminados se pueden recoger juntos en un ZIP, que además es la forma sensata de mover treinta archivos de 36 MB por una red. El tope de entrada son 100 MB por archivo, que cualquier HEIC supera con muchísimo margen; en este par lo que aprieta es la salida y no la entrada.

El HEIC se descodifica con libheif compilado a WebAssembly y el BMP lo escribe JavaScript, las dos cosas dentro de la pestaña. Nada de esto viaja a ningún servidor, y se puede comprobar mirando la pestaña de red mientras conviertes o, más contundente todavía, desconectando la red y convirtiendo igual. Escribir HEIC, en cambio, este sitio no lo hace: haría falta x265, que es GPL, así que es una decisión de licencia y no una carencia.