Annullando una controversa decisione del 2022 che ha bloccato l’adozione delle immagini di prossima generazione, Google ha confermato ufficialmente che ripristinerà il supporto per JPEG XL (JXL) nel suo browser Chrome.
JPEG XL (JXL) è un formato di immagine esente da royalty di nuova generazione progettato per sostituire lo standard JPEG legacy offrendo compressione superiore e funzionalità moderne come HDR, trasparenza e animazione. Il suo vantaggio principale è la capacità di transcodificare senza perdita di dati JPEG esistenti in file più piccoli (riducendo le dimensioni di circa il 20%) senza alcuna perdita di qualità.
La mossa di Google fa seguito ad anni di reazione negativa degli sviluppatori e alla crescente pressione da parte di attori dell’ecosistema rivali come Apple e Adobe, che hanno abbracciato il formato di file di grafica raster esente da royalty nonostante le precedenti affermazioni di Google di”mancanza di interesse”.
Gli ingegneri di Chrome ora affermano che forniranno la funzionalità una volta integrato un decoder memory-safe, segnalando un importante passo avanti nelle”guerre dei codec”del web e aprendo la strada a JXL per sostituire il vecchio standard JPEG.
A Percorso di redenzione basato su Rust
Rompendo uno stallo durato tre anni, Rick Byers, responsabile del team di audit di Chrome, ha ufficialmente posto fine al blocco dell’integrazione di JPEG XL in Discussione sulla mailing list di Blink-dev. L’approvazione dipende da due condizioni specifiche: la presenza di”segnali positivi”dall’ecosistema più ampio e una rigorosa conformità alla sicurezza.
Google sta esplicitamente rifiutando la precedente implementazione C++ a favore di un decoder”performante e sicuro per la memoria”, probabilmente scritto in Rust. Byers ha osservato che”dati questi segnali positivi, saremmo lieti di accogliere contributi per integrare in Chromium un decoder JPEG XL performante e sicuro per la memoria”, inquadrando la logica dell’adozione esterna piuttosto che dei parametri interni.
La manutenzione a lungo termine rimane l’ultimo ostacolo prima che la funzionalità raggiunga gli utenti. Google richiede che un team dedicato sia proprietario del codice del decodificatore prima che venga spedito al canale Stable.
Byers ha chiarito la sequenza temporale, affermando:”Per abilitarlo per impostazione predefinita in Chromium avremmo bisogno di un impegno per la manutenzione a lungo termine. Se questi e i nostri consueti criteri di lancio fossero soddisfatti, lo forniremo in Chrome.”
Lo sviluppatore Helmut Januschka ha fornito un aggiornamento granulare sullo stato del bug tracker di Chromium, confermando che il nuovo codice è basato sull’ultimo implementazione di riferimento di libjxl. L’aggiornamento dello sviluppatore afferma:
“Stato attuale: – Funzionalità completata – utilizzata la precedente implementazione JXL come modello e aggiornata all’implementazione di riferimento più recente – Aggiunto supporto per le animazioni (Chromium sarebbe il primo browser a supportare le animazioni JXL) – i robot sono verdi”
Januschka ha anche pubblicato la seguente demo che mostra il supporto per l’animazione JPEG XL in una build Chromium.
[contenuto incorporato]
Contrassegnato come”funzionalità completata”, il secondo quanto riferito, la nuova implementazione supera la maggior parte dei test automatizzati dei bot. Il supporto delle animazioni è un elemento di differenziazione tecnica fondamentale in questo secondo tentativo, superando potenzialmente l’implementazione iniziale di Safari.
Januschka ha osservato che”Chromium sarebbe il primo browser a supportare le animazioni JXL”, sebbene questa affermazione sia contestata da progetti più piccoli come il browser Thorium, che da allora supporta le animazioni JXL metà del 2024.
Il contesto della”Guerra dei codec”(2022-2025)
Google aveva originariamente rimosso il supporto JXL in Chrome 110 nel dicembre 2022, uccidendo di fatto lo slancio web del formato. All’epoca, Jim Bankoski dichiarò che”abbiamo deciso di interrompere l’esperimento JPEG XL di Chrome e rimuovere il codice associato all’esperimento”, citando vantaggi insufficienti rispetto al formato AVIF di Google.
I critici e gli esperti di compressione delle immagini hanno accusato Google di utilizzare metriche errate testando codificatori non ottimizzati per favorire AVIF. Scatenando uno dei thread più controversi nella storia di Chromium, la rimozione ha attirato oltre 1.000 stelle e centinaia di commenti da parte degli sviluppatori.
Durante la pausa, Google ha spinto in modo aggressivo AVIF, derivato dal codec video AV1, come unico successore di JPEG e WebP. Gli ingegneri hanno completamente rimosso il”flag di funzionalità”dal browser, impedendone anche un utilizzo sperimentale per quasi tre anni.
Consolidando la narrativa della”guerra dei formati”, questo periodo ha contrapposto l’AVIF basato su video di Google al design incentrato sull’immagine di JPEG XL.
Pressione dell’ecosistema e realtà tecnica
Apple ha sbloccato lo stallo nel 2023 aggiungendo il supporto JXL nativo a Safari 17. Creando uno scenario di”web diviso”, questa adozione ha comportato il caricamento di immagini ad alta fedeltà sugli iPhone ma ha fallito su Android e Chrome.
Adobe ha integrato JXL in Lightroom e Photoshop, mentre Microsoft ha aggiunto l’JPEG XL Image Extension a Windows 11, convalidandolo come standard professionale indipendentemente dal browser supporto.
La posizione di Mozilla è passata da”neutrale”a”positiva”, a condizione che i problemi di sicurezza fossero affrontati tramite un decoder basato su Rust. Tecnicamente, JXL offre un vantaggio unico: transcodifica senza perdita di JPEG esistenti per ridurre le dimensioni di circa il 20% senza perdita di generazione.
AVIF non dispone di questa capacità di transcodifica, richiedendo una ricodifica con perdita che degrada la qualità del contenuto di archivio. In linea con la più ampia tendenza del settore volta a eliminare le vulnerabilità della sicurezza della memoria nell’analisi di file multimediali complessi, il passaggio a un decodificatore basato su Rust garantisce stabilità a lungo termine.
