WebP es increíble, excepto que no lo es (2021)

Artículo original ↗ Discusión en Hacker News ↗

La crítica de un fotógrafo al formato de imagen WebP de Google provoca un debate sobre si sus artefactos de compresión —especialmente el banding en gradientes suaves— lo hacen inadecuado para fotografía de alta calidad, aunque muchos apenas los noten. Los comentaristas comparan WebP con JPEG, AVIF y JPEG XL, y discuten las compensaciones entre tamaño de archivo, fidelidad visual, soporte de hardware, duración de la batería y compatibilidad retroactiva. Un tema recurrente es que las herramientas automáticas y los incentivos de PageSpeed de Google empujan conversiones masivas de JPEG a WebP que pueden degradar imágenes importantes por ganancias modestas en el mundo real.

Calidad de imagen percibida y banding

  • El hilo se divide entre quienes ven “ninguna diferencia en absoluto” y quienes encuentran los artefactos de WebP “inmediatamente obvios”.
  • La principal queja: una fuerte posterización / banding en gradientes suaves (por ejemplo, fondos de retratos, viñeteados), especialmente en WebP con pérdida.
  • Una vez notado, algunos dicen que ya son “incapaces de dejar de ver” el banding en muchas imágenes WebP de la web.
  • Otros sostienen que, para las imágenes web típicas (pequeñas, recargadas o decorativas), estos artefactos son en la práctica irrelevantes.

Dispositivo, pantalla y condiciones de visualización

  • La visibilidad de los artefactos depende mucho del dispositivo y del contexto:
    • Las habitaciones oscuras y las pantallas brillantes, de alta calidad o de amplia gama hacen que el banding sea mucho más evidente.
    • Algunos lo ven claramente en paneles antiguos o baratos; otros apenas lo notan en portátiles o móviles.
  • El escalado/redimensionado importa: las vistas previas WebP “sin pérdida” en línea y reducidas pueden mostrar artefactos que el archivo a tamaño completo no muestra.

Casos de uso: fotógrafos frente a la web general

  • Muchos aceptan que, para fotografía profesional, portfolios o fotos de producto, los problemas de gradientes de WebP son inaceptables.
  • Otros insisten en que es “suficientemente bueno” para la web: para blogs, capturas de pantalla de interfaces, miniaturas, etc., los artefactos de WebP rara vez importan.
  • Algunos señalan que el estándar del autor es “alto como el de un fotógrafo”; los desarrolladores web a menudo priorizan tamaño, velocidad y duración de batería.

JPEG, WebP, AVIF, JPEG XL

  • JPEG:
    • Con buenos codificadores (mozjpeg, ajuste fino, dithering), sigue siendo competitivo; a menudo necesita solo unos pocos bytes más que WebP para una calidad percibida similar.
    • Se citan como ventajas el JPEG progresivo y la madurez de sus herramientas.
  • WebP:
    • Se elogia por la transparencia, la animación y por ser un reemplazo sin pérdida más pequeño que PNG.
    • Se critica su submuestreo de crominancia forzado 4:2:0, el YCbCr de rango limitado y los malos gradientes; a menudo solo supone una mejora incremental respecto a JPEG optimizado.
  • AVIF:
    • En general se considera de mayor calidad y más eficiente que WebP, pero computacionalmente pesado; el beneficio real llega con la decodificación por hardware de AV1.
  • JPEG XL (JXL):
    • Gran entusiasmo: mejor conjunto de funciones, buena calidad, decodificación rápida y capacidad para recomprimir sin pérdida JPEGs existentes a ~15–20% menos tamaño.
    • Frustración por la retirada de soporte en Chrome; Safari y Firefox (tras banderas) ya lo soportan, lo que alimenta la sensación de que “Google está bloqueando el formato mejor”.

Flujos de trabajo de codificación y causas técnicas

  • Varios señalan que volver a codificar JPEGs ya con pérdida a WebP con pérdida (como hacen muchas herramientas y plugins) es inherentemente destructivo y agrava los artefactos.
  • El banding se vincula a:
    • Precisión de luma de 8 bits y cuantización agresiva.
    • Submuestreo de crominancia 4:2:0 y YCbCr de rango limitado en WebP.
  • WebP sin pérdida se considera, en general, visualmente idéntico a PNG y más pequeño, pero es fácil usarlo mal cuando los flujos de trabajo adoptan por defecto la variante con pérdida.

Herramientas, Google y la política de estándares

  • Google PageSpeed y herramientas similares empujan fuertemente a los sitios a “convertir a WebP”, lo que lleva a recompresiones masivas a ciegas y pérdida de calidad.
  • Algunos ven el trato de Chrome a JPEG XL (eliminado por “no ofrecer suficiente beneficio incremental”) como político/estratégico, especialmente dada la propia participación de Google en la investigación de JXL y el marketing histórico de WebP usando benchmarks favorables.
  • Otros argumentan que la retirada de Chrome se debió a la carga de mantenimiento y a una implementación incompleta, no a una conspiración.

Compatibilidad de formatos y molestias de UX

  • Quejas por el pobre soporte de WebP en sistemas operativos y aplicaciones (Windows antiguos, algunas configuraciones de Linux, herramientas ofimáticas, Slack, GitHub), pese al buen soporte en navegadores.
  • A los usuarios les molesta guardar WebP desde los navegadores cuando todo lo demás en su flujo de trabajo espera PNG/JPEG; a menudo recurren a capturas de pantalla o conversiones.

Presentación del artículo y del sitio

  • Muchos encuentran la página difícil de leer: columna de texto estrecha, fuente pequeña, ligaduras discrecionales/históricas agresivas (“st”, “ct”) calificadas de distractoras o de “troleo”.
  • Algunos recurren al modo lector, CSS personalizado o bloqueo de fuentes web para hacer el artículo legible.