El formato JPEG XL enfrenta serios obstáculos para consolidarse en la web abierta tras su exclusión de Chromium y las persistentes críticas sobre su rendimiento frente a AVIF, a pesar de mantener ventajas en compresión sin pérdida y de contar con implementaciones recientes en navegadores como Firefox y Chrome.
El rechazo inicial en Chromium y el dominio del ecosistema
En el cambio de 2022 a 2023, Google eliminó el soporte experimental de JPEG XL de Chromium argumentando falta de interés en todo el ecosistema, falta de beneficios incrementales suficientes sobre los formatos existentes, y reducción de la carga de mantenimiento
, según recogió HotHardware. Dado que Chromium concentra entre el 70% y el 80% del mercado global de navegadores según PCWorld, cualquier formato que no entra a Chromium difícilmente escala a la web abierta.
La decisión enfureció a parte de la comunidad: JPEG XL es royalty-free, viene del comité JPEG —la referencia institucional del formato original— y contaba con el respaldo de Cloudinary, donde trabaja el Dr. Jon Sneyers como senior image researcher y co-chair del JPEG XL adhoc group, según un artículo de Computer Weekly firmado por el propio Sneyers.
Ventajas técnicas y debates sobre el rendimiento frente a AVIF
La propuesta original de JXL era un códec diseñado específicamente para imágenes, en contraste con WebP (basado en VP8), HEIF (HEVC) y AVIF (AV1), que vienen del mundo del video. Esa es la tesis que Cloudinary defiende: JXL ofrece progressive decoding real, donde se ve una versión útil de la imagen mientras se carga el resto. El codec mejora en los formatos anteriores de JPEG y permite que los archivos JPEG existentes se codifiquen de forma sin pérdida como archivos JPEG XL y se restauren al archivo JPEG inicial, garantizando la retrocompatibilidad. El archivo JPEG XL utiliza los datos de imagen junto con cualquier otro metadato presente, como Exif, XMP o JUMBF, para reconstruir el archivo JPEG original. La función de capacidad de respuesta del códec JPEG XL permite admitir imágenes de decodificación progresiva que otros formatos basados en códecs de video, como WebP, HEIC y AVIF, no admiten.
Sin embargo, Gianni Rosato, ingeniero de compresión con experiencia en AV1 y AVIF, sostiene en su blog que en la práctica AVIF ya implementa progressive decoding y muestra una imagen utilizable mucho mejor que JXL, a apenas el 2-3% del tamaño total del archivo, al apoyarse en el decodificador nativo del navegador en lugar del polyfill habitual. En el frente de la compresión con pérdida, los benchmarks que cita Rosato muestran que el encoder de referencia de JXL queda detrás de alternativas como Aperture, el encoder en desarrollo de Halide Compression, y que libaom AVIF en modo perceptual queda solo un par de puntos por debajo de su propio modo optimizado para métrica perceptual. La única ventaja que sobrevive, según Rosato, es la lossless: JXL logra alrededor de un 11,9% menos bytes que WebP lossless en su banco de pruebas —fotos de 157 MP, ilustraciones de 10 MP y libros de 27 MP, un dataset que no es representativo del tráfico web promedio.
Carencias funcionales y riesgos de seguridad reportados
Rosato enumera cuatro carencias técnicas del formato: sin predicción direccional en comparación con códecs block-based como WebP; sin deblocking loop filter (DLF), ya que las dos herramientas in-loop de JXL —gaborish y EPF— no son equivalentes al DLF de AV1 y JXL sigue sufriendo de mosquito noise; colorspace XYB con problemas, donde el canal B se cuantiza agresivamente, lo que degrada la preservación de color y obliga a los nuevos desarrolladores de encoders a deshacer ese efecto a mano; y pocas opciones para imágenes no fotográficas, dado que el mecanismo de patches es más costoso que Intra Block Copy de AV1 y está deshabilitado por debajo de effort 7 por temas de rendimiento.
En el plano del rendimiento y la seguridad, el argumento más sensible para founders es el de rendimiento. Rosato probó su set de imágenes con decodificadores reales: WebP terminó más de 90 KB más grande y aun así decodifica más de 10 veces más rápido que jxl-rs con wpd, mientras que la recompresión lossless de JPEG a JXL recupera alrededor del 20% de bytes, pero paga cerca del 33% más de tiempo de procesamiento.
Perspectivas operativas para desarrolladores e integradores
Más recientemente, un decodificador de JPEG XL escrito en Rust empezó a integrarse en Firefox y Chrome, en parte porque mitiga la vulnerabilidad de WebP de 2023, aunque Gianni Rosato sostiene en su blog que eso no alcanza para justificar un nuevo intento.
Lectura relacionada