Análisis de las ventajas y desventajas de la tecnología WebP (2021)

 (eng.aurelienpierre.com)
2 puntos por GN⁺ 2023-12-17 | 1 comentarios | Compartir por WhatsApp
  • Con la compatibilidad de WebP en WordPress y los principales navegadores, se volvió más fácil migrar una biblioteca fotográfica, pero en fotos reales destacan más defectos como la posterización y el ringing que la reducción del tamaño de archivo
  • Google y varios plugins de WordPress indican que WebP es más pequeño que JPEG y que lossy 80 es suficiente, pero volver a convertir un JPEG existente a WebP puede acumular compresión con pérdida
  • En imágenes donde son importantes las gradaciones suaves, como retratos de estudio y escaneos de película, incluso WebP 95~96 muestra resultados similares o más pesados que JPEG 85+ruido
  • Comparar el SSIM promedio y el tamaño promedio de archivo no garantiza la respuesta ante el peor caso que necesitan los fotógrafos, y en sitios web donde es difícil ajustar la calidad imagen por imagen, la estabilidad es más importante
  • Si la calidad de imagen es importante, es más realista mantener JPEG 85~90, agregar dithering o ruido fino, evitar la recodificación de JPEG existentes a WebP y aprovechar CDN, imágenes responsivas y carga diferida

Expectativas al adoptar WebP y problemas reales

  • Como WordPress acepta subidas con el tipo MIME image/webp y desde septiembre de 2020 los principales navegadores ya pueden mostrar WebP, se volvió más fácil migrar una biblioteca fotográfica a WebP
  • WebP parece una opción atractiva por comparaciones que lo sitúan un 15% por debajo de JPEG a la misma calidad y por cifras de Google que hablan de archivos entre 25 y 34% más pequeños
  • En WordPress hay muchos plugins que convierten la biblioteca multimedia existente a WebP, y una buena parte funciona con un modelo SaaS que convierte en servidores externos
  • Algunos plugins y documentos técnicos indican que una calidad WebP de lossy 80 o más es innecesaria para la mayoría de las fotos, pero los ejemplos con logotipos no representan suficientemente los problemas del trabajo fotográfico real

Daño al recomprimir JPEG existentes a WebP

  • Después de convertir en lote medios de WordPress con calidad lossy 80, aparecieron anillos posterizados en el fondo
  • La imagen problemática era un escaneo en formato medio 6×7 cm tomado con una Mamiya RB 67 sobre película Ilford Delta 400, y el original partía de un escaneo de 16 bits
  • El grano de haluro de plata de Delta 400 funciona como un dithering natural y ayuda a evitar la posterización en áreas suaves, pero después de convertir a WebP las gradaciones se rompieron en escalones
  • El JPEG original con calidad 85 tampoco estaba completamente limpio, pero era mejor que la versión convertida a WebP, y el impacto principal vino de sumar otra compresión con pérdida de WebP sobre un JPEG ya comprimido con pérdida
  • Google Page Speed Insights y varios plugins recomiendan o facilitan este flujo de recodificación, pero el deterioro real de calidad no es seguro

Experimentos comparativos con fotos reales

  • Incluso en condiciones donde una foto RAW se codificó directamente desde darktable y se comprimió solo una vez, se confirmó la debilidad de WebP
  • La imagen de prueba era un retrato de estudio real, donde la iluminación que cae suavemente y la gradación del fondo son elementos importantes
  • Al guardar tanto JPEG como WebP con calidad 90 y aplicar Floyd-Steinberg dithering de 8 bits:
    • Tanto JPEG 85 como WebP 90 se evaluaron como fallidos
    • En WebP el contraste de los anillos posterizados era mayor, por lo que se veía peor
    • WebP 90 seguía teniendo el problema aunque su calidad era 10 puntos superior al valor recomendado lossy 80
    • JPEG 90 se veía aceptable, pero el archivo era más grande
  • Al guardar WebP en modo sin pérdida, la calidad quedó limpia, pero el tamaño de archivo no fue satisfactorio; JPEG 90 era difícil de distinguir con cerca de un tercio de ese tamaño, y JPEG 95 se veía similar con poco más de la mitad del tamaño
  • En pruebas donde se agregó ruido aleatorio de -48 dB PSNR en lugar de Floyd-Steinberg dithering, WebP siguió siendo más vulnerable a la posterización
    • La calidad de WebP que se suavizaba de forma similar a JPEG 85+ruido estuvo entre 95 y 96
    • En esas condiciones, WebP fue 39% más pesado que JPEG 85+ruido, e incluso 30% más pesado que JPEG 90+Floyd-Steinberg dithering
    • En el resultado de WebP seguía quedando un ringing débil

La brecha entre las métricas promedio y la calidad fotográfica

  • La evaluación de la superioridad de WebP depende en gran medida del SSIM promedio y del tamaño promedio en bits dentro de conjuntos de imágenes
  • Los valores promedio no garantizan la estabilidad de salida que un fotógrafo necesita en un portafolio web
    • Un portafolio fotográfico no es un entorno donde el backend de compresión pueda fallar al azar
    • Ajustar con precisión la calidad de WebP para cada imagen consume mucho tiempo, y en WordPress ese enfoque también parece difícil
  • SSIM es una métrica de similitud de imágenes basada en promedio, varianza y covarianza, por lo que no refleja suficientemente las métricas perceptuales reales y sigue siendo discutida
  • En los daños por compresión, importa no solo la magnitud de la desviación numérica sino también la naturaleza de los artefactos
    • El ruido aleatorio puede tolerarse hasta cierto punto
    • Las manchas con patrón o las gradaciones en escalones arruinan mucho más una fotografía

Escenas donde WebP es especialmente débil

  • En trabajo fotográfico, las escenas más difíciles suelen ser las de gradaciones suaves más que las de detalle nítido
  • En situaciones donde una luz cercana a una fuente puntual cae sobre una pared y crea un fondo natural, el fondo debe tener suficiente textura sin robar atención al sujeto
  • Los ejemplos de compresión WebP suelen mostrar escenas nítidas, con gran profundidad de campo y mucho detalle de alta frecuencia, pero esas escenas tienen baja probabilidad de posterización y no revelan bien las debilidades del algoritmo
  • La falta de nitidez no necesariamente arruina una foto, pero que un viñeteado suave se rompa en escalones es un deterioro difícil de aceptar

Diseño del formato y problemas de color

  • WebP usa formato RGB o RGBalpha, por lo que no puede guardar imágenes en blanco y negro como imágenes de grises de un solo canal
  • En las pruebas, la posterización observada empeoró con anillos magenta y verdes, interpretados como desplazamientos de color por submuestreo de croma
  • Si un formato en blanco y negro puro pudiera guardarse como un solo canal, podría evitar generar desplazamientos de croma adicionales
  • AVIF resolvió este punto, pero se estima que pasarán al menos 10 años antes de que sea una realidad técnica ampliamente extendida

Medidas para proteger la calidad de imagen

  • Si se trata de un sitio web donde la imagen es importante, especialmente el portafolio de un artista visual, se considera mejor mantener una calidad JPEG de 90 o al menos 85
  • Para proteger las gradaciones suaves, se recomienda agregar siempre dithering o un ruido muy leve a la imagen
  • Es mejor no convertir JPEG existentes a WebP, salvo cuando se pueda aceptar un deterioro del nivel mostrado en los ejemplos anteriores
  • Para mejorar la velocidad de carga y la capacidad de respuesta percibida, es más seguro aprovechar un CDN, tamaños de imagen responsivos y carga diferida de imágenes que depender de una conversión de formato
  • El modelo SaaS que convierte en servidores externos tiene costo, no revela los coeficientes reales de calidad y puede generar errores de conexión HTTP en entornos WordPress reforzados con plugins de seguridad
  • Es preferible ejecutar ImageMagick o GraphicsMagick directamente en el servidor, y se recomienda un enfoque que use el programa del servidor de forma directa en lugar de la interfaz de PHP
  • Si desarrolladores técnicos y diseñadores de algoritmos de imagen imponen la elección de formato basándose solo en métricas promedio, pueden causar pérdidas de tiempo y dinero a artistas reales

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-17
Opiniones de Hacker News

  • Vi el mismo problema también en WebP, así que en su mayoría volví a JPG/PNG: uso jpg para fotos y png para imágenes tipo UI.
    El verdadero problema parece ser que mucha gente no nota la diferencia, y creo que se debe a que, durante los últimos 10 años, los monitores de escritorio quedaron en una zona olvidada sin innovación. La mitad de los que están aquí probablemente estén viendo las imágenes de ejemplo en un LCD 1920x1080 de alrededor de 2012, y eso también es parte del problema.
    Curiosamente, las pantallas pequeñas como las de los teléfonos y las grandes como las TVs 4K han alcanzado una excelente densidad de píxeles en relación con la distancia de visualización, pero los paneles de 20 a 40 pulgadas siguen estancados en niveles de mediados de los 2000.
    También creo que habría sido mejor si el autor hubiera usado una foto de ejemplo con fondo claro o cambiado el fondo del artículo a negro. Una imagen negra sobre fondo blanco hace que al ojo le cueste adaptarse, lo que dificulta ver el problema; puesta sobre un fondo oscuro, la diferencia se ve mucho más fácilmente.

    • Incluso en dos pantallas de la época de 2012, los artefactos de compresión se ven bien. Una es un monitor IPS de 30 pulgadas 2560x1600 bastante bueno para su época, y la otra es una TV TN 1080p de 27 pulgadas de gama básica.
      Por eso no creo que la calidad de la pantalla sea el problema principal. Podría ser un tema de drivers o de filtros de posprocesamiento, o simplemente que no todo el mundo tiene ojo para estas cosas.
      Si te interesa el procesamiento de imágenes, por experiencia terminas viendo este tipo de detalles. El autor claramente tiene más experiencia que yo, y puede que detectar estos detalles sea parte de su trabajo. Es muy probable que pueda reconocer el problema incluso en un monitor pésimo y decirte también de qué manera ese monitor es pésimo.
    • Incluso en un monitor 4K de 27 pulgadas cuesta mucho notar la diferencia, y ni siquiera estoy seguro de estar viéndola realmente.
      El ejemplo es malo. Si quieres mostrar algo, deberías ampliar una captura de pantalla y mostrar los artefactos.
    • Del lado de Apple, las laptops y los monitores de escritorio han evolucionado bien desde hace casi 10 años, con alto PPI, brillo y precisión de color casi como estándar. Eso sí, son caros, y en PC a la mayoría no le importa, así que es una de las primeras cosas que se recortan.
    • Estoy de acuerdo respecto a JPG, pero si usas WebP sin pérdida en lugar de PNG, ¿no se mantienen los píxeles tal cual y solo queda un archivo alrededor de un 30% más pequeño que ese PNG? Incluso comparado con PNG ya fuertemente optimizados con zopfli/optipng y similares, queda alrededor de un 15% más chico.
      Al convertir PNG a WebP, ¿el “lossless” de “lossless WebP” en realidad no es sin pérdida?
      Como referencia, si conviertes un PNG a WebP sin pérdida, luego lo descomprimes de nuevo a PNG, y después conviertes ese PNG otra vez a WebP, obtienes un archivo WebP sin pérdida completamente idéntico. Da el mismo WebP tanto si lo codificas directamente desde el PNG como si lo haces desde el mismo PNG “crushed” con un optimizador de PNG.
    • Aquí uso una pantalla IPS 4K de 27 pulgadas, y para ver la diferencia de la que habla el autor tengo que entrecerrar los ojos o hacer zoom.
      Está bien que haya gente a la que realmente le importe obtener el mejor resultado posible, pero creo que la mayoría ni lo notaría ni le importaría.

  • Abrí las dos primeras fotos en pestañas separadas y cambié rápidamente entre ellas, pero no hay ninguna diferencia. Lo probé en dos monitores distintos, en Chrome y Firefox, y con las últimas fotos del hombre pasó lo mismo.
    Edición: la última comparación tenía WebP dos veces y el enlace estaba mal. El jpg está aquí, pero aun así no veo diferencia
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • En mi opinión, la peor desventaja de WebP y la más fácil de distinguir es el submuestreo de croma 4:2:0 obligatorio. En muchas imágenes con colores brillantes, la pérdida de color y luminosidad se nota claramente incluso sin ojo profesional.
    En la comparación [1], se ve claramente que el globo de la parte superior derecha perdió su rojo vivo, y en la comparación [2], el arte de neón azul brillante del centro perdió luminosidad.
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • No quiero avivar más la discusión, pero en los dos ejemplos enlazados no noto ninguna diferencia. Habría ayudado que ese sitio al menos permitiera arrastrar una barra vertical de comparación. Lo vi en la pantalla de un iPhone 14.
    • Gracias por ese enlace; para mis ojos sí se detecta, pero para uso en sitios web parece despreciable. ¿Qué pasa con la saturación?
      Me pregunto por qué este comando produce un azul claro pálido al convertir de jpg a webp, mientras que los otros colores salen razonablemente bien.
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • Este artículo no aborda el problema que más siento con WebP. Fuera del navegador, la incomodidad de este formato pesa más que el pequeño ahorro de tamaño.
    Hay formatos mejores. Están los formatos inspirados en códecs de video, como los que pueden salir de HEIF, AVIF o H.266, y también JPEG XL; WebP parece un compromiso sin suficientes ventajas.

    • Clic derecho, guardar como, y... ay, otra vez WebP.
    • WebP en realidad también está basado en un códec de video. Solo que VP8 parece no haber logrado mucha presencia en codificadores/decodificadores por hardware.
    • Una realidad peor que la del artículo original es que podrías terminar lidiando con una imagen JPEG convertida a WEBP y luego vuelta a convertir a JPEG. Después quizá alguien editó ese JPEG y volvió a convertirlo a WEBP.
      Mucha gente discute si se ve o no banding en una imagen WEBP cercana a las mejores condiciones, pero en la realidad las imágenes WEBP por lo general se ven horribles. Recién hace poco empecé a notarlo en serio.
      Claro que ahora se pueden “limpiar” imágenes mediante procesos de escalado generativo, pero es bastante irónico gastar tanta electricidad porque alguien quiso ahorrar 45 KB.
      Esto también me recuerda a cuando los GIF se convertían a JPEG. Hace unos 25 años había muchas capturas de pantalla limpias en GIF para las que 256 colores eran suficientes, y JPEG las arruinó.
      Google les dice a los desarrolladores que usen WEBP, pero no tiene ningún problema en servir petabytes de anuncios de video que nadie quiere ver.
    • Ahora hablemos también de HEIF. En escritorio es un formato incómodo, tanto dentro como fuera del navegador.

  • Si la idea es “puede verse bien para ojos no expertos, pero no para un fotógrafo”, creo que debería haber mejores ejemplos para mostrarles a los “no expertos” por qué WebP es malo y justificar el texto y el tono.
    Tal vez sea porque lo estoy viendo en Android, pero la calidad de todas las fotos me parece igual.
    Y si vas a crear fotos para “ojos expertos”, ¿no basta con no usar una tecnología que no está a la altura de esos ojos expertos? ¿O con no dejar esa decisión en manos de otros?

    • El punto del autor es que, si estás creando este tipo de tecnología, deberías tener ojo experto.
      Viendo en este hilo los comentarios de gente que dice disparates y afirma con seguridad que no hay diferencia, su frustración parece justificada. Está bien no ver la diferencia en las primeras imágenes, pero no deberías afirmar con seguridad que sabes más que el autor ni diseñar códecs de imagen.
    • Yo también lo vi en Android.
      Pude verlo sin ponerlo en pantalla completa. Hay que mirar al hombre que está haciendo una mueca y luego el borde de la camisa cerca del hombro.
      En la foto de mala calidad aparece un halo de luz alrededor del hombro, casi como si estuviera a contraluz.
      En la foto de buena calidad, el degradado es suave. No hay un halo de contraluz alrededor del hombro; simplemente parece un fondo con un degradado suave.
      Para dejarlo claro, no soy fotógrafo sino ingeniero DevOps. La última vez que usé JavaScript profesionalmente fue hace al menos 11 años.
      Se ve con bastante facilidad.
    • Vean la discusión aquí [1]. Para distinguirlo hay que verlo en tamaño completo.
      [1] https://news.ycombinator.com/item?id=38653224
    • Cualquiera que haya trabajado con códecs sabe que no se compara un códec con una sola imagen.
      Toda la idea base de esta entrada de blog no parece intentar pasar una validación básica como comparación entre formatos, sino generar más quejas y clics.

  • Para dar un poco de contexto, Aurelien Pierre es conocido como uno de los principales colaboradores de Darktable. Darktable es una herramienta open source de revelado/catalogación RAW, básicamente un Adobe Lightroom open source.
    Es conocido por tener opiniones fuertes sobre la forma correcta de hacer las cosas, a veces hasta el punto de ser áspero, y también hizo un fork de Darktable en su propio proyecto llamado Ansel. Ya había habido una discusión en HN antes: https://news.ycombinator.com/item?id=38390914

    • Tengo que revisar Ansel. ¿Alguien sabe si todavía es compatible con el formato de Darktable?

  • Si te importa la calidad de las imágenes de archivo, no recomprimirías imágenes antiguas a un formato nuevo, salvo que puedas hacerlo desde originales sin comprimir. Reencodificar desde una fuente con compresión con pérdida empeora la calidad. El almacenamiento es barato y sigue abaratándose.
    Lo que sí tiene sentido es elegir configuraciones seguras al comprimir fotos nuevas en un formato nuevo.

    • Se dice que JPEG XL puede reencodificar archivos JPEG existentes a archivos 20% más pequeños sin pérdida de calidad.
      En este contexto, Google ha bloqueado JPEG XL al eliminar el soporte en Chrome y negarse a restaurarlo, argumentando que no ofrece suficientes “beneficios incrementales” frente a formatos existentes como WebP.
    • Es cierto, pero ese no es el punto central. Incluso partiendo de un degradado perfecto guardado como PNG, WebP muestra banding visible con -q100, mientras que JPEG es visualmente transparente incluso con -q90.

  • Creo que el autor se enfocó en el lugar equivocado. Se concentró en las diferencias entre formatos, pero en realidad debería haberse enfocado en los métodos de compresión. Cada programa de procesamiento de imágenes produce resultados distintos aun cuando se use el mismo número, por ejemplo “80”, como configuración de compresión.
    Para hacer una comparación realmente significativa, habría que probar una variedad de imágenes: no solo retratos de estudio en blanco y negro con fondos de degradado suave, sino también imágenes a todo color con fondos complejos. También habría que considerar distintos programas, como imagemagik, graphicsMagick, sharp, photoshop y varios servicios en la nube.
    Otro problema es el caso de uso. Si un fotógrafo profesional quiere subir una foto en tamaño completo y con la máxima calidad, quizá sea mejor simplemente no comprimirla para preservar por completo el resultado creativo/de edición. Pero ese caso de uso no es el caso promedio de un sitio web que muestra imágenes de tamaño y calidad razonables.
    En muchas situaciones, una imagen mucho más pequeña vale la pena aunque implique una compresión más fuerte, y en muchas imágenes la compresión no será tan visible como en una foto profesional de estudio a resolución completa con un gran fondo degradado.

  • Personalmente no veo una diferencia significativa, así que mis ojos claramente parecen ser “ojos de no experto”.

    • Depende mucho del dispositivo. En una máquina Windows del trabajo veo un poco de banding; en el celular se ve peor, y en la MacBook es horrible.
    • Lo más probable es que, como la mayoría, estuvieras mirando solo el primer plano. Incluso en un dispositivo Android 12 pequeño, si lo ves sin pantalla completa, el color del fondo alrededor del borde de la camisa y en los bordes de la foto cambia notablemente entre imágenes.
      De lo que se queja el autor son los artefactos en el fondo de la imagen.
    • Tengo mala vista y no estoy entrenado, pero después de que me señalaron los defectos y volví a mirar, son bastante claros.
    • Qué suerte. Una vez que notas el problema de banding, quedas maldito y lo ves en todas partes.
    • Curiosamente, ya podía ver claramente la diferencia antes de leer. El dispositivo que uso es una MacBook Air de 11 pulgadas de hace 9 años, así que no es mala, pero tampoco es equipo de gama alta.
      Es fascinante que la percepción varíe tanto entre personas.

  • Los degradados de WebP a menudo se ven como fotogramas de video. El subsampling de croma reduce la densidad de aproximaciones de luminancia disponibles, y cuanto más fuerte se aplica, peor se ven los degradados.
    El contraste alto y los detalles de alta frecuencia no se ven muy afectados, pero los degradados pueden arruinarse bastante.

    • Decir que “el subsampling de croma reduce la densidad de aproximaciones de luminancia” es casi lo contrario.
      Croma significa color, y el subsampling de color se usa para no quitar información del canal de luminancia, que es más importante.
    • En WebM/VP9 tampoco es raro ver banding bastante fuerte en degradados oscuros, así que esta explicación tiene cierto sentido.
    • WebP usa YCbCr de rango limitado, como el video, mientras que JPEG usa YCbCr de rango completo. Por eso, en monitores que usan valores RGB completos, un JPEG en escala de grises se ve perfecto, mientras que WebP puede mostrar un poco de banding al representar contenido en escala de grises.