Entrega de JPEG XL en Chrome

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

La decisión de Google de (re)habilitar JPEG XL en Chrome se ve como un punto de inflexión importante para el formato de imagen, que promete mejor compresión, soporte de alta profundidad de bits y HDR, carga progresiva e incluso transcodificación sin pérdida desde JPEG heredados. Los comentaristas debaten cómo se compara JPEG XL con AVIF y WebP, sopesando la eficiencia de compresión, el rendimiento sin pérdida, la velocidad de decodificación y las herramientas del mundo real, al tiempo que destacan preocupaciones de seguridad pasadas y la política detrás de que Google primero retirara y ahora restablezca el soporte. Muchos esperan que, con el respaldo de navegadores importantes, proveedores de SO e incluso el ecosistema PDF, JPEG XL pueda convertirse en un sucesor de largo plazo y de propósito general de la mezcla fragmentada actual de JPEG, PNG, WebP, AVIF y HEIC.

Historia y motivación de JPEG XL en Chrome

  • Se añadió compatibilidad con JPEG XL a Chrome, se eliminó alrededor de 2023 y ahora se está volviendo a añadir.
  • La eliminación anterior se atribuyó oficialmente a la baja demanda y a la redundancia con AVIF/WebP; algunos comentaristas creen que el coste de seguridad, la política interna o la política del consorcio (AVIF/AOM) también influyeron.
  • El cambio de rumbo se atribuye de diversas maneras a: un decodificador Rust más seguro (jxl‑rs), una tracción más amplia en el ecosistema, compatibilidad de Apple/Safari (incluido iPhone ProRAW JXL) y actualizaciones de la especificación PDF que adoptan JXL, lo que en la práctica obliga a dar soporte en el navegador para la renderización de PDF.

Propiedades técnicas y comparaciones (AVIF, WebP, PNG, JPEG)

  • Muchos ven JPEG XL como un “sucesor de propósito general” de JPEG/PNG/WebP/AVIF:
    • Con pérdida y sin pérdida, alta profundidad de bits (HDR), amplia gama cromática, canales extra, capas, páginas, animación y mapas de profundidad.
    • Recomposición sin pérdida de JPEGs existentes con menor tamaño y sin pérdida generacional.
  • Varios informan que JPEG XL supera a AVIF/WebP/PNG en fotos de alta calidad y uso sin pérdida, incluidos grandes conjuntos de archivos y conjuntos de datos de visión por máquina.
  • Otros sostienen que AVIF es más eficiente para bitrates muy bajos e “imágenes heroicas” de la web, y que los codificadores AVIF modernos han reducido gran parte de la ventaja percibida de JXL.
  • Un “caso contra JXL” detallado argumenta:
    • AVIF es mejor para el uso con pérdida típico en la web.
    • Las mejoras sin pérdida de JXL sobre WebP (~10–13%) no justifican un mayor coste de decodificación.
    • Las ganancias por transcodificación de JPEG pueden verse compensadas por una decodificación más lenta en los clientes.
  • Contraargumentos: muchos benchmarks y pruebas prácticas en el hilo muestran que JXL gana en calidad/tamaño para fotos y en uso sin pérdida, y que jxl‑rs ahora compite o es más rápido que libjxl C++.

Seguridad e implementación

  • La libjxl original en C/C++ tuvo varias vulnerabilidades y se consideró una superficie de ataque demasiado grande.
  • Chrome y Firefox están adoptando un decodificador Rust para cumplir las directrices internas de seguridad de “regla de dos” (seguridad de memoria frente a aislamiento frente a entrada de confianza).
  • Algunos debaten si Rust por sí solo es suficiente sin aislamiento.

Ecosistema, UX y compatibilidad

  • Navegadores: Safari incluye JXL (sin algunas funciones avanzadas como la animación progresiva); Chrome estable ahora; Firefox lo habilitará por defecto en una próxima versión. Se espera que Android WebView siga a Chrome.
  • SO/aplicaciones: los visores del sistema de macOS/iOS, algunas herramientas de edición y pilas PDF admiten JXL; la calidad de las herramientas es desigual (algunos codificadores se consideran deficientes).
  • Muchos se quejan del dolor de compatibilidad pasado con WebP/HEIC (LMS, Telegram, Instagram, aplicaciones de escritorio) y temen otra ronda de fragmentación; otros señalan que la adopción de JXL fuera de los navegadores ya es más rápida de lo que fue la de WebP.
  • La renderización progresiva es elogiada por eliminar la necesidad de muchas miniaturas, pero algunos se preocupan por la UX (no está claro cuándo la carga está “terminada”) y por un posible mal uso si las miniaturas divergen de las imágenes finales.

Adopción y preocupaciones de despliegue

  • Los desarrolladores web vigilan los porcentajes de caniuse; varios no usarán JXL hasta ~80–90% de soporte o, al menos, hasta el siguiente Firefox ESR.
  • El coste de codificación es una preocupación importante para canalizaciones dinámicas o bajo demanda; experimentos previos con AVIF provocaron grandes aumentos de CPU y coste.
  • Los patrones recomendados incluyen servir JXL mediante <picture> con alternativas JPEG/PNG/WebP/AVIF, y esperar unos cuantos ciclos de versiones del navegador antes de un uso amplio en producción.

Filosofía más amplia

  • Algunos quieren un único formato de imagen moderno de “usa esto y ya”; otros prefieren un conjunto pequeño y especializado (por ejemplo, AVIF para pérdida en la web, PNG/WebP para sin pérdida).
  • Los escépticos sostienen que JPEG/PNG siguen siendo “suficientemente buenos” y universalmente compatibles; los partidarios enfatizan el ahorro de datos móviles, el almacenamiento, la mejor calidad, las necesidades de HDR/profundidad de bits y el valor de archivo a largo plazo.