¿Google reactivó el soporte de JPEG XL?

 (tonisagrista.com)
5 puntos por GN⁺ 2025-12-03 | 2 comentarios | Compartir por WhatsApp
  • Con el restablecimiento del soporte de JPEG XL en el motor de Chromium, un formato de imagen que en su momento se había dejado de lado vuelve a llamar la atención
  • En 2022, Google eliminó JPEG XL con el argumento de la “falta de interés del ecosistema”, pero continuó la presión sostenida de la comunidad y de grandes empresas
  • Varias organizaciones, entre ellas Meta, Intel, Adobe, Cloudinary y Krita, apoyaron públicamente la necesidad de mantener el formato
  • Recientemente, la decisión de PDF Association de adoptar JPEG XL como formato base para contenido HDR fortaleció la tendencia
  • La decisión de reincorporación de Chrome se ve como un punto de inflexión que aumenta las posibilidades de estandarización masiva de JPEG XL

Antecedentes del resurgimiento de JPEG XL

  • En 2022, el equipo de Chromium eliminó el código y las banderas de JPEG XL por la supuesta "falta de interés suficiente del ecosistema" y la "falta de ventajas en comparación con formatos existentes"
    • En ese momento, la comunidad manifestó apoyo de forma pública de parte de actores clave como Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips y Krita
    • Luego siguieron reacciones en blogs, videos y redes sociales señalando la impropiedad de la decisión de eliminación
  • A fines de 2025, el equipo de Chromium cambió el estado del issue de JPEG XL de Obsolete a Assigned, iniciando oficialmente el proceso de restauración
    • En el grupo de desarrolladores de Blink, Rick Byers comentó que "da la bienvenida a un decodificador de JPEG XL seguro en memoria y de buen rendimiento"
    • Esta decisión se basó en señales positivas como el apoyo de Safari, el cambio de postura de Firefox y el movimiento de adopción de PDF Association

Desarrollo de decodificador basado en Rust en Firefox

  • El equipo de Firefox planteó la necesidad de una versión en Rust al preocuparse por el riesgo de seguridad del decodificador libjxl, basado en C++, que calificó como crítico
    • Por ello, Google Research comenzó a desarrollar la implementación jxl-rs en Rust
    • Este proyecto fue un paso para mejorar la viabilidad de una integración segura de JPEG XL dentro del navegador

Movimiento de adopción de PDF Association

  • El CTO de PDF Association, Peter Wyatt, anunció su intención de incluir JPEG XL como formato predeterminado para imágenes HDR en la especificación de PDF
    • Esto funciona como un factor que refuerza la posibilidad de estandarización de JPEG XL en el área de documentos y edición

Principales características técnicas de JPEG XL

  • Soporte de recompresión sin pérdidas de JPEG existente, lo que permite reducir el tamaño alrededor de un 30% sin pérdida de calidad
  • Soporte de gamut ampliado y HDR, manejo de hasta 32 bits de canal y 4,099 canales
  • Soporta un tamaño de imagen máximo de 1,073,741,823×1,073,741,824, lo que permite trabajar con imágenes de gran escala
  • Soporta decodificación progresiva (progressive decoding) para mejorar la eficiencia de transferencia en la web
  • Incluye animación, transparencia alpha y mapas de profundidad (depth map)
  • Su estructura es robusta frente a pérdidas generacionales, minimizando la degradación de calidad tras recodificaciones repetidas

Conclusión

  • JPEG XL cumple con los requisitos de formato de imagen de nueva generación, y el regreso del motor de Chrome es un hito clave para su adopción masiva
  • Gracias a la presión sostenida de la comunidad, esta restauración lo convierte en un nuevo candidato a estándar del ecosistema de imágenes web
  • El autor recibe con beneplácito la reevaluación de Chromium, aunque advierte que esta decisión se tomó demasiado tarde

Lecturas relacionadas

2 comentarios

 
GN⁺ 2025-12-03
Comentarios de Hacker News

  • Una de las funciones geniales menos conocidas de JPEG XL es un modo que transcodifica sin pérdida desde JPEG y ahorra alrededor de un 20% de espacio de almacenamiento
    Como conserva intacto el bitstream de entropía original, es completamente reversible
    GCP lo está aplicando a la DICOM Store API, así que puede aprovechar el ahorro de espacio de JXL y al mismo tiempo entregar conversión en tiempo real a JPEG
    Nuestra empresa almacena decenas de PB de datos en GCP DICOM Store, así que esperamos que esta función reduzca significativamente la factura anual
    También tenemos la esperanza de contar con soporte nativo en el navegador, y escuché que el equipo de Chrome eventualmente terminará dándole soporte

    • Me da curiosidad qué diferencia hay frente a un codificador JPEG promedio o mozjpeg
    • Nunca tuve tiempo de probar GCP DICOM Store antes, así que me pregunto cómo es en la práctica
      Quisiera saber si es un PACS completo, una implementación de WADO o simplemente una API personalizada
    • Si es reversible, entonces ¿no bastaría con guardar en JPEG XL y volver a convertir al servirlo?
      Me pregunto si el procesamiento tarda mucho
    • Si de todos modos hay que almacenar el DICOM original, dudo que la transcodificación tenga mucho sentido
      Parece que la mayor parte del costo de almacenamiento vendría del propio DICOM
    • Al final, como los grandes clientes de GCP salen muy beneficiados con esta función, da la impresión de que la razón para impulsar JXL en Chrome viene de clientes internos

  • El competidor de JPEG XL no es AVIF
    AVIF ya se estableció como un estándar de facto, casi todos los navegadores lo soportan y también se usa como formato de imagen predeterminado de Apple
    JXL todavía tiene poco soporte en navegadores, pero se está abriendo espacio en nichos como archivado, fotografía profesional y uso médico
    En unos 10 años podría volverse tan común que la gente simplemente lo llame “JPEG”
    AVIF es un estándar abierto y libre de regalías, tiene una compresión mucho mejor que JPEG/WebP y está en un nivel similar a JXL
    El tamaño máximo de imagen de JXL es mayor, pero en adopción real AVIF va muy por delante
    Cuando llegue AV2, la brecha de calidad casi desaparecerá, y creo que ambos formatos seguirán evolucionando mientras mantienen un nivel de calidad similar

    • Que AVIF sea mejor que JPEG o WebP en compresión es obvio, pero con JXL no compite
      En ajustes de calidad realistas, JXL muestra mayor compresión y velocidades de codificación y decodificación más rápidas
      Además, soporta progressive decoding
      Puede que AV2 lo alcance cuando salga, pero por ahora creo que JXL va muy por delante
    • Una de las razones por las que el equipo de Chrome dejó de dar soporte a JXL fue que AVIF ya era suficientemente bueno
      Parece que esta reevaluación está conectada con aquella decisión
    • Creo que eso de que “el formato de imagen predeterminado de Apple es AVIF” es incorrecto
      El iPhone usa HEIF
    • Probé libjxl directamente y consumía mucha memoria y era inestable
      Codificar imágenes de alta resolución requería tanta RAM que llegaba al nivel de terabytes
      Me sorprendió lo desordenado del codebase, y muchas opciones no funcionaban bien
      Es positivo volver a intentarlo con jxl-rs, pero como participan los mismos desarrolladores, lo miro con cautela

  • Es muy probable que Chromium use el crate jxl-rs para la funcionalidad de JPEG XL
    Parece que están esperando a que madure lo suficiente antes de integrarlo
    El issue relacionado se puede ver aquí

    • Mozilla tenía una postura parecida, pero Google mostró durante un tiempo una actitud hostil
      Cerró el issue pese a la oposición de los usuarios, y recién hace poco lo volvió a abrir
      Quizá se deba a un problema de PR o a malestar interno
    • Hubo un periodo de más de un año y medio sin commits en jxl-rs
      Que ahora esté avanzando bien puede ser simplemente un golpe de suerte

  • Revisé la implementación de referencia (C++) de JPEG XL, y hasta hace 2 años la calidad del código no era buena
    Daba la impresión de que podían aparecer problemas de seguridad

    • Por eso tanto Mozilla como Google están evaluando el soporte de JXL con la condición de que exista una implementación memory-safe
      Se está desarrollando una versión en Rust, y Google tiene el plan de ir reemplazando gradualmente todos los decodificadores de Chromium por versiones en Rust
    • En realidad, a estas alturas (2025), cualquier código grande de procesamiento de imágenes escrito en C++ es en sí mismo un riesgo de seguridad
      No es un problema exclusivo de JPEG XL

  • La resolución máxima de JPEG XL es 1,073,741,823 × 1,073,741,824, así que puede representar imágenes de ultra alta resolución de cientos de petabytes
    En la práctica, incluso después de comprimir seguirían siendo decenas o cientos de PB

    • A 600DPI, un lado equivaldría a la distancia de una maratón
      Si se puede definir una imagen tan enorme en un espacio pequeño de bytes, parece que también podría convertirse en un vector de ataque DOS
      Intenté convertirlo a hojas A4, pero la calculadora de Gemini confundió las unidades y dio un resultado absurdo
    • La única forma práctica de manejar imágenes tan gigantes es con tiling y estructura piramidal
    • Parece del tamaño de una imagen de toda la Tierra tomada con una resolución de unos 4 cm
    • Si te tomaras una selfie con esa resolución, sería nivel microscopio de superresolución
    • A diferencia de AVIF, JPEG XL sí soporta progressive decoding eficiente, así que puedes ver una vista previa de baja calidad rápidamente mientras todavía se descarga

  • Recopilación de discusiones pasadas en HN
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • Llevo varios años usando .avif
    No es perfecto, pero siento que es mucho mejor que .jpg o .png
    También consideré .webp y jpeg-xl, pero al final quedé satisfecho con .avif
    Aun así, me molesta que Google prácticamente dicte los estándares web
    No es deseable que una empresa comercial controle el ecosistema digital

    • La frase “.avif es mejor que .jpg” confunde porque repite .avif dos veces
    • Si quieres hacer JPEG de alta calidad más pequeños, te recomiendo probar jpegli
      jpegli GitHub
      Si eliges muy bien los ajustes de pérdida visual de AVIF, puede quedar más pequeño que jpegli, pero en promedio jpegli es más eficiente
    • Como referencia, en inglés “for several years” suena más natural que “since some years”
    • JPEG XL pierde menos calidad al volver a guardarlo varias veces, así que es ventajoso para la web
      Video relacionado: enlace de YouTube

  • Quien eliminó JXL no fue “Google en su conjunto”, sino el equipo de Chrome
    JXL fue diseñado por Jyrki Alakuijala del laboratorio Google Zurich, y él pertenece a Google Research, no al equipo de Chrome
    El equipo de Chrome tiene una cultura cerrada centrada en Mountain View

    • Jyrki es un ingeniero sobresaliente que también creó Brotli, WebP lossless, WOFF2 y jpegli
      El hecho de que hiciera jpegli después de que JpegXL fuera descartado también fue una especie de reacción
    • Parece una situación que se puede explicar con Conway’s Law

  • Parece que JXL se retrasó por la gran cantidad de dependencias multihilo basadas en C++, lo que podría ampliar la superficie de ataque de seguridad
    Tanto Mozilla como Google prefieren una implementación en Rust para evitar eso
    El estándar en sí definitivamente es un formato mejorado respecto a los anteriores

    • Eso de 100 millones de líneas suena demasiado exagerado
    • En realidad son unas 30 mil líneas, y la versión de un solo hilo ronda las 10 mil
      El binario también es mucho más pequeño que el de AVIF, y la especificación es bastante más concisa
    • Como Google participó en el desarrollo de JXL, es su propia responsabilidad no haber hecho antes un decodificador memory-safe
    • ¿No habrás querido decir unas 100 mil líneas? Probablemente una buena parte sea código de pruebas
    • El libjxl real tiene unas 112 mil líneas, lo que deja la afirmación de 100 millones tres órdenes de magnitud por fuera

  • Se dice que los archivos RAW del iPhone 17 Pro se comprimen con JPEG XL