JPEG XL

Il nome è composto da JPEG derivante da il Joint Photographic Experts Group, che è il comitato che ne progettò il formato, X parte del nome di diversi standard JPEG dal 2000: JPEG XT, JPEG XR, JPEG XS) e L per lungo termine. La L è inclusa poiché l'intenzione degli autori per il formato è quella di sostituire il formato precedente JPEG e durare altrettanto a lungo.^[2]

Autori principali: Jyrki Alakuijala, Jon Sneyers, Luca Versari.

Altri collaboratori: Sami Boukortt, Alex Deymo, Moritz Firsching, Thomas Fischbacher, Eugene Kliuchnikov, Robert Obryk, Alexander Rhatushnyak, Zoltan Szabadka, Lode Vandevenne, Jan Wassenberg.

Nell'agosto 2017, JTC1 / SC29 / WG1 (JPEG) ha pubblicato un invito a presentare proposte per JPEG XL, lo standard di codifica delle immagini di nuova generazione.^[3] Le proposte sono state presentate entro settembre 2018, portando a una bozza del comitato nel luglio 2019.^[4] Si basava principalmente su una combinazione di una proposta denominata PIK,^[5] presentata da Google, e una proposta denominata FUIF^[6] — a sua volta basato su FLIF — presentato da Cloudinary.

Il flusso di bit è stato congelato in modo informale il 24 dicembre 2020 con il rilascio della versione 0.2 del software di riferimento libjxl.^[7] Il formato del file e il sistema di codifica principale sono stati formalmente standardizzati rispettivamente il 13 ottobre 2021 e il 30 marzo 2022.^[8][9]

Le proposte sono state presentate entro settembre 2018, portando a una bozza del comitato nel luglio 2019, con il formato del file e il sistema di codifica principale sono stati formalmente standardizzati rispettivamente il 13 ottobre 2021 e il 30 marzo 2022.^[10][11]

Le caratteristiche principali sono:^{[12][13][14][15]}

• Alta fedeltà all'immagine sorgente (corrisponde alla percezione umana).
• Alto rapporto di compressione (da 20:1 a 50:1).
• Funzionalità ed efficienza migliorate rispetto ai formati tradizionali.
• Sono consentite dimensioni maggiori: Dimensioni dell'immagine di oltre un miliardo (2³⁰−1) pixel su ciascun lato.^[16]
• Codifica e decodifica ad alta velocità, decompressione veloce.
• Supporto per immagini sia fotografiche che sintetiche.
• Grazioso degrado, della qualità su un'ampia gamma di bitrate.
• Encoder di riferimento percettivamente ottimizzato.
• Supporto ai contenuti animati, animazioni.
• Supporto per vari spazi di colore, a gamut larga, bit depth alti e HDR.
• Design responsivo / codifica progressiva, decodifica progressiva (per risoluzione e precisione).
• Codifica senza perdita di dati, del canale alpha senza perdita di dati; supporta la trasparenza alfa.
• Ricodifica senza perdita dei dati dei vecchi JPEG con riduzione della dimensione del file di circa il 20%.^[17]
• Codifica a bassa complessità, una codifica e decodifica efficienti senza richiedere hardware specializzato, compressione più rapida di H.265 HEVC HM, Daala e Webp.
• Royalty-free con implementazione di riferimento open source.^[18]
• Uno spazio colore più ampio, HDR, profondità colore superiori a 8 Bit, informazioni di stampa, panorami ad alta risoluzione, immagini a 360°, raffiche di immagini.

L'invito a presentare proposte^[3] per JPEG XL parla del requisito di uno standard di compressione delle immagini di prossima generazione con un'efficienza di compressione sostanzialmente migliore (miglioramento del 60%) rispetto a JPEG. Lo standard dovrebbe superare le prestazioni di compressione delle immagini fisse mostrate da HEIC, AVIF, WebP e JPEG 2000. Fornisce inoltre opzioni di ricompressione senza perdite efficienti per le immagini nel formato JPEG tradizionale/legacy. JPEG XL supporta la compressione con perdita e la compressione senza perdita di immagini ad altissima risoluzione (fino a 1 terapixel), fino a 32 bit per componente, fino a 4099 componenti (inclusa la trasparenza alfa), immagini animate e anteprime incorporate. Dispone di funzionalità mirate alla distribuzione sul Web come la decodifica progressiva avanzata^[19] e un sovraccarico minimo dell'intestazione, nonché funzionalità mirate all'elaborazione di immagini e alla stampa digitale, come il supporto per più livelli, CMYK e tinte piatte. È specificamente progettato per gestire senza problemi spazi colore ampi con una gamma dinamica elevata come Rec. 2100 con la funzione di trasferimento PQ o HLG.

• JPEG XL Reference Software (libjxl)
  • licenza: New BSD License (precedentemente Apache License 2.0)
  • contiene (tra l'altro):
    • codificatore cjxl
    • decodificatore djxl
    • codificatore solo senza perdita di qualità e con path rapidefjxl
    • strumenti per misurare e testare velocità e qualità dei vari codec immagine benchmark_xl
    • plugin con GIMP e Gtk pixbuf file-jxl
• decodificatore per JPEG XL (j40), indipendente ed autonomo
  • in licenza: Licenza MIT No Attribution
  • Libreria C99 a intestazione singola (nessuna dipendenza).
• hydrium: Codificatore JPEG XL veloce, a bassissima memoria, in streaming scritto in formato C.^[21]
  • licenza: BSD License

• https://caniuse.com/jpegxl.

• Windows 11 22000.194 non ha un'estensione, non è incluso nelle optional features o su Microsoft edge. 6
• Win thumb jxl^[22] –visualizzare le miniature nel formato .jxl su Windows Explorer, non associato a Microsoft e programmato in Rust. Funziona da Windows 10 in poi.
• Plugin KDE, installabile nelle distribuzioni Linux.
• FFmpeg^[23] – (libreria di conversione multi-platform).
• Imageglass.
• GIMP – editor di grafica raster.
• Krita 5.01, beta con un bug sull'esportazione delle animazioni.
• JPEGView fork – visualizzatore ed editor di grafica raster.^[24]
• Ksnip – utility per la cattura dello schermo.^[25]
• Elenco software community: https://github.com/libjxl/libjxl/blob/main/doc/software_support.md

• I documenti PDF integreranno il supporto a JXL ma secondo^[26] il PDF Association serviranno almeno altri 5 anni per ISO e ballots.
• Facebook, dopo 5 mesi di test, pianificava di introdurre libjxl nelle sue applicazioni appena fosse integrato nei browser.

JPEG XL si basa sulle idee del formato PIK di Google e del formato FUIF di Cloudinary (a sua volta basato su FLIF).^[27] La modalità modulare è basata su FUIF, nato dopo FLIF. Contiene degli elementi lossless PIK, WebP lossless e nuove idee che sono state sviluppate durante lo sviluppo di Jxl dal suo punto di partenza PIK + FUIF.^[28] JPEG XL può ricodificare senza perdita di dati i file JPEG esistenti copiando direttamente i coefficienti di blocco DCT di JPEG, su blocchi VarDCT 8 × 8, rendendo possibili file di dimensioni inferiori grazie ad una migliore codifica entropica.

I dati di ricostruzione JPEG consentono la transcodifica di nuovo nel file JPEG originale, sebbene i vincoli limitino il supporto per alcuni file.^[29]

Il formato si basa principalmente su 2 modalità di codifica, incluse nella finalizzazione di gennaio 2021:

• VarDCT (variable-blocksize DCT) - utilizza lo stesso algoritmo DCT del precedente JPEG, ma i blocchi invece di essere limitati a 8 × 8 sono disponibili in varie dimensioni (2 × 2 fino a 256 × 256), forme non quadrate (ad es. 16 × 8, 8 × 32, 32 × 64) e possono utilizzare altre trasformazioni (AFV, Hornuss). La modalità VarDCT si basa su PIK (con perdita).
• Modulare, che comprende lossless, quasi lossless/delta della tavolozza - responsabile, tra l'altro, dell'efficiente codifica dei contenuti senza perdita di dati. Questa è la modalità usata/sfruttata internamente in VarDCT per il salvataggio di tutta una serie di dati 2D ausiliari come i campi/pesi della quantizzazione adattiva e gli eventuali canali aggiuntivi/extra (alfa e profondità, termici, colori spot, ecc.) e l'immagine DC, 1:8 immagine sottocampionata (coefficienti DC) essa dalla modalità VarDCT. Esso consente la compressione con perdita con l'aiuto della trasformata Haar modificata (chiamata squeeze), che ha proprietà progressive: la qualità dell'immagine aumenta con la quantità di dati caricati.

Uno dei modi in cui le immagini basate su VarDCT possono essere caricate progressivamente è salvando i coefficienti DC di VarDCT con lo "squeeze" di modular facendo funzionare le modalità entrambe in tandem ed esse possono essere assistite da una modellazione separata di caratteristiche specifiche dell'immagine, sconosciute in altri codec al momento della creazione del formato:

• spline per la codifica, ad es. capelli (non ancora usate nel codificatore di riferimento); spline e rumori sono rimossi in Libjxl-tiny.
• ripetere "patches" come testo, punti o sprite.
• sintesi del rumore (poiché il rumore è difficile da prevedere, è meglio separarlo e quindi rigenerare il rumore nel decoder). Apparentemente questo sta prendendo piede anche su altri codec moderni: lo schema di compressione JPEG XL include un generatore di rumore che ricostruisce il rumore dai parametri nell'immagine, invece di comprimerlo direttamente. Il generatore di grana AV1 è più simile a un generatore di texture, per patch relativamente grandi di grana della pellicola analogica. Il generatore di rumore di Jxl viene utilizzato per modellare il rumore dei fotoni di un singolo pixel come quello che si ottiene su una fotocamera digitale con impostazioni ISO elevate.

Le modalità con perdita in genere utilizzano lo spazio colore XYB derivato da LMS.

La previsione viene eseguita utilizzando un decorrelatore pixel per pixel senza informazioni collaterali, incluso un insieme ponderato di predittori parametrizzati con correzione automatica. La modellazione del contesto include modelli statici specializzati e potenti modelli meta-adattivi che tengono conto dell'errore locale, con una struttura ad albero segnalata e una selezione di predittori per contesto. La codifica dell'entropia è abilitata per LZ77 e può utilizzare sia i sistemi numerici asimmetrici (ANS) sia la codifica Huffman (per codificatori a bassa complessità o per ridurre il sovraccarico di flussi brevi).^{[senza fonte]}

L'impostazione predefinita è un'impostazione visivamente quasi priva di perdite che fornisce comunque una buona compressione.

Le immagini animate (multi-frame) non eseguono previsioni avanzate tra i frame, sebbene siano disponibili alcuni rudimentali strumenti di codifica tra frame:

• le cornici possono aggiornare solo parti della tela;
• oltre a sostituire parti della tela, le cornici possono anche essere unite, aggiunte o moltiplicate a parti di essa;
• fino a quattro frame possono essere ricordati e referenziati utilizzando lo strumento di codifica "patch" nei frame successivi.

Oltre a Cloudinary e Google (originariamente), durante l'implementazione preliminare di JPEG XL nei browser Web, diversi noti rappresentanti di marchi del settore hanno espresso pubblicamente il loro supporto per JPEG XL come opzione preferita, tra cui Facebook ,^[30][31] Adobe,^[32][33] Intel e la Video Electronics Standards Association,^[34][35][36] Flickr e SmugMug ,^[37] Shopify,^[38] la Fondazione Krita,^[39] e Serif Ltd.^[40]

La compressione FLIF può essere sperimentata approssimativamente in JPEG XL come "modulare" -- con la maggior parte delle cose migliorate, ma anche alcune indebolite per dirla in breve, FLIF/FUIF è circa il 50% in più di byte rispetto alla modalità VarDCT di JPEG XL, quindi non lo è esattamente competitivo per le fotografie.

In JPEG XL abbiamo esteso FLIF/FUIF con la palettizzazione delta (ispirazione senza perdita di dati WebP), alberi di contesto statici anziché adattivi per una decodifica più rapida (per velocità), con il predittore di gradiente di Alexander Ratushnyak (possibile ispirazione gralic/qlic) e con LZ77 con 2d short codici (ispirazione senza perdita di dati WebP).

Per comprimere il testo, che è principalmente pattern ripetitivo, jxl ha due metodi principali: patch e lz77 con codici di distanza 2d. La limitazione di lz77 è che i gruppi sono codificati in modo indipendente, quindi non puoi fare riferimenti al di fuori di ciascun gruppo 256x256 (per impostazione predefinita). WebP non ha gruppi; proprio come PNG è basato su righe, non affiancato, il che è negativo per la decodifica parallela ma buono per schemi ripetitivi orizzontalmente come il testo. Un'altra cosa è che non abbiamo mai veramente capito come combinare efficacemente l'apprendimento dell'albero MA con lz77, quindi l'encoder attuale esegue sostanzialmente l'uno o l'altro ma non entrambi, il che ovviamente non è ottimale. Una migliore euristica delle patch potrebbe portare a miglioramenti sostanziali per le immagini con molto testo o altri schemi ripetitivi come icone o avatar. Le patch non hanno un limite di limite di gruppo: sono codificate in un frame invisibile separato e possono quindi essere referenziate ovunque. Il problema principale è che non è facile rilevare tutti i pattern ripetuti in un'immagine in un modo che sia comunque ragionevolmente veloce.

•   Wikimedia Commons contiene immagini o altri file su JPEG XL

• (EN) Sito ufficiale, su jpeg.org.  
• (EN) JPEG XL, su GitHub.