JPEG XL y la frontera de Pareto

Artículo original ↗ Discusión en Hacker News ↗

JPEG XL se presenta como un códec de imagen de nueva generación altamente eficiente que supera a JPEG, WebP, AVIF y PNG tanto en relación de compresión como en velocidad, con funciones como recomprensión sin pérdida de JPEG, decodificación progresiva, compatibilidad HDR y un sólido rendimiento sin pérdida. Los comentaristas elogian las mejoras recientes del codificador y del uso de memoria, pero señalan que el impacto en el mundo real está limitado por una compatibilidad inconsistente entre navegadores, las preocupaciones por patentes y el dominio de Chromium en la fijación de estándares web de facto. Existe un amplio acuerdo en que JPEG XL es técnicamente impresionante y atractivo para fotografía, archivos y flujos de trabajo profesionales, pero su futuro en la web dependerá de las decisiones de adopción de los principales proveedores más que del mérito técnico por sí solo.

Compatibilidad de navegadores y “control de acceso”

  • Muchos comentarios se centran en que Chrome eliminó JPEG XL detrás de un flag y se negó a incluirlo, a pesar de las peticiones de la comunidad.
  • Algunos sostienen que las ramas derivadas de Chrome (Edge, Brave, Opera) podrían diferenciarse habilitando JXL, pero en general no lo hacen, lo que sugiere que divergir de Chromium de verdad es caro.
  • Safari ya incluye JPEG XL; Firefox se describe como “neutral” y con recursos limitados, con el trabajo estancado en nightly.
  • Hay preocupación de que el dominio de Chromium lo convierta en un control de acceso de facto; otros responden que la cuota de mercado no obliga a implementar todos los formatos.

Patentes, riesgo legal y seguridad

  • Se debate si una patente de Microsoft relacionada con ANS asustó a los proveedores de navegadores; otros responden que no se aplica a JXL y que eso es especulativo.
  • El hecho de que Apple y Adobe incluyan JXL se cita como evidencia de que el riesgo de patentes es manejable.
  • Se aclara que Cloudinary y Google ofrecen licencias libres de regalías para sus patentes relacionadas con JXL; el riesgo restante es el genérico de cualquier formato reciente.
  • Preocupación aparte: libjxl está en C++, y ya ha tenido errores de seguridad de memoria; algunos sostienen que los códecs nuevos y complejos que acabarán siendo ubicuos deberían escribirse en lenguajes seguros.
    Existe un decodificador en Rust y ha sido validado.

Calidad de compresión y velocidad

  • Sin pérdida: JXL y WebP sin pérdida son fuertes; AVIF sin pérdida es muy criticado y a menudo peor que PNG. Se elogia WebP sin pérdida, pero está limitado a 8 bits y a dimensiones más pequeñas.
  • Con pérdida: a las calidades típicas de la web, JXL suele superar a JPEG y WebP; AVIF puede ser mejor a bajas tasas de bits. Algunos consideran que JPEG de baja calidad conserva más detalle, pero señalan que usa más bits.
  • Las mejoras del codificador JXL en la v0.10 redujeron de forma importante el uso de memoria y aumentaron la velocidad, especialmente para la compresión sin pérdida multihilo.
  • Hay debate sobre cómo trazar la frontera de Pareto y si algunos puntos fueron clasificados incorrectamente.

Rendimiento de decodificación y UX

  • Muchos consideran que la velocidad de codificación es económicamente crítica para los servicios (codificación masiva); la velocidad de decodificación es “suficientemente buena” en dispositivos modernos.
  • La decodificación progresiva/por streaming se ve como más importante para la UX que el rendimiento bruto de decodificación; JXL admite una decodificación progresiva sólida, a diferencia de AVIF.

Funciones y ecosistema

  • Un punto de venta importante: JXL puede recomprimir JPEG existentes sin pérdida y reconstruir JPEG idénticos a nivel de bits, lo que permite ahorrar almacenamiento sin pérdida de calidad.
  • El codificador compatible con JPEG “jpegli” ofrece mejoras impresionantes sin dejar el terreno de JPEG, reforzando que “el viejo JPEG todavía tiene vida”.
  • Herramientas: se desea una mejor integración de JXL (por ejemplo, versiones de libvips, ImageMagick), y se menciona la biblioteca SIMD Highway, surgida del trabajo en JXL.
  • Persisten algunas dudas de que, pese a sus méritos técnicos, la adopción de JXL sea lenta y su uso real siga siendo limitado frente al entusiasmo.