Notas del equipo sobre el oficio, los formatos y las pequeñas decisiones detrás de un buen resultado.
Por qué el WebP no es compatible en todas partes en los programas de escritorio
Google lanzó el WebP en 2010, pero la adopción por parte del software de escritorio quedó muy por detrás de la compatibilidad de los navegadores. Los navegadores adoptaron el WebP pronto porque controlan sus propios motores de renderizado y Google optimizó activamente la compatibilidad WebP de Chrome como ventaja competitiva. Las aplicaciones de escritorio tardan más en adoptar un nuevo formato de imagen porque cada una mantiene su propia pila de decodificación, y admitir un formato nuevo exige probarlo contra una larga serie de casos límite. Adobe Photoshop, usado por la mayoría de los fotógrafos y diseñadores profesionales, no incorporó compatibilidad nativa con WebP hasta la versión 23.2 a finales de 2022. Las aplicaciones de Microsoft Office todavía tratan el WebP de forma inconsistente entre plataformas en 2026. El software RIP de impresión y la mayoría de las herramientas heredadas de archivo nunca adoptaron el WebP. La consecuencia práctica es que un archivo que se ve perfecto en un navegador puede ser rechazado por completo por el software que el usuario necesita, y convertir a PNG es la solución fiable.
Cómo el WebP logra su ventaja de compresión sobre el PNG
El PNG usa compresión DEFLATE, un algoritmo sin pérdida de uso general de 1996. Aplica un conjunto de filtros reversibles por línea antes de comprimir y codifica el resultado con un flujo zlib. Es eficaz pero se diseñó antes de que el aprendizaje automático y la investigación en códecs de vídeo dieran técnicas mejores. El modo con pérdida del WebP usa una transformación por bloques derivada de la compresión de vídeo VP8, aplicando predicción intra-fotograma y una transformada de coseno discreta a unidades de macrobloques de 16x16. El modo sin pérdida del WebP usa predicción espacial, transformación de color y una etapa de codificación LZ77 estructuralmente más eficiente que DEFLATE para el contenido de imagen típico. Los datos de Google muestran el WebP sin pérdida un 26% más pequeño que el PNG. El WebP con pérdida y alfa es cerca de tres veces más pequeño a igual calidad visual. La dirección de PNG a WebP aprovecha estas ganancias, la dirección de WebP a PNG las revierte, de ahí el resultado más grande.
Ejemplos medidos de crecimiento del tamaño del archivo
Medido en Chrome 148, escritorio Linux, usando la ruta de escritura PNG del sistema aplicada a entradas WebP decodificadas. Un gráfico vectorial de 400×300 píxeles, guardado como WebP a calidad 80, se decodifica y reescribe como PNG en 15 a 25 ms. El crecimiento típico de tamaño es del 20 al 30%. Un WebP fotográfico a 1024x768, pequeño, se decodifica y se vuelve a escribir en PNG en menos de 100 ms con un crecimiento típico de 3 a 5 veces. Un WebP fotográfico grande a 3840x2160, más grande, se escribe en PNG en unos 1,2 segundos con un crecimiento de 5 a 10 veces según la complejidad de la escena. El límite superior práctico es aproximadamente una fotografía WebP de gran tamaño que pasa a ser un PNG de mucho mayor tamaño. Estos números reflejan la diferencia de eficiencia de compresión entre los dos formatos y crecen de forma lineal con el número de píxeles.
La transparencia alfa en el viaje de ida y vuelta
El canal de transparencia de 8 bits en WebP y PNG usa el mismo rango de valores, donde 0 es totalmente transparente y 255 es totalmente opaco. Cuando el navegador decodifica un WebP con alfa, produce un búfer de píxeles con valores RGBA donde el componente A refleja los datos alfa originales. Cuando ese búfer se vuelve a escribir como PNG, el escritor PNG coloca los valores A directamente en el canal de transparencia del PNG. No ocurre ningún paso de composición, no se aplica ningún color de fondo y ningún efecto de premultiplicación altera los valores de los píxeles. El resultado es una transferencia sin pérdida del canal de transparencia, donde el valor de opacidad de cada píxel en el PNG coincide con lo que el WebP había guardado. Para imágenes con suavizado fino en los bordes, cada valor alfa intermedio, por ejemplo un píxel al 40 por ciento de opacidad en el borde de un texto, sobrevive intacto al viaje. Esa fidelidad es lo que hace del PNG la opción correcta frente al JPG cuando la aplicación de destino tiene que mostrar la imagen sobre varios fondos.
Comportamiento de EXIF y los metadatos
La ruta de reescritura quita los metadatos EXIF, IPTC y XMP del PNG resultante. Los archivos WebP pueden llevar datos EXIF incrustados en su bloque de metadatos, y esos datos se pierden cuando el navegador decodifica y vuelve a escribir la imagen. Los perfiles de color ICC siguen una ruta distinta, donde Chrome y Safari conservan la etiqueta del perfil ICC sRGB en el PNG resultante tras decodificar el WebP, y Firefox quita todos los metadatos incluido el perfil ICC. La consecuencia práctica es un resultado seguro en sRGB en todos los navegadores, pero cualquier perfil de gama amplia incrustado en el WebP de origen no sobrevive en Firefox. Para flujos de trabajo fotográficos profesionales que dependen de viajes con etiqueta ICC, usa una herramienta de conversión que cuide los metadatos. Para el manejo normal de imágenes web, quitar los metadatos suele ser aceptable y tiene la pequeña ventaja de reducir levemente el tamaño del archivo resultante.
Verificación de la privacidad en la práctica
La afirmación de que ningún dato del archivo sale del navegador se puede comprobar sin ninguna herramienta especial. Abre tu navegador, ve a la página webp-to-png, luego abre las herramientas de desarrollo con F12 o el menú del botón derecho. Cambia a la pestaña Red, borra las solicitudes existentes y ejecuta una conversión soltando un archivo WebP. Filtra la lista de solicitudes por Fetch, XHR o Todo. La lista muestra cero solicitudes salientes con datos de imagen durante la escritura. Las únicas solicitudes de red son los recursos de carga inicial y los pings de análisis habituales. Estos solo registran vistas de página y datos de rendimiento, sin ningún contenido de imagen. Todo conversor de WebP a PNG remoto de relieve genera como mínimo una POST de subida y una GET de descarga por conversión, ambas registradas en el servidor. La arquitectura en el dispositivo hace que esas entradas de registro no existan, lo que es la diferencia significativa para los usuarios que convierten archivos con contenido sensible.
