JPEG XL es un formato para imágenes de tipo raster. Ofrece un modo de compresión con pérdida así como un modo de compresión sin pérdida. Está diseñado para ofrecer mejor compresión que formatos raster previos y servir como un reemplazo universal.[1]

JPEG XL
Desarrollador
Joint Photographic Experts Group, Google y Cloudinary
https://jpeg.org/jpegxl
Información general
Extensión de archivo .jxl (contenedores)
Tipo de MIME image/jxl
Número mágico FF 0A o 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A
Lanzamiento inicial 24 de diciembre de 2020, 13 de octubre de 2021 y 30 de marzo de 2022
Extendido de PIK, Free Universal Image Format y JPEG
Estándar(es) ISO/IEC 18181
Formato abierto Sí 

Nombre

editar

JPEG son las siglas de Joint Photographic Experts Group, que es el comité encargado de diseñar el formato.

La letra X ha sido usada en el nombre de varios estándares de JPEG desde el año 2000.

L significa Largo plazo, pues la intención de los autores del formato es reemplazar los formatos previos y servir como reemplazo durante un largo periodo de tiempo.[2]

Los principales autores de la especificación son Jyrki Alakuijala, Jon Sneyers y Luca Versari. Otros colaboradores son Sami Boukortt, Alex Deymo, Moritz Firsching, Thomas Fischbacher, Eugene Kliuchnikov, Robert Obryk, Alexander Rhatushnyak, Zoltan Szabadka, Lode Vandevenne y Jan Wassenberg.

Historia

editar

En agosto de 2017, JTC1/SC29/WG1 (JPEG) publicó una convocatoria de propuestas para JPEG XL, el estándar de codificación de imágenes de próxima generación.[3]​ Las propuestas se enviaron en septiembre de 2018, lo que llevó a un borrador del comité en julio de 2019.[4]​ Se basó principalmente en una combinación de una propuesta llamada PIK,[5]​ presentada por Google, y una propuesta llamada FUIF[6]​, basado en FLIF, presentado por Cloudinary.

El flujo de bits se congeló informalmente el 24 de diciembre de 2020 con el lanzamiento de la versión 0.2 del software de referencia libjxl.[7]​ El formato de archivo y el sistema de codificación central se estandarizaron formalmente el 13 de octubre de 2021 y el 30 de marzo de 2022, respectivamente.[8][9]

Descripción

editar

La convocatoria de propuestas JPEG XL habla sobre el requisito de un estándar de compresión de imágenes de próxima generación con una eficiencia de compresión sustancialmente mejor (60 % de mejora) en comparación con JPEG. Se espera que el estándar supere el rendimiento de compresión de imágenes fijas mostrado por HEIC, AVIF, WebP y JPEG 2000. También proporciona opciones eficientes de recompresión sin pérdidas para imágenes en el formato JPEG tradicional/heredado. JPEG XL admite compresión con pérdida y compresión sin pérdida de imágenes de ultra alta resolución (hasta 1 terapíxel), hasta 32 bits por componente, hasta 4099 componentes (incluida la transparencia alfa), imágenes animadas y vistas previas incrustadas. Tiene funciones destinadas a la entrega web, como la decodificación progresiva avanzada y la sobrecarga mínima del encabezado, así como funciones destinadas a la edición de imágenes y la impresión digital, como la compatibilidad con varias capas, CMYK y colores directos. Está específicamente diseñado para manejar a la perfección espacios de color de una amplia gama de colores con un alto rango dinámico como Rec. 2100 con la función de transferencia PQ o HLG.

Características

editar

Las características principales son:[10][11]

  • Compresión más rápida que AVIF, HEIF y WebP y rápida descompresión.
  • Soporte de varios espacios de color, Gama de colores amplia, gran profundidad de bits y HDR.
  • Se permiten resoluciones más grandes: tamaño de imagen de 1 073 741 823 píxeles (230−1) en horizontal y vertical.[12]
  • Codificación progresiva.
  • Codificación sin pérdida de datos y codificación del canal alfa.
  • Codificación de baja complejidad.
  • Soporte para contenido animado.
  • Recodificación reversible sin pérdidas del antiguo JPEG, con una reducción del tamaño de archivo de alrededor de un 20 %.[13]
  • Libre de regalías con una implementación de referencia.[14]

Programas

editar
  • Implementación de referencia JPEG XL (libjxl)
    • licencia: Nueva Licencia BSD (anteriormente Licencia Apache 2.0)
    • contiene (entre otras cosas):
      • cjxl codificador
      • djxl decodificador
      • codificador solo sin pérdida de calidad y con rutas rápidas fjxl
      • herramientas para medir y probar la velocidad y la calidad de varios códecs de imagen benchmark_xl
      • complemento con GIMP y Gtk pixbuf file-jxl
  • decodificador para JPEG XL (j40), independiente y autónomo.
    • con licencia: Licencia MIT Sin atribución
    • Biblioteca de encabezado único C99 (sin dependencia).
    • En números romanos, "XL" denota 40, de ahí el nombre.
  • hydrium: Codificador JPEG XL de transmisión rápido, de memoria ultrabaja, escrito en C portátil.[15]
  • libjxl-tiny: una implementación codificadora más simple de JPEG XL, dirigida a imágenes fotográficas sin un canal alfa.
  • jxlatte: decodificador Java JPEG XL.
  • jxl_decode: un decodificador Python JPEG XL.
    • con licencia: Licencia MIT Sin atribución
    • jpeg-xl-encode: un PHP JPEG

Compatibilidad

editar
  • GIMP, editor gráfico: utilizará un plugin oficial de libjxl con posibilidad de crear y abrir imágenes.
  • ImageMagick[16]​ – kit de herramientas para elaboración gráfica raster.
  • XnView MP[17]​ – lector de imágenes multi-plataforma para gráfica raster digital.
  • FFmpeg: Framework multimedia.
  • Squoosh- Aplicación web, utilizada principalmente para reducir el tamaño de una imagen, que incluye comparación original y vista previa. Convierta fuera de línea a través de recursos informáticos y utilice WebAssembly.
  • qt-jpegxl-image-plugin – apoyo JXL para la interfaz gráfica Qt sobre Linux y Windows.
  • JXLook – visor y plugin para macOS.
  • fork de JPEGView: editor visualizador de ráster gráfico.[18]
  • Ksnip – utilidad para la captura de pantalla.[19]

WIC PLUGIN Windows OS (compatibilidad no oficial)

editar
  • Vista en miniatura, solo sobre Windows 7/10 SO : COMPONENTE WIC
  • Otro plugin por Windows, antigua versión 0.5.0 de libjxl: JXL WIN THUMB en GitHub.

Detalles técnicos

editar
 
Arquitectura de códec

Modo modular es basado en FUIF, nacido después de FLIF. Contiene elementos de PIK lossless, lossless WebP con nuevas ideas que se han desarrollado durante el desarrollo de Jxl desde su punto de partida PIK + FUIF. JPEG XL se basa en ideas del formato PIK de Google y el formato FUIF de Cloudinary, que a su vez se basó en FLIF.[20]​ Dos modos de codificación, están incluidos en la finalización de enero de 2021.

Modular permite la compresión con pérdida con la ayuda de la transformada de Haar modificada, que tiene propiedades progresivas: la calidad de la imagen aumenta con la cantidad de datos cargados: una de las formas en que las imágenes basadas en VarDCT se pueden cargar progresivamente es guardando los coeficientes DC con squeeze, haciendo que ambos modos funcionen en conjunto. Los modos con pérdida suelen utilizar el espacio de color XYB derivado de LMS.[21]

Con este modo se pueden hacer una codificas sin pérdida, casi sin pérdida/delta de paleta) y es responsable, entre otras cosas, de la codificación eficiente de contenido sin pérdida. Modular está explotado internamente usando el VarDCT para guardar toda una serie de datos 2D auxiliares, como los campos/pesos de la cuantificación adaptativa y cualquier canal adicional/extra (por ejemplo, alfa, profundidad, térmico, colores directos, etc.) e imagen DC, 1 :8 imagen submuestreada (coeficientes DC) del modo VarDCT.

VarDCT y el modular pueden ser asistidos por un modelado separado de características de imagen específicas, desconocidas en otros códecs al momento de crear el formato:

  • splines para codificar, p. pelos (todavía no utilizados en el codificador de referencia), splines y ruidos se eliminan en Libjxl-tiny.
  • repetir "parches" como texto, puntos o sprites.
  • síntesis de ruido (dado que el ruido es difícil de predecir, es mejor separarlo y luego regenerar el ruido en el decodificador): esto aparentemente también se está imponiendo en otros códecs modernos: el esquema de compresión JPEG XL incluye un generador de ruido que reconstruye el ruido de los parámetros de la imagen, en lugar de comprimirlo directamente. El generador de grano AV1 es más como un generador de textura para parches relativamente grandes de grano de película analógica. El generador de ruido de Jxl se utiliza para modelar el ruido de fotones de un solo tamaño de píxel, como el que se obtiene en una cámara digital con una configuración ISO alta.

JPEG XL también puede volver a codificar archivos JPEG existentes sin pérdidas copiando directamente los coeficientes de bloque DCT de JPEG a bloques VarDCT de 8 × 8, lo que permite tamaños de archivo más pequeños debido a una mejor codificación de entropía, con datos de reconstrucción JPEG que permiten la transcodificación de nuevo al archivo JPEG original, aunque las restricciones limitan la compatibilidad para algunos archivos.[22]

La predicción se realiza utilizando un descorrelacionador píxel a píxel sin información colateral, que incluye un conjunto de predictores ponderados y autocorregibles parametrizados. El modelado de contexto incluye modelos estáticos especializados y potentes modelos meta-adaptativos que tienen en cuenta el error local, con una estructura de árbol marcada y una selección de predictores por contexto.

La codificación de entropía está habilitada con el algoritmo de compresión sin pérdidas LZ77 y puede usar tanto la codificación ANS como la codificación Huffman (para codificadores de baja complejidad o para reducir la sobrecarga de flujos cortos). El valor predeterminado es una configuración visualmente casi sin pérdidas que aún proporciona una buena compresión.[23]

Las imágenes en movimiento (fotogramas múltiples) no realizan predicción avanzada entre cuadros, aunque se encuentran disponibles algunas herramientas rudimentarias de codec de video:

  • un fotograma solo puede actualizar parte del lienzo.
  • un fotograma no solo puede reemplazar el contenido del lienzo, sino que también se puede mezclar, agregar o multiplicar[24]​ y * Se pueden "recordar" y hacer referencia a hasta cuatro fotogramas utilizando la herramienta de codificación "patches" en fotogramas posteriores.

Apoyo y adopción de la industria

editar

Además de Cloudinary y Google (originalmente), a lo largo de la implementación preliminar de JPEG XL en los navegadores web, varios representantes de marcas reconocidas de la industria han expresado públicamente su apoyo a JPEG XL como su opción preferida, incluido Facebook ,[25][26]Adobe,[27][28]Intel y la Video Electronics Standards Association,[29][30]The Guardian,[31][32]Flickr y SmugMug ,[33]Shopify,[34]​ la Fundación Krita,[35]​ y Serif Ltd.[36]

Mejoras sobre FUIF

editar

La compresión FLIF se puede experimentar aproximadamente en JPEG XL como 'modular': con la mayoría de las cosas mejoradas, pero también algunas debilitadas para resumir, FLIF / FUIF tiene aproximadamente un 50 % más de bytes que el modo VarDCT de JPEG XL, por lo que no es exactamente competitivo para fotografía. En JPEG XL, extendimos FLIF / FUIF con paletización delta (inspiración sin pérdidas de WebP), árboles de contexto estáticos en lugar de adaptativos para una decodificación más rápida (para velocidad), con el predictor de gradiente de Alexander Ratushnyak (posiblemente inspiración gralic / qlic) y con LZ77 con 2d corto códigos (inspiración sin pérdidas WebP).

Cómo funciona LZ77 en jxl

editar

Para comprimir texto, que en su mayoría son patrones repetitivos, jxl tiene dos métodos principales: parches y lz77 con códigos de distancia 2d. La limitación de lz77 es que los grupos se codifican de forma independiente, por lo que no puede hacer referencias fuera de cada grupo (de forma predeterminada) de 256x256. WebP no tiene grupos; al igual que PNG, se basa en filas, no en mosaicos, lo que es malo para la decodificación paralela pero bueno para patrones repetitivos horizontales como el texto. Otra cosa es que nunca descubrimos cómo combinar efectivamente el aprendizaje del árbol MA con lz77, por lo que el codificador actual básicamente hace uno o el otro, pero no ambos, lo que obviamente es subóptimo. Una mejor heurística de parches podría conducir a mejoras sustanciales para imágenes con mucho texto u otros patrones repetitivos como íconos o avatares. Los parches no tienen una limitación de límite de grupo: están codificados en un marco invisible separado y luego se puede hacer referencia a ellos en cualquier lugar. El principal problema es que no es fácil detectar realmente todos los patrones repetitivos en una imagen de una manera razonablemente rápida.

Estado de estandarización

editar
Nombre común Parte Primera fecha de lanzamiento público (Primera edición) Número ISO/IEC Título formal
JPEG XL Parte 1 30 de marzo de 2022 ISO/IEC 18181-1 JPEG XL Image Coding System — Part 1: Core coding system
Parte 2 13 de octubre de 2021 ISO/IEC 18181-2 JPEG XL Image Coding System — Part 2: File format
Parte 3 3 de octubre de 2022 ISO/IEC 18181-3 JPEG XL Image Coding System — Part 3: Conformance testing
Parte 4 5 de agosto de 2022 ISO/IEC 18181-4 JPEG XL Image Coding System — Part 4: Reference software

Referencias

editar
  1. «Can JPEG XL Become the Next Free and Open Image Format? - Slashdot». tech.slashdot.org (en inglés). 
  2. «Support for reading/writing JPEG XL images (#4681) · Issues · GNOME / GIMP». GitLab (en inglés). 
  3. «N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)» (en inglés). 
  4. «Committee Draft of JPEG XL Image Coding System» (en inglés). 
  5. «PIK, A new lossy/lossless image format for photos and the internet» (en inglés). 
  6. «FUIF, Free Universal Image Format» (en inglés). 
  7. «v0.2 JPEG XL Reference Software» (en inglés). 
  8. «ISO/IEC 18181-1:2022 Information technology — JPEG XL image coding system — Part 1: Core coding system» (en inglés). 
  9. «ISO/IEC 18181-2:2021 Information technology — JPEG XL image coding system — Part 2: File format» (en inglés). 
  10. «JPEG XL reaches Committee Draft» (html). JPEG (en inglés). 3 de agosto de 2019. Archivado desde l el original el 3 de agosto de 2019. Consultado el 3 de agosto de 2019. «The current contributors have committed to releasing it publicly under a royalty-free and open source license.» 
  11. «JPEG XL White Paper». JPEG Org. (en inglés). 22 de enero de 2021. Archivado desde el original el 2 de mayo de 2021. Consultado el 17 de marzo de 2021. 
  12. Sneyers, Jon (26 de mayo de 2020). «How JPEG XL Compares to Other Image Codecs» [Cómo se Compara JPEG XL a Otros Codecs de Imágenes]. Cloudinary (en inglés). Archivado desde el original el 30 de diciembre de 2021. Consultado el 19 de febrero de 2019. 
  13. «JPEG - 84th Meeting – Brussels, Belgium - JPEG XL reaches Committee Draft». jpeg.org (en inglés). 
  14. «jpeg / JPEG XL Reference Software». GitLab (en inglés). 
  15. Leo Izen (6 de marzo de 2023). «hydrium». GitHub. Consultado el 2 de abril de 2023. 
  16. https://imagemagick.org/script/formats.php#supported
  17. https://www.xnview.com/mantisbt/view.php?id=1845
  18. «JPEGView». GitHub. Consultado el 9 de abril de 2023. 
  19. «Ksnip». GitHub. Consultado el 9 de abril de 2023. 
  20. «FLIF - Free Lossless Image Format». Consultado el 6 de abril de 2021. 
  21. Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Szabadka, Zoltan; Bruse, Martin; Comsa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas et al. (6 de septiembre de 2019). «JPEG XL next-generation image compression architecture and coding tools». En Tescher, Andrew G, ed. Applications of Digital Image Processing XLII: 20. ISBN 9781510629677. doi:10.1117/12.2529237. 
  22. Sneyers, Jon. «Feature request: allow jbrd to reconstruct a part of the file when it's not possible for the whole file». GitHub. Consultado el 10 de diciembre de 2021. 
  23. Sneyers, Jon. «How JPEG XL Compares to Other Image Codecs». Cloudinary. 
  24. «JPEG XL reference implementation». GitHub. 3 de diciembre de 2021. Archivado desde el original el 30 de diciembre de 2021. Consultado el 24 de junio de 2021. 
  25. Andre, Erik (20 de abril de 2021). org/p/chromium/issues/detail?id=1178058#c16 «Declaración de apoyo de Facebook sobre el problema de Chromium n.º 1178058». bugs.chromium.org. Consultado el 03-11-2022. 
  26. Andre, Erik (24 de mayo de 2021). «Declaración de apoyo de Facebook sobre el problema de Firefox n.° 1539075». bugzilla.mozilla.org (en inglés). Consultado el 03-11-2022. 
  27. Rosenthol, Leonard (07-06-2021). «Declaración de apoyo de Adobe sobre el problema de Firefox #1539075». bugzilla.mozilla.org (en inglés). Consultado el 03-11-2022. 
  28. Chan, Eric (23 de agosto de 2022). «Declaración de apoyo de Adobe en Chromium problema n.º 1178058». bugs.chromium.org. Consultado el 03-11-2022. 
  29. Wooster, Roland (24 de agosto de 2022). «Declaración de apoyo a Chromium edición n.º 1178058 del presidente de DisplayHDR de VESA e ingeniero principal del grupo de computación de cliente de Intel». bugs.chromium.org. Consultado el 03-11-2022. 
  30. Wooster, Roland (11-11-2022). «Declaración reforzada de apoyo al problema de Chromium n.º 1178058 por el presidente e ingeniero principal de DisplayHDR de VESA en el grupo de computación de cliente de Intel =bugs.chromium.org». 
  31. Chauvin, Mariot (26 de agosto de 2022). «Declaración de apoyo de The Guardian sobre el problema de Chromium n.° 1178058». bugs.chromium.org. Consultado el 03-11-2022. 
  32. Chauvin, Mariot (13 de enero de 2022). «Declaración de apoyo de The Guardian en el problema de Firefox #1539075». bugzilla.mozilla.org (en inglés). Consultado el 03-11-2022. 
  33. MacAskill, Don (04-01-2022). mozilla.org/show_bug.cgi?id=1539075 «Declaración de apoyo de Flickr y SmugMug en el problema de Firefox n.º 1539075». bugzilla.mozilla.org (en inglés). Consultado el 03-11-2022. 
  34. Bendell, Colin (17 de octubre de 2022). detail?id=1178058#c79 «Declaración de apoyo de Shopify sobre el problema de Chromium n.º 1178058». bugs.chromium.org. Consultado el 03-11-2022. 
  35. Rempt, Rempt (10-11-2022). 1178058#c190 «Declaración de apoyo de la Fundación Krita sobre el problema de Chromium n.º 1178058». bugs.chromium.org. Consultado el 11-11-2022. 
  36. Brightman, Tony (11-11-2022). id=1178058#c192 «Declaración de apoyo de SerifLabs de Serif Ltd. sobre el problema de Chromium n.º 1178058». bugs.chromium.org. Consultado el 11-11-2022. 

Enlaces externos

editar