Wikipedia

JPEG XL

formato per immagini di tipo raster

JPEG XL è un formato per immagini di tipo raster. Supporta sia una compressione con perdita di dati che una compressione senza perdita di dati. È progettato per ottenere una compressione più efficiente dei formati preesistenti e fungere da loro sostituto in tutte le situazioni.[1]

JPEG XL
Estensione.jxl
Magic number
  • FF 0A
  • 00 00 00 0C 4A 58 4C 20 0D 0A 87 0A
Tipo MIMEimage/jxl
SviluppatoreJoint Photographic Experts Group, Google, Cloudinary
LicenzaRoyalty-free
TipoCompressione dell'immagine
CompressioneSia lossy che lossless
Estensione diPIK, FLIF, FUIF
StandardISO/IEC 18181
Formato aperto?Sì
Sito webjpeg.org/jpegxl/

Nome modifica

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 modifica

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 modifica

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]

Caratteristiche modifica

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 (230−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.

Descrizione modifica

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.

Programmi ed adozione modifica

Implementazioni codec modifica

libjxl
software
 
Logo
 
Schermata di esempio
GenereImplementazione di riferimento (non in lista)
SviluppatoreJoint Photographic Experts Group, Google e Cloudinary
Data prima versione27 dicembre 2019[20]
Ultima versione0.9.0 (22 dicembre 2023)
Sistema operativoUnix-like
macOS
Microsoft Windows
LinguaggioC++
LicenzaBSD 3-clausole
(licenza libera)
Sito webgithub.com/libjxl/libjxl
  • 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]

Browser web modifica

Software decodifica o esportazione jxl modifica

  • 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

Supporto futuro modifica

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

 
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.

Supporto e adozione del settore modifica

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]

Miglioramenti rispetto al FUIF modifica

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 modifica

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.

Stato standardizzazione modifica

Nome comune Parte Prima data di rilascio pubblica (Prima edizione) Numero ISO/IEC Titolo formale
JPEG XL Parte 1 30 marzo 2022 ISO/IEC 18181-1 JPEG XL Image Coding System — Part 1: Core coding system
Parte 2 13 ottobre 2021 ISO/IEC 18181-2 JPEG XL Image Coding System — Part 2: File format
Parte 3 3 ottobre 2022 ISO/IEC 18181-3 JPEG XL Image Coding System — Part 3: Conformance testing
Parte 4 5 agosto 2022 ISO/IEC 18181-4 JPEG XL Image Coding System — Part 4: Reference software

Note modifica

  1. ^ (EN) Can JPEG XL Become the Next Free and Open Image Format? - Slashdot, su tech.slashdot.org. URL consultato il 17 marzo 2021.
  2. ^ (EN) Support for reading/writing JPEG XL images (#4681) · Issues · GNOME / GIMP, su GitLab. URL consultato il 17 marzo 2021.
  3. ^ a b (EN) N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL) (PDF), su jpeg.org.
  4. ^ (EN) Committee Draft of JPEG XL Image Coding System, su arxiv.org.
  5. ^ (EN) PIK, A new lossy/lossless image format for photos and the internet, su github.com.
  6. ^ (EN) FUIF, Free Universal Image Format, su github.com.
  7. ^ (EN) v0.2 JPEG XL Reference Software, su gitlab.com.
  8. ^ (EN) ISO/IEC 18181-1:2022 Information technology — JPEG XL image coding system — Part 1: Core coding system, su iso.org.
  9. ^ (EN) ISO/IEC 18181-2:2021 Information technology — JPEG XL image coding system — Part 2: File format, su iso.org.
  10. ^ 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.
  11. ^ N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL) (PDF), in ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16). URL consultato il 29 maggio 2018.
  12. ^ JPEG XL reaches Committee Draft, su JPEG Org., 3 agosto 2019. URL consultato il 3 agosto 2019 (archiviato dall'url originale il 3 agosto 2019).
    «The current contributors have committed to releasing it publicly under a royalty-free and open source license.»
  13. ^ JPEG XL White Paper (PDF), su JPEG Org., 22 gennaio 2021. URL consultato il 17 marzo 2021 (archiviato dall'url originale il 2 maggio 2021).
  14. ^ (EN) encode.su JPEG XL VS AVIF Jyrki Alakuijala, su encode.su.
  15. ^ (EN) jpeg xl whitepaper (PDF), su ds.jpeg.org.
  16. ^ 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).
  17. ^ (EN) JPEG - 84th Meeting – Brussels, Belgium - JPEG XL reaches Committee Draft, su jpeg.org. URL consultato il 17 marzo 2021.
  18. ^ (EN) jpeg / JPEG XL Reference Software, su GitLab. URL consultato il 17 marzo 2021.
  19. ^ (EN) Using Saliency in progressive JPEG XL images, su opensource.googleblog.com.
  20. ^ Update JPEG-XL with latest changes., su GitHub, 27 dicembre 2019. URL consultato il 10 ottobre 2022.
  21. ^ Leo Izen, hydrium, su GitHub, 6 marzo 2023. URL consultato il 2 aprile 2023.
  22. ^ (EN) jxl-winthumb, su github.com.
  23. ^ (EN) FFmpeg Lands JPEG-XL Support, su phoronix.com. URL consultato il 24 aprile 2022.
  24. ^ JPEGView, su GitHub. URL consultato il 9 aprile 2023.
  25. ^ Ksnip, su GitHub. URL consultato il 9 aprile 2023.
  26. ^ (EN) PDF/R revisions and new highly compressed image format (Rene Rebe, Exactcode). URL consultato l'8 novembre 2021.
  27. ^ FLIF - Free Lossless Image Format, su flif.info. URL consultato il 6 aprile 2021 (archiviato dall'url originale il 21 dicembre 2021).
  28. ^ (EN) FLIF, 3 Sep 2021, jonsneyers comment, su github.com.
  29. ^ Jon Sneyers, Feature request: allow jbrd to reconstruct a part of the file when it's not possible for the whole file, su GitHub, 10 dicembre 2021.
  30. ^ Erik Andre, Dichiarazione di supporto di Facebook sul problema Chromium n. 1178058, su bugs.chromium.org, 20 aprile 2021. URL consultato il 3 novembre 2022.
  31. ^ (EN) Erik Andre, Facebook Support Statement for Firefox Issue #1539075, su bugzilla.mozilla.org, 24 maggio 2021. URL consultato il 3 novembre 2022.
  32. ^ (EN) Leonard Rosenthol, Dichiarazione del supporto Adobe su problema Firefox #1539075, su bugzilla.mozilla.org, 6 luglio 2021. URL consultato il 3 novembre 2022.
  33. ^ Eric Chan, Dichiarazione di supporto Adobe per il problema con Chromium #1178058, su bugs.chromium.org, 23 agosto 2022. URL consultato il 3 novembre 2022.
  34. ^ Roland Wooster, Dichiarazione di supporto per Chromium Issue # 1178058 del Presidente di VESA DisplayHDR e Principal Engineer di Intel Client Computing Group, su bugs.chromium.org, 24 agosto 2022. URL consultato il 3 novembre 2022.
  35. ^ Mariot Chauvin, Dichiarazione di sostegno del Guardian riguardo al problema Chromium n. 1178058, su bugs.chromium.org, 26 agosto 2022. URL consultato il 3 novembre 2022.
  36. ^ (EN) Implement support for JPEG XL, su bugzilla.mozilla.org. URL consultato il 3 novembre 2022.
  37. ^ (EN) Don MacAskill, Dichiarazione di supporto da parte di Flickr e SmugMug sul numero #1539075 di Firefox, su bugzilla.mozilla.org, 4 gennaio 2022. URL consultato il 3 novembre 2022.
  38. ^ (EN) Colin Bendell, Dichiarazione dell'assistenza Shopify sulla questione Chromium n. 1178058, su bugs.chromium.org, 17 ottobre 2022. URL consultato il 3 novembre 2022.
  39. ^ (EN) Rempt Rempt, Dichiarazione di supporto della Krita Foundation sulla questione Chromium #1178058, su bugs.chromium.org, 10 novembre 2022. URL consultato l'11 novembre 2022.
  40. ^ (EN) Tony Brightman, Dichiarazione di supporto da SerifLabs di Serif Ltd. sul problema di Chromium n. 1178058, su bugs.chromium.org, 11 novembre 2022. URL consultato l'11 novembre 2022.

Altri progetti modifica

Collegamenti esterni modifica

Estratto da "https://it.wikipedia.org/w/index.php?title=JPEG_XL&oldid=137114172"