JPEG XL

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
[editar datos en Wikidata]

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 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.

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]​

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.

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 (2³⁰−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]​

• 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]​
  • con licencia: Licencia BSD
• libjxl-tiny: una implementación codificadora más simple de JPEG XL, dirigida a imágenes fotográficas sin un canal alfa.
  • con licencia: Licencia BSD
• jxlatte: decodificador Java JPEG XL.
  • con licencia: Licencia MIT Sin atribución
• jxl_decode: un decodificador Python JPEG XL.
  • con licencia: Licencia MIT Sin atribución
  • jpeg-xl-encode: un PHP JPEG

• 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]​

• 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.

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.

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]​

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).

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.

• Sito oficial
• Referencia de Implementación
• Página personal del autor
• Portal:Informática. Contenido relacionado con Informática.