JPEG XL: sus inicios y su situación actual

(cloudinary.com)

1 puntos por GN⁺ 2023-07-22 | 1 comentarios | Compartir por WhatsApp

JPEG XL es un formato de compresión de imágenes de próxima generación que comenzó a desarrollarse en 2018 combinando Google PIK y Cloudinary FUIF, y su bitstream quedó completamente congelado en 2020, con lo que el trabajo de estandarización quedó prácticamente concluido.
Antes de que Chrome decidiera eliminarlo en 2022, hubo una expansión fluida en la que navegadores principales como Firefox y Chrome añadieron soporte experimental.
Al anunciarse que toda la línea de productos de Apple, incluidos Safari 17, iOS y macOS, soportará JPEG XL, volvió a crecer el impulso para expandir el ecosistema.
Cloudinary comparó JPEG XL, AVIF, WebP y mozjpeg mediante experimentos basados en el dataset CID22 y SSIMULACRA 2, analizando diferencias desde la perspectiva de alta calidad, alta compresión y velocidad.
Se plantea que JPEG XL ofrece una ganancia adicional de compresión de 5 a 10% frente a AVIF y mantiene un nivel razonable de velocidad, por lo que hoy en promedio sería el mejor códec.

Los inicios de JPEG XL

El comité JPEG lanzó una convocatoria para el estándar de compresión de imágenes de próxima generación y se presentaron 7 propuestas; el diseño de JPEG XL comenzó al combinar la tecnología de Google PIK y Cloudinary FUIF.
- Al unir las ventajas de ambos formatos, se creó una nueva estructura de códec que ofrece compresión de mayor calidad y eficiencia frente al JPEG tradicional.
A finales de 2020 se congeló el bitstream y en marzo de 2022 fue aprobado oficialmente como estándar ISO (ISO/IEC 18181).
En 2021, Chrome y Firefox añadieron soporte experimental mediante flags, y parecía que todo avanzaba bien.
Cerca de Halloween de 2022, Chrome anunció sorpresivamente la eliminación del soporte, lo que provocó controversia.
- Desde Cloudinary señalaron varios problemas metodológicos en la forma en que Chrome realizó sus pruebas, pero no fueron tomados en cuenta.
Fuera del entorno de navegadores, la adopción de JPEG XL siguió creciendo, sobre todo en herramientas de autoría como Serif Affinity, Adobe Camera Raw, GIMP y Krita.

En la WWDC23, JPEG XL se incluyó oficialmente en la lista de novedades de Safari 17.
- Todo el ecosistema de Apple, incluidos iOS, iPadOS, macOS, watchOS y visionOS, añadió soporte para JXL.
Incluso los desarrolladores de JPEG XL no esperaban que Safari fuera el primer navegador con soporte oficial, y este anuncio reforzó el impulso del ecosistema.

Cloudinary construyó el gran dataset de imágenes CID22 (datos subjetivos en los que personas evaluaron directamente la calidad).
- La evaluación subjetiva es el criterio más preciso, pero como es difícil hacer experimentos a gran escala, con esa base se validaron métricas como SSIMULACRA 2.1 para usarlas en pruebas más amplias.
En compresión de imágenes es importante equilibrar tasa de compresión, calidad visual y velocidad de codificación.
- Bajo condiciones de calidad equivalente, se compararon JPEG XL, AVIF, WebP y mozjpeg con SSIMULACRA 2 como referencia.
Resultados principales
- WebP: en el rango de baja calidad reduce entre 25 y 35% frente a JPEG, pero en el rango de alta calidad la ganancia disminuye por la limitación de yuv420.
- Frente a mozjpeg, la ganancia adicional de WebP es de apenas 3 a 5%.
- AVIF: puede reducir entre 10 y 15% adicional frente a WebP y también soporta yuv444, por lo que mantiene una alta reducción incluso en el rango de alta calidad.
  - Sin embargo, la velocidad de codificación es muy lenta (varias veces más lenta, de un solo dígito, con su configuración predeterminada).
- JPEG XL: logra una reducción adicional de compresión de 5 a 10% frente a AVIF, especialmente con una diferencia mayor en el rango de alta calidad.
  - La velocidad de codificación también es más rápida que AVIF y ofrece un rendimiento utilizable en escenarios reales.

Como Cloudinary participó en el desarrollo de JPEG XL, fue de los primeros en ofrecer soporte para JXL.
- Se puede convertir añadiendo f_jxl a la URL o cambiando la extensión a .jxl.
Si se trata de un servicio con una alta proporción de usuarios de Safari, es válida la estrategia de servir primero JPEG XL y usar AVIF/WebP/JPEG como fallback para otros navegadores.
Como el códec óptimo depende de cada imagen, Cloudinary está desarrollando una nueva versión de f_auto,q_auto basada en IA.
- Planean ofrecer una función que seleccione automáticamente el formato más adecuado para cada imagen.

GN⁺ 2023-07-22

MKV, un "formato contenedor" estable para video y audio, perdura mientras que una nueva codificación de imágenes exige un nuevo formato contenedor y una nueva extensión de archivo.
Los decodificadores AV como libffmpeg soportan todos los formatos y códecs AV interesantes, lo que permite un soporte ampliamente extendido para nuevos códecs.
No existe una "súper biblioteca" para formatos de imagen + códecs como sí la hay con libffmpeg.
Chrome y Edge ahora soportan y muestran JXL en iOS 17.
JPEG 2000 en realidad no fue adoptado, y JPEG XL es solo una mejora incremental.
Algunas personas no están convencidas al usar webp, avif o jxl debido al soporte limitado y a la dificultad de trabajar con estos tipos de archivo.
La adopción de nuevos formatos de imagen podría recordar a los primeros días de JPEG.
Algunos usuarios tienen experiencias distintas con formatos de compresión de imagen como WEBP, AVIF y JPEG XL.
Está creciendo el interés en AVIF y JPEG XL para publicar imágenes con amplia gama de color.
El ecosistema de Apple adoptó HEIF, pero no el video AV1.
Algunos usuarios esperan que también se incluya el formato BPG además de JPEG XL.
JPEG XL es diferente de JPEG 2000 y JPEG XR.
El nombre "JPEG XL" podría influir en su éxito.
Hay una propuesta de usar JPEG XL como códec de imagen estática en un nuevo formato de video basado en AV1.