Convertir BMP a WebP

Un BMP de veinticuatro bits de 1920 por 1080 ocupa 6,2 MB, y ocupa 6,2 MB tanto si es una fotografía como si es un rótulo plano de dos colores, porque el formato escribe tres bytes por píxel y no comprime ninguno. Ponlo en una página y la página es él: el HTML, la hoja de estilos, las tipografías y los guiones juntos son un error de redondeo a su lado.

WebP se diseñó justo para ese sitio. Gasta bits donde hay detalle y prácticamente ninguno donde no lo hay, que es por lo que la misma imagen llega en decenas o cientos de kilobytes. La conversión no es una optimización marginal: en una página con una imagen arriba, esa imagen es lo que la métrica de mayor elemento visible está cronometrando, y la diferencia es la que hay entre pasar la medición y no poder pasarla.

Casi nunca de alguien que eligió el formato. Salen de una aplicación de gestión escrita hace veinte años que exporta a BMP y solo a BMP, del programa que vino con un escáner de sobremesa, de un equipo de laboratorio o de un instrumento de medida que guarda capturas, de una utilidad interna que nadie mantiene. En muchas administraciones y empresas medianas esos programas siguen en producción precisamente porque funcionan.

El registro clasifica BMP como formato heredado, publicado en 1987, y le anota los archivos enormes entre sus problemas conocidos. Lo relevante para quien lee esto es que el mapa de bits casi siempre es un intermedio accidental: nadie lo quería, apareció en la carpeta. Convertirlo no pierde nada que alguien hubiera decidido conservar.

WebP tiene un modo sin pérdida, y es una de las razones por las que existe. El codificador de esta página escribe la variante con pérdida, con una calidad de 82 por defecto, porque es lo que debe ser una imagen publicada.

Conviene decirlo con claridad, porque significa que esta conversión no se puede deshacer. Si lo que querías era una copia exacta del mapa de bits en un envase más pequeño, esta es la página equivocada y PNG es la correcta. Ese 82 es además el mismo número para JPG, WebP, AVIF y JXL: no hay valores por defecto por formato, hay uno solo, y es lo bastante alto como para que casi nadie distinga el resultado del original a tamaño normal.

Aquí hay una respuesta incómoda y preferimos darla. Nuestro registro anota BMP sin canal alfa, y ese campo no describe lo que la especificación del formato permite sino lo que un lector obtiene de verdad al final del recorrido. Estuvo puesto al revés durante un tiempo y el resultado fue que diez páginas de este sitio publicaron «la transparencia sobrevive» sobre conversiones cuya salida era opaca.

Así que no vamos a afirmarte que las zonas transparentes de un BMP de treinta y dos bits lleguen al WebP, ni tampoco lo contrario, porque no es una cosa que nuestro código deje resuelta. Lo que sí es seguro es que WebP no está entre los destinos que este sitio aplana contra un color de fondo, de modo que no se te va a pedir que elijas un blanco ni se va a rellenar nada por tu cuenta. Si la imagen tiene zonas que deben verse a través, abre el WebP sobre un fondo de color antes de publicarlo y compruébalo con los ojos: son diez segundos y esa comprobación vale más que cualquier frase nuestra.

Es un límite del formato y no de este conversor, y es lo único que puede hacer la conversión imposible en lugar de meramente imperfecta. Ninguna de las dos dimensiones de un WebP puede pasar de 16.383 píxeles; nuestro registro lleva esa cifra anotada como el techo del formato.

Las imágenes corrientes no se acercan: una fotografía de 4000 por 3000 tiene muchísimo margen. Lo que sí llega son justamente las cosas que aparecen en BMP —un documento escaneado a resolución alta, una panorámica cosida, la salida en tira larga de un instrumento—. Si tu mapa de bits es de esos, reduce el ancho antes o usa PNG, cuyo techo propio está en el orden de los dos mil millones de píxeles por lado y por tanto es teórico. Merece la pena mirar las dimensiones antes de convertir una carpeta entera.

WebP salió de Google en 2010 y se pasó su primera década con un asterisco al lado. Eso se acabó: nuestro registro le da la misma marca de soporte de navegador que a JPG y a PNG, «todos», y las herramientas de diseño y de contenido lo leen sin ceremonia.

Lo cual cambia de qué va la decisión en esta página. Ya no es si el público podrá ver la imagen; es únicamente si la pérdida es aceptable para esta fotografía concreta. Esa pregunta es mucho más fácil y para casi todo lo que se publica la respuesta es que sí. AVIF, la alternativa más nueva, sigue marcada como de soporte moderno, y esa sola palabra es la diferencia práctica entre las dos cuando eliges qué servir sin alternativa de reserva.

El error más común en esta dirección es convertir el mapa de bits con sus dimensiones originales y ponerlo en una columna de 600 píxeles. El navegador se descarga entonces varias veces los datos que puede enseñar y tira el resto al escalar, y no hay ajuste de codificación que recupere eso.

Pon el ancho máximo al mayor tamaño al que la imagen se vaya a dibujar nunca, doblado si tiene que verse nítida en una pantalla de alta densidad. El redimensionado ocurre en el mismo paso de lienzo que todo lo demás, así que la imagen se escala una sola vez y con suavizado de calidad alta, y el ahorro es proporcional al número de píxeles y no al ancho: reducir el ancho a la mitad quita tres cuartas partes de los datos. El control actúa solo sobre el ancho; la altura sale sola manteniendo la proporción.

Una parte grande de los BMP que circulan son capturas de pantalla, y los codificadores con pérdida tratan mal el texto: los bordes duros de una letra son exactamente el contenido de alta frecuencia que están construidos para descartar. Es un argumento fuerte contra JPG para este material y uno más suave contra WebP, que se porta mejor con las fronteras nítidas al mismo ajuste sin que le salgan gratis.

Para una captura que tiene que leerse, el orden honesto es PNG primero, después WebP con la calidad subida y JPG muy por detrás. Y con frecuencia el PNG será además el archivo más pequeño, porque las regiones planas y los bordes duros son justo en lo que la compresión sin pérdida es buena y la compresión con pérdida es mala, así que en este material el intercambio habitual ni siquiera se plantea. Para una fotografía, WebP a 82 sin tocar nada es la respuesta y esta ordenación da igual.

Nuestro registro no le anota a BMP ningún contenedor de metadatos: ni EXIF, ni XMP, ni perfil ICC incrustado. WebP puede llevar los tres y aquí no hay nada con lo que rellenarlos, y además la conversión descodifica la imagen a píxeles y la vuelve a codificar desde píxeles, camino por el que no pasa ningún bloque de metadatos aunque lo hubiera.

Para una imagen de web eso es sobre todo cómodo: el archivo es tan pequeño como los píxeles permiten y no lleva nada que diga de dónde salió. Importa si el mapa de bits venía de una cadena con gestión de color y esperaba interpretarse en un espacio concreto, porque el WebP se leerá como sRGB y en este camino no hay nada que diga otra cosa.

Suelta el conjunto. Cada mapa de bits se descodifica y se vuelve a codificar por turno en tu propia máquina, conserva su nombre con la extensión cambiada y todo vuelve en un solo archivo comprimido. No hay cola, ni cuenta, ni cupo diario, y el techo por archivo son 100 MB, que para un BMP de 1920 por 1080 es dieciséis veces su tamaño. Se admiten hasta cien archivos por tanda; si sueltas más, el excedente se descarta sin avisar.

Hacerlo en local pesa aquí más que la velocidad. Imágenes de un sitio que todavía no ha salido, fotografías de producto bajo embargo, capturas de una aplicación interna: todo eso se le estaría entregando a un tercero a cambio de una pasada de compresión que puedes ejecutar tú. Y si dos archivos del lote se llaman igual, el comprimido los numera en vez de sobrescribir uno.

Cada archivo convertido conserva su nombre original con la extensión cambiada, que es lo que hace usable un lote y también donde el trabajo se queda corto. Todas las referencias al archivo viejo —en una plantilla, en una hoja de estilos, en una entrada de contenido, en un manifiesto— siguen apuntando a un nombre terminado en `.bmp`, y una imagen que falta es un fallo mucho más visible que una imagen que pesa.

La otra mitad es acordarse de quitar los mapas de bits de lo que se despliega. Una compilación que copia un directorio de recursos entero se llevará las dos copias, con lo que el repositorio crece, el despliegue crece y los megabytes que esta conversión venía a eliminar se siguen transfiriendo a alguna parte. Convierte, actualiza las referencias, borra los originales del proyecto y guárdalos fuera si son los únicos maestros que tienes.