Google riporta JPEG XL su Chrome

Contenuto di questo video

• L'annuncio di Chrome è stato pubblicato il 6 ottobre 2026 e menziona Chrome 155. Non stabilisce che ogni visitatore del sito web stia già utilizzando una versione supportata.
• Google attribuisce il merito al persistente feedback degli sviluppatori e al processo Interop. Il decodificatore jxl-rs utilizza Rust e operazioni vettoriali ottimizzate, mentre rimangono piccole aree unsafe verificate e la sandbox del browser.
• Il miglioramento della compressione pubblicizzato da Google, del 30-50%, utilizza JPEG come riferimento. I risparmi effettivi dipendono dalle immagini, dalle impostazioni dell'encoder e dalla qualità visiva.
• Il confronto tra encoder di settembre di Gianni Rosato favorisce AVIF su tutta la gamma di fedeltà con perdita testata. Sviluppa strumenti AVIF concorrenti; il suo risultato e l'affermazione di Google basata su JPEG misurano confronti diversi.
• Confronta i formati su immagini rappresentative e mantieni fallback compatibili. JPEG XL supporta anche la transcodifica reversibile e senza perdita di file JPEG esistenti.
• OpenAI ha rilasciato 722 manoscritti raggruppati in 372 famiglie, con verifica variabile e molte formalizzazioni Lean. Il modello rimane inedito e le cifre di calcolo equivalenti a Pro non sono né un prezzo al dettaglio né una garanzia di tempo trascorso.
• Il creatore dell'ESP32-C3 riporta un utilizzo di circa 50 KB di RAM memorizzando hash di dominio ordinati in flash. Il blocco a livello DNS ha limitazioni di stesso dominio e risolutore alternativo; le collisioni di hash possono bloccare eccessivamente. I risultati hardware non sono stati misurati indipendentemente per questo episodio.

Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

Perché Chrome sta riportando JPEG XL?

0:00 Probabilmente pensate che Google abbia seppellito JPEG XL. Chrome lo sta riportando, dopo aver rimosso il supporto sperimentale, e Rust lo ha aiutato a rientrare. In questo video, perché Google ha cambiato rotta? E dovreste cambiare la vostra pipeline di immagini? È mercoledì 7 ottobre, e questo è The Daily Diff. Tenete a mente un dettaglio. I vostri JPEG esistenti hanno un modo per rientrare in questo ritorno.

0:20 Martedì, Google ha annunciato la decodifica JPEG XL a partire da Chrome 155. Oggi l'annuncio è salito su Hacker News, accanto al "dump" di prove matematiche di OpenAI e a una scheda da due dollari che blocca i domini pubblicitari. Il precedente esperimento di Chrome si era concluso nel 2023.

Perché il formato rifiutato ha avuto un'altra possibilità?

0:35 La spiegazione di Google includeva un interesse insufficiente dell'ecosistema, il che è scomodo quando il browser più grande controlla se l'ecosistema può effettivamente usare la vostra cosa. Il nuovo post attribuisce il merito al persistente feedback degli sviluppatori, incluso il processo Interop. Le persone che lo chiedevano hanno continuato a chiederlo, e Google ora indica i test del browser intesi a far sì che il formato si comporti in modo coerente. L'annuncio accredita i contributori, tra cui Helmut Januschka.

0:57 A volte la roadmap più efficace è rifiutare di chiudere il problema.

Cosa è cambiato all'interno del decodificatore?

1:01 Il più grande cambiamento di implementazione è un decodificatore chiamato jay ex ell R S, scritto in Rust. I decodificatori di immagini ingeriscono file complessi forniti da estranei, il che li rende un posto spettacolare per fidarsi accidentalmente di internet. Rust aiuta a prevenire classi di errori di memoria prima che diventino vulnerabilità del browser. Google mantiene ancora la sandbox, e l'implementazione contiene ancora piccole aree unsafe attentamente revisionate. La sicurezza ha strati, perché la realtà continua a trovare le cuciture.

1:27 Google afferma che il fuzzing e la revisione del codice AI non hanno trovato bug di sicurezza della memoria nella storia di questo decodificatore. Questo è un rapporto utile dal team che lo spedisce. È improbabile che i futuri attaccanti accettino il post del blog come un contratto vincolante. Prima domanda risolta. La pressione degli sviluppatori e un decodificatore Rust ottimizzato hanno riaperto la porta. Google ha invertito una decisione con l'ingegneria alle spalle, il che è consentito anche su internet. Ora i benchmark della presentazione.

I file più piccoli battono AVIF?

1:48 Google pubblicizza una compressione dal trenta al cinquanta percento migliore rispetto a JPEG. Download più piccoli possono aiutare i vostri utenti e la vostra bolletta della larghezza di banda, ma quel range dipende da cosa codificate e da come confrontate la qualità. L'ingegnere di compressione Gianni Rosato ha pubblicato un confronto a settembre in cui i moderni encoder avif battono JPEG XL su tutta la sua gamma di fedeltà testata. Lavora su strumenti avif concorrenti, quindi tenete a mente quell'incentivo accanto ai grafici. Questi confronti utilizzano diverse basi di riferimento.

2:12 Battere il vecchio JPEG lascia spazio ad avif per vincere un carico di lavoro. Google stessa raccomanda di provare entrambi i formati, il che è un consiglio insolitamente pratico per un annuncio di lancio. Le altre attrazioni di JPEG XL includono l'alta gamma dinamica, immagini senza perdita e decodifica progressiva a grana fine. La community pubblica demo interattive per esplorare il formato. Il vostro pubblico può vedere un'immagine utile mentre il resto arriva. Per l'implementazione, mantenete un'immagine di fallback e verificate il supporto nei browser che i vostri

2:37 clienti utilizzano effettivamente. L'annuncio nomina Chrome 155. Questo vi dà una versione target, e le vostre analisi vi dicono quando il vostro pubblico ci arriva. Seconda domanda risolta. Testate le vostre immagini reali prima di cambiare la pipeline e preservate il percorso di compatibilità. Un formato di immagine che risparmia byte è utile. Una migrazione che nasconde il vostro pulsante di checkout è un'interpretazione costosa del minimalismo. Nel frattempo, martedì OpenAI ha pubblicato manoscritti matematici e artefatti di prova a supporto.

Cosa ha effettivamente pubblicato OpenAI?

3:00 Il repository contiene 722 manoscritti, raggruppati in famiglie correlate. Il conteggio del titolo include argomenti di accompagnamento e prove alternative, quindi leggete cosa afferma effettivamente ogni articolo. Molti hanno prove formali in Lean, che permette a un computer di verificare le deduzioni matematiche. Altri attendono ancora la formalizzazione, e OpenAI avverte esplicitamente che alcuni risultati non formalizzati potrebbero avere problemi.

3:21 Il repository fornisce ai ricercatori materiale che possono ispezionare e contestare. Il modello rimane inedito. OpenAI afferma che ogni risultato ha utilizzato in media circa tre ore di calcolo equivalente a ChatGPT Pro. Ciò descrive lo sforzo computazionale. Non vi dà né una garanzia di tempo di esecuzione né un prezzo al dettaglio per produrre un teorema. Il rilascio segue la consultazione con un gruppo consultivo indipendente di matematica, e include un processo di revisione e citazione.

3:40 Il mondo accademico riceve un nuovo mucchio di compiti, oltre alla ben più utile capacità di indicare la pagina esatta che necessita di correzioni. I manutentori di Lean raccomandano di compilare piccole porzioni alla volta. Anche una svolta matematica alla fine incontra l'antico nemico del software, far finire la build. Infine, un ad blocker DNS open source funziona su una minuscola scheda microcontroller da due dollari. Il trucco del creatore è memorizzare gli hash di dominio ordinati in flash,

Come blocca i domini una scheda da due dollari?

4:03 quindi la lista di blocco non deve risiedere nella scarsa memoria di lavoro. Il progetto riporta circa cinquanta kilobyte di utilizzo della RAM. Cerca un dominio richiesto nella tabella flash, blocca una corrispondenza e inoltra le altre query a monte. Il vostro router può acquisire un minuscolo buttafuori con una lista ospiti molto specifica. Il filtraggio DNS funziona a livello di dominio. Gli annunci serviti dallo stesso dominio di contenuti utili possono sfuggire, e i client che utilizzano un altro risolutore possono bypassarlo.

4:28 Mantenete le vostre aspettative più piccole della scheda, che è un obiettivo di dimensioni impegnativo. E il dettaglio sui vostri JPEG esistenti? JPEG XL supporta la transcodifica JPEG senza perdita, con un percorso per ricostruire l'originale JPEG.

I tuoi JPEG esistenti possono unirsi al ritorno?

4:40 Questo offre a un vecchio archivio di immagini un'opzione di migrazione senza un'altra generazione di perdita di qualità. Testate i compromessi di archiviazione e consegna. Se preferite leggerlo piuttosto che sentirmi dirlo, la diff arriva nella vostra casella di posta ogni mattina, gratuitamente su the daily diff dot dev, link qui sotto. Quindi il verdetto di oggi, SHIP IT. Spedirei il decodificatore aggiuntivo perché il supporto del browser offre agli sviluppatori una scelta reale,

Perché dovrei spedire il decodificatore e testare la migrazione?

4:58 e testerei la migrazione sulle nostre immagini. Iscrivetevi, cliccate sulla campanella e ditemi nei commenti se l'avreste timbrato in modo diverso. E questa è la diff di oggi. Sono Niko di Axrisi. Unite responsabilmente. Sono Niko di Axrisi. Unite responsabilmente.

Fonti

1. Shipping JPEG XL in ChromeChrome for Developers
2. JPEG XL prototype and November 2022 removal discussionChromium Blink developers
3. Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
4. The case against JPEG XL — competing-encoder benchmarkGianni Rosato
5. JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
6. HTML picture element and fallback selectionMDN Web Docs
7. Progressive loading demoJPEG XL community
8. Distance versus effort visualizerJPEG XL community
9. Sharing AI progress in mathematicsOpenAI
10. Mathematical manuscripts and proof artifactsOpenAI on GitHub
11. Lean formalization library build notesOpenAI on GitHub
12. ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub