Chromium integra JpegXL

• Se integró un decodificador JpegXL en la base de código de Chromium, lo que permite que el navegador procese imágenes en formato JXL
• El cambio puede verse en la página de revisión de código de Gerrit con el título "Wire up JXL decoder"
• Esta fusión es un paso clave para el soporte del formato JpegXL, ya que incluye el trabajo de conectar el decodificador
• La revisión de código fue registrada como un cambio en el repositorio src de Chromium (7184969)
• Tiene relevancia por la ampliación del soporte de formatos de imagen de próxima generación en navegadores web

---

Integración del decodificador JpegXL en Chromium

• El elemento de revisión de código de Gerrit "Wire up JXL decoder (7184969)" es un cambio para conectar el decodificador JpegXL al proyecto Chromium
  • Este cambio se realizó dentro del repositorio src de Chromium
  • La plataforma de revisión de código utilizada es chromium-review.googlesource.com
• Tal como indica el título, se trata de conectar internamente el decodificador JXL (JpegXL) dentro del navegador
• La página no muestra explicaciones adicionales ni detalles del código; solo permite confirmar el título del cambio

Contexto técnico

• JpegXL es un formato de compresión de imágenes de próxima generación, orientado a mejorar la eficiencia frente a JPEG existente (no se menciona directamente en el texto original, solo aparece el nombre técnico)
• Con la fusión del decodificador en Chromium, queda preparada la base para habilitar a nivel de código el procesamiento de imágenes JXL
• Este cambio representa un avance técnico relacionado con la expansión del sistema de decodificación de medios del motor del navegador

Estado del documento

• La página aparece como una instantánea en caché de una revisión de código de Gerrit
• Incluye una advertencia de que el shadow DOM está oculto, pero no se muestra el contenido real del código
• Por lo tanto, la información verificable en este documento se limita al título del cambio y al identificador de revisión (7184969)

[GN⁺]

Comentarios de Hacker News

• Vi la entrada del blog de Cloudinary, y es un clásico algo antiguo que compara webp, jpegxl, avif, jpeg, etc.
  Los gráficos están muy bien organizados, y AVIF es muy lento.

  • Cuando JPEG se configuró con la calidad más baja, aquí se veía mucho mejor.
    Enlace a la sección relacionada
  • No tengo claro qué intenta hacer exactamente este sitio.
    Ver captura de pantalla
  • Si, como dice la cita, JPEG XL ya se consolidó como el mejor códec tanto con pérdida como sin pérdida, entonces sería un gran avance que podría reemplazar a JPEG y PNG con un solo formato.
  • Eso sí, esta prueba no usa codificadores/decodificadores con aceleración por hardware.

• La librería jxl-rs es una implementación de JPEG XL en Rust.
  Es un proyecto relativamente nuevo, pero gracias a Rust da cierta tranquilidad en cuanto a solidez de seguridad.
  En las discusiones anteriores de Chromium, esta librería no existía.

  • Según recuerdo, Google rechazó JPEG XL por “falta de interés”. No parece que haya sido por temas de seguridad.
  • No estoy de acuerdo con la idea de que “Rust reduce las preocupaciones de seguridad”. La seguridad de memoria no es la seguridad en sí misma.
    Rust puede generar exceso de confianza, y eso puede hacer que se omita el modelado de amenazas.
    Incluso un programador cuidadoso de C podría ser más seguro.
  • De hecho revisé cuánto código unsafe tiene.
    Enlace al resultado de búsqueda

• Comparé WebP y AVIF recientemente, y WebP codifica casi al instante, mientras que AVIF tarda más de 20 segundos en una imagen de 1 MP.
  JXL todavía tiene poco soporte, así que en la práctica no puedo usarlo, pero esperaría una velocidad tipo WebP con mejor calidad.

  • Dicen que rav1e lleva años sin actualizaciones, así que conviene más usar codificadores como aom o svt-av1.
  • En AVIF hay que ajustar los parámetros de uso de CPU. La configuración predeterminada usa un nivel de CPU demasiado alto, por eso es lento.
    En mi entorno, genera un AVIF de 2 MP en unos 100 ms.

• Es una lástima que la especificación pública (spec) de JPEG XL no sea de acceso libre.

  • Creo que mantener estándares cerrados es algo vergonzoso.
  • El problema es que muchísimos documentos de organismos como ISO e IEC están detrás de muros de pago (paywall).

• Llegó otro formato de imagen nuevo, y me preocupa que termine repitiéndose la situación en la que no se puede usar sin convertirlo.

  • Aun así, incluso Microsoft lanzó un complemento para JPEG XL, y ahora que Google retrocedió, creo que hay una oportunidad real.
    Enlace a Microsoft Store
  • En la práctica ya lo soportan muchas apps — Affinity, Photoshop, Microsoft Photos, Gimp, e incluso soporte a nivel de sistema en iOS 17+/macOS 12+.
    Chromium más bien va tarde.
  • Claro, un formato nuevo siempre necesita unos 10 años de adopción.

• Leí en Wikipedia la lista de funciones de JPEG XL, y tiene características interesantes como imágenes multicanal o documentos multipágina.
  Tiene cosas buenas, pero da la impresión de que cada vez se vuelve más complejo, como TIFF.

• Entre JPEG y JPEG-XL todavía hay muchas similitudes.
  Me pregunto si, si una implementación nueva integrara también soporte para JPEG tradicional, sería posible reducir el tamaño del código.

  • De hecho, ya hay un issue abierto para esa función en el repositorio Rust de JPEG-XL.
    Enlace al issue #513

• Personalmente, igual que con WEBP, prefiero seguir usando JPEG tradicional en vez de otro formato nuevo.
  La mayoría de los programas lo soportan, y para el usuario común JPEG + PNG es suficiente.
  Las animaciones simples pueden ir en GIF, y las complejas en video.

  • “JPEG XL”, pese al nombre, no es simplemente una extensión de JPEG.
    Permite codificación sin pérdida con menor tamaño que PNG, y también admite transcodificación reversible comprimiendo JPEG existente un 20% más.
    Tiene varias funciones como HDR, wide gamut y carga progresiva, así que también es ideal para entrega web.
    Ver jpegxl.info
  • WebP ya puede verse como un formato estándar de facto.
    Todos los navegadores principales lo soportan desde Safari 14, y viene incluido por defecto desde Windows 10 y macOS Big Sur.
    Ver estado de soporte y lista de software.
  • GIF ya es ineficiente. Reemplazarlo con video es entre 5 y 10 veces más eficiente.
    Artículo relacionado

• Llevo tiempo escuchando el debate entre JPEG XL, WebP y AVIF, pero no sabía mucho del tema.
  Viendo los benchmarks, JpegXL supera a WebP tanto en velocidad de compresión como en tamaño, así que me pregunto por qué Chromium dudó tanto en adoptarlo.

  • WebP y AVIF comparten código con VP8/AV1, así que integrarlos en el navegador es más fácil, mientras que JPEG-XL requiere una base de código aparte y eso aumenta la carga de implementación.
    Además, libjxl tiene más de 100 mil líneas de C++, así que había riesgo de vulnerabilidades de seguridad.
    Parece que ahora Chrome lo está reconsiderando a medida que madura la implementación en Rust.
  • JPEG XL soporta decodificación progresiva.
    Video demo
  • Google había argumentado que “tener varios formatos similares solo aumenta el riesgo de seguridad”, y que con AVIF era suficiente.
  • AVIF funciona bien con bpp bajo (baja calidad), pero flojea en sin pérdida, mientras que JXL es fuerte en alta calidad y sin pérdida.
  • En el pasado, la librería C++ de JPEGXL estaba sin mantenimiento, pero con la aparición de la versión en Rust, la adopción en navegadores se volvió posible.

• Tenía curiosidad por saber si JPEG XL soporta animación.

  • Sí la soporta, pero como no tiene compresión entre cuadros, es ineficiente y termina pesando más que un video normal.
  • Según la página de estado de la plataforma de Chrome, soporta animación, HDR y decodificación progresiva.
    Enlace con detalles
  • De hecho lo probé en el navegador Canary y la animación funcionó bien.
  • Alguien lo resumió en broma diciendo que WebP es básicamente una “imagen que en realidad es un formato de video”, mientras que JPEG XL es un “video que en realidad es un formato de imagen”, así que se da una simetría paradójica 😄