Convertir WebP a BMP

Es lo primero con lo que hay que contar y pilla a mucha gente, porque todas las demás conversiones que ha hecho dejaban el archivo más pequeño. El WebP existe para comprimir una imagen y entregarla; el BMP existe para guardar un rectángulo de píxeles sin ningún trabajo de descodificación. La aritmética es exactamente tres bytes por píxel más una cabecera de 54 bytes, sea cual sea la imagen.

Las muestras de este sitio lo concretan a 480 por 320: la fotografía pesa 14.700 bytes como WebP y 460.854 como BMP, la escena tipo captura 10.830 frente a esos mismos 460.854, y el gráfico plano 4.428 frente a 460.854 otra vez. La cifra del BMP no cambia nunca porque a un formato sin comprimir el contenido le da igual. Llevado a una imagen de 4.000 píxeles descargada de una web de fotografía, el BMP ronda los 48 MB.

El WebP son dos formatos con una sola extensión: una imagen fija y una animación. Buena parte de los pequeños gráficos en bucle de la web son del segundo tipo, y el descodificador que se usa aquí solo maneja el primero. El resultado es un rechazo con un mensaje legible y no una conversión silenciosa del fotograma uno.

De los dos fallos posibles es el mejor, y es deliberado: un conversor que te devuelve calladamente una décima parte del archivo es justo lo que este sitio intenta no ser. Se probaron contra el descodificador un WebP animado con pérdida y otro sin pérdida, y los dos fueron rechazados. Si solo querías un fotograma, ábrelo en un navegador, párala y haz una captura. Si lo que tiene que sobrevivir es el movimiento, WebP a GIF lo conserva, y un BMP nunca habría podido guardarlo.

De 24 bits y sin comprimir, con una BITMAPINFOHEADER: la línea base que entiende cualquier lector de BMP jamás escrito, incluidos los que viven dentro de un equipo embebido y ocupan doscientas líneas de C. No hay paleta, no hay codificación por longitud de tirada y no hay cabecera V5.

Tres detalles importan si eres quien programa lo que consume el archivo. Las filas se guardan de abajo arriba, así que una imagen que aparece del revés significa que el lector supuso lo contrario. Los canales van en orden azul, verde y rojo, así que una imagen con los rojos y los azules cambiados significa lo mismo. Y cada fila se rellena hasta un múltiplo de cuatro bytes, que es lo que produce ese sesgo diagonal cuando el paso de línea se calcula como ancho por tres. Los tres están en la especificación. El campo de resolución se escribe como 2.835 píxeles por metro, es decir 72 ppp, porque un cero ahí hace que algunos visores antiguos rechacen el archivo.

El WebP lleva un canal alfa real y muchísimas imágenes guardadas desde páginas web lo usan: logotipos, distintivos, recortes de producto, cualquier cosa pensada para apoyarse sobre el fondo de una página. El BMP que se escribe aquí no tiene alfa, así que la imagen se compone sobre un color macizo antes de codificarse, en la misma pasada que cualquier reescalado para que no quede una orla de píxeles semitransparentes.

El color es blanco por defecto y hay un control para cambiarlo. Ponlo a conciencia cuando el destino sea una máquina y no una persona: una rutina de inspección que umbraliza la imagen, o un controlador de pantalla que trata un color como su clave de transparencia, se comportan de forma completamente distinta contra blanco que contra negro o magenta. Si la transparencia es el punto —una máscara, una superposición, un logotipo que va sobre un fondo desconocido—, el BMP no puede expresarla y WebP a PNG sí.

Un WebP puede ser con pérdida o sin pérdida y la extensión no te dice cuál tienes delante. Si era con pérdida —que es lo habitual en las imágenes que sirve una web—, el codificador ya alisó las zonas planas y dejó timbre en los bordes duros, y eso son ahora los píxeles. Escribirlos en un contenedor sin comprimir los conserva exactamente y no recupera nada.

Importa porque «sin comprimir» se lee como «de alta calidad» y no es lo mismo. El BMP es una copia fiel de una imagen que ya venía perjudicada, treinta veces mayor y ni un poco mejor. Si el original existe en otra forma —el PNG de reserva que muchos sitios sirven junto al WebP, o el archivo antes de subirse—, convertir ese es lo único que mejora de verdad el resultado.

Merecen la pena cinco minutos con la documentación antes de asumir un archivo treinta veces mayor. Muchísimas herramientas embebidas, industriales y de laboratorio que enumeran BMP aceptan también PNG, que es sin pérdida, muchísimo más pequeño, lleva transparencia y tiene descodificador disponible para cualquier plataforma. Cuando los dos están en la lista, el PNG gana en todos los ejes.

Los casos de BMP obligatorio son reales y estrechos: un analizador que escribió alguien de la casa, un controlador de pantalla con kilobytes de ROM, un programa compilado en 1997 que nadie puede recompilar, o una práctica de asignatura que especifica el formato porque leerlo es el ejercicio. Para esas situaciones existe esta página, y en todas ellas el tamaño es una restricción de otro y no una decisión tuya.

Como el tamaño de salida es una función pura del número de píxeles, cambiar las dimensiones es lo único que lo mueve. La opción de ancho máximo escala la imagen antes de codificar, con un reescalado filtrado en lugar de tirando píxeles, así que el texto y los bordes quedan limpios en vez de convertirse en una escalera.

Si conviene usarla depende por completo del destino. Un panel embebido de 480 por 272 no gana nada con un origen de 2.000 píxeles y va a gastar tiempo y memoria reales en él; una rutina de visión artificial que espera una resolución concreta necesita esa y ninguna otra. El BMP en sí no impone ningún techo —a diferencia del WebP, que no puede pasar de 16.383 píxeles de lado—, así que aquí el límite es lo que el lector del otro extremo pueda mantener en memoria.

Un WebP puede llevar bloques EXIF y XMP dentro. Ninguno llega al BMP, porque la conversión descodifica a píxeles crudos y vuelve a codificar, y porque el formato de destino no tiene además dónde ponerlos: un BMP es una cabecera y una rejilla de píxeles, sin ningún compartimento para texto.

En esta página el asunto no tiene consecuencias prácticas, y se dice por coherencia con el resto del sitio más que por otra cosa. Si lo que quieres es precisamente limpiar un archivo sin cambiarlo de formato, hay una herramienta propia para quitar metadatos que trabaja sobre JPG, PNG y WebP sin volver a codificar la imagen.

Si el problema es simplemente que el software corriente no abre el archivo, WebP a PNG es la respuesta casi siempre: sin pérdida, admitido en todas partes, transparencia intacta y una fracción del tamaño del BMP. Si el destino es una persona —un correo, una imprenta, un laboratorio fotográfico—, WebP a JPG es lo que esa persona espera recibir.

Si la imagen tiene que entrar en un documento o en una solicitud que nombra un formato, WebP a PDF y WebP a TIFF existen y son bastante más probables que el BMP en lo que pide un formulario. El BMP se gana su sitio solo cuando algo inflexible lo ha nombrado, que es la suposición sobre la que está escrita esta página.

libwebp compilado a WebAssembly descodifica el archivo, y el BMP se escribe a mano en unas pocas decenas de líneas, porque el formato es una cabecera seguida de píxeles y no justifica cargar una biblioteca de imagen entera. No se sube nada, no hay cuenta, y el codificador solo se descarga cuando se suelta un WebP de verdad.

El límite gratuito es de 100 MB por archivo, mucho más de lo que va a pesar un WebP: aquí la restricción está en la salida y no en la entrada. Los lotes funcionan —hasta cien archivos, cada uno con su fila de progreso y un ZIP al final—, y como cada BMP son tres bytes por píxel, ese ZIP puede ser enorme. Una tanda de descargas en alta resolución conviene hacerla por grupos y no toda de una vez.