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
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.
Storia
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]
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.
Descrizione
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.
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).
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.
Dettagli tecnici
Architettura del codec
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.
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).
Come funziona LZ77 in jxl
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.
^ Alexander Rhatushnyak, Jan Wassenberg, Jon Sneyers, Jyrki Alakuijala, Lode Vandevenne, Luca Versari, Robert Obryk, Zoltan Szabadka, Evgenii Kliuchnikov, Iulia-Maria Comsa, Krzyszto f Potempa, Martin Bruse, Moritz Firsching, Renata Khasanova, Ruud van Asseldonk, Sami Boukortt, Sebastian Gomez e Thomas Fischbacher, Committee Draft of JPEG XL Image Coding System, 2019.
^ Jon Sneyers, How JPEG XL Compares to Other Image Codecs, su Cloudinary, 26 maggio 2020. URL consultato il 19 febbraio 2021 (archiviato dall'url originale il 30 dicembre 2021).
.svg){kind=small}
