Revocando una controvertida decisión de 2022 que paralizó la adopción de imágenes de próxima generación, Google ha confirmado oficialmente que restaurará la compatibilidad con JPEG XL (JXL) en su navegador Chrome.
JPEG XL (JXL) es un formato de imagen de próxima generación libre de derechos diseñado para reemplazar el estándar JPEG heredado al ofrecer una compresión superior y capacidades modernas como HDR, transparencia, y animación. Su ventaja definitoria es la capacidad de transcodificar archivos JPEG existentes sin pérdidas en archivos más pequeños (reduciendo el tamaño aproximadamente un 20 %) sin pérdida de calidad.
La medida de Google sigue a años de reacción de los desarrolladores y presión creciente de actores del ecosistema rivales como Apple y Adobe, que adoptaron el formato de archivo de gráficos rasterizados libre de regalías a pesar de las afirmaciones anteriores de Google de”falta de interés”.
Los ingenieros de Chrome ahora dicen que lanzarán la función una vez que se integre un decodificador seguro para la memoria, lo que indica un giro importante en las “guerras de códecs” de la web y despeja el camino para que JXL reemplace el antiguo estándar JPEG.
Un camino hacia la redención basado en Rust
Rompiendo un estancamiento de tres años, Rick Byers, líder del equipo de auditoría de Chrome, puso fin oficialmente a la congelación de la integración de JPEG XL en el hilo de la lista de correo de Blink-dev. La aprobación depende de dos condiciones específicas: la presencia de”señales positivas”del ecosistema más amplio y un estricto cumplimiento de la seguridad.
Google está rechazando explícitamente la implementación anterior de C++ a favor de un decodificador”de alto rendimiento y seguro para la memoria”, probablemente escrito en Rust. Byers señaló que”dadas estas señales positivas, agradeceríamos contribuciones para integrar un decodificador JPEG XL de alto rendimiento y con memoria segura en Chromium”, enmarcando la lógica en torno a la adopción externa en lugar de métricas internas.
El mantenimiento a largo plazo sigue siendo el último obstáculo antes de que la función llegue a los usuarios. Google requiere un equipo dedicado que sea propietario del código decodificador antes de enviarlo al canal estable.
Byers aclaró el cronograma y afirmó:”Para habilitarlo de forma predeterminada en Chromium necesitaríamos un compromiso de mantenimiento a largo plazo. Una vez cumplidos esos criterios y nuestros criterios de lanzamiento habituales, lo enviaríamos en Chrome”.
El desarrollador Helmut Januschka proporcionó una actualización de estado granular en el rastreador de errores de Chromium, confirmando que el nuevo código se basa en la última versión. implementación de referencia de libjxl. La actualización del desarrollador indica:
“Estado actual: – Función completa – se usó la implementación JXL anterior como modelo y se actualizó a la implementación de referencia más reciente – Se agregó soporte de animación (Chromium sería el primer navegador que admitiría animaciones JXL) – los bots son verdes”
Januschka también publicó la siguiente demostración que muestra el soporte de animación JPEG XL en una compilación de Chromium.
[contenido incrustado]
Marcado como “característica completo”, la nueva implementación supuestamente pasa la mayoría de las pruebas de bot automatizadas. El soporte de animación es un diferenciador técnico crítico en este segundo intento, superando potencialmente la implementación inicial de Safari.
Januschka señaló que “Chromium sería el primer navegador que soportaría animaciones JXL”, aunque esta afirmación es impugnada por proyectos más pequeños como el navegador Thorium, que ha soportado animaciones JXL desde mediados de 2024.
El contexto de la “guerra de códecs” (2022-2025)
Google eliminó originalmente la compatibilidad con JXL en Chrome 110 en diciembre de 2022, lo que acabó con el impulso web del formato. En ese momento, Jim Bankoski declaró que”hemos decidido detener el experimento JPEG XL de Chrome y eliminar el código asociado con el experimento”, citando beneficios insuficientes sobre el propio AVIF de Google. formato.
Los críticos y expertos en compresión de imágenes acusaron a Google de utilizar métricas defectuosas al probar codificadores no optimizados para favorecer AVIF. Lo que provocó uno de los hilos más polémicos en la historia de Chromium, la eliminación atrajo más de 1000 estrellas y cientos de comentarios de desarrolladores.
Durante la pausa, Google impulsó agresivamente AVIF, derivado del códec de vídeo AV1, como el único sucesor de JPEG y WebP. Los ingenieros eliminaron por completo la”marca de función”del navegador, impidiendo incluso el uso experimental durante casi tres años.
Consolidando una narrativa de”guerra de formatos”, este período enfrentó el AVIF basado en video de Google con el diseño de imagen primero de JPEG XL.
Presión del ecosistema y realidad técnica
Apple rompió el punto muerto en 2023 al agregar soporte nativo JXL a Safari 17. Al crear un escenario de”web dividida”, esta adopción significó imágenes de alta fidelidad cargadas en iPhones pero fallaron en Android y Chrome.
Adobe integró JXL en Lightroom y Photoshop, mientras que Microsoft agregó la Extensión de imagen JPEG XL a Windows 11, validándola como un estándar profesional. independientemente de la compatibilidad del navegador.
La posición de Mozilla cambió de”neutral”a”positiva”, siempre que los problemas de seguridad se abordaran mediante un decodificador basado en Rust. Técnicamente, JXL ofrece una ventaja única: transcodificación sin pérdidas de archivos JPEG existentes para reducir el tamaño en aproximadamente un 20 % sin pérdida de generación.
AVIF carece de esta capacidad de transcodificación, lo que requiere una recodificación con pérdidas que degrada la calidad del contenido de archivo. Alineándose con la tendencia más amplia de la industria de eliminar las vulnerabilidades de seguridad de la memoria al analizar archivos multimedia complejos, el cambio a un decodificador basado en Rust garantiza la estabilidad a largo plazo.
