Google bring JPEG XL terug na Chrome
Google het JPEG XL-dekodering aangekondig wat begin met Chrome 155 nadat sy vroeëre eksperiment verwyder is.
Google het JPEG XL-dekodering aangekondig wat begin met Chrome 155 nadat sy vroeëre eksperiment verwyder is. Hierdie uitgawe van 7 Oktober ondersoek ontwikkelaarsterugvoer, die nuwe Rust-dekodeerder, mededingende kompressie-aansprake en ontplooiingsvalbakke, en kyk dan na OpenAI se nuut gepubliseerde wiskundige bewys-artefakte en 'n ESP32-C3 DNS-sinkgat se hash-in-flits-ontwerp.
Lees die geskrewe uitgawe (Engels) ↗
Wat hierdie video dek
- 'n Aankondiging vir Chrome is op 6 Oktober 2026 gepubliseer en noem Chrome 155. Dit bevestig nie dat elke webwerfbesoeker reeds 'n ondersteunde weergawe gebruik nie.
- Google skryf aanhoudende ontwikkelaarsterugvoer en die Interop-proses toe. Die jxl-rs-dekodeerder gebruik Rust en geoptimaliseerde vektoroperasies, terwyl klein veilige onveilige areas en die blaaier-sandbox bly.
- Google se geadverteerde 30-50% kompressieverbetering gebruik JPEG as sy basislyn. Werklike besparings hang af van beelde, enkodeerderinstellings en visuele kwaliteit.
- Gianni Rosato se September-enkodeerdervergelyking bevoordeel AVIF oor sy getoetste lossy-getrouheidsreeks. Hy ontwikkel mededingende AVIF-instrumente; sy resultaat en Google se JPEG-basislyn-aanspraak meet verskillende vergelykings.
- Vergelyk formate op verteenwoordigende beelde en hou versoenbare valbakke. JPEG XL ondersteun ook omkeerbare, verlieslose transkodering van bestaande JPEG-lêers.
- OpenAI het 722 manuskripte wat in 372 families gegroepeer is, vrygestel, met verskillende verifikasie en baie Lean-formaliserings. Die model bly onuitgereik, en Pro-ekwivalente rekenaarsyfers is nóg 'n kleinhandelprys nóg 'n verstreke-tydwaarborg.
- Die ESP32-C3-skepper rapporteer ongeveer 50 KB RAM-gebruik deur gesorteerde domein-hashes in flits te stoor. DNS-vlakblokkering het dieselfde-domein- en alternatiewe-oplossersbeperkings; hash-botsings kan oormatig blokkeer. Hardeware-resultate is nie onafhanklik vir hierdie episode gemeet nie.
Vertaalde transkripsie
Vertaal uit die oorspronklike Engelse vertelling. Beskikbare klank en onderskrifte word deur YouTube beheer.
Hoekom bring Chrome JPEG XL terug?
0:00 Jy dink waarskynlik Google het JPEG XL begrawe. Chrome bring dit terug, nadat eksperimentele ondersteuning verwyder is, en Rust het gehelp om dit deur die deur te kry. In hierdie video, hoekom het Google van koers verander? En moet jy jou beeldpypleiding verander? Dit is Woensdag, sewe Oktober, en dit is The Daily Diff. Hou een detail in gedagte. Jou bestaande JPEG's het 'n manier om deel te wees van hierdie terugkeer.
0:20 Dinsdag het Google JPEG XL-dekodering aangekondig wat begin met Chrome een honderd vyf en vyftig. Vandag het die aankondiging Hacker News geklim, saam met OpenAI se wiskundige bewys-storting en 'n twee-dollar bord wat advertensiedomeine blokkeer. Chrome se vroeëre eksperiment het in twintig drie en twintig geëindig.
Hoekom het die verwerpte formaat 'n tweede kans gekry?
0:35 Google se verduideliking het onvoldoende ekosisteem-belangstelling ingesluit, wat ongemaklik is wanneer die grootste blaaier beheer of die ekosisteem werklik jou ding kan gebruik. Die nuwe pos gee krediet aan aanhoudende ontwikkelaarsterugvoer, insluitend die Interop-proses. Die mense wat hiervoor gevra het, het aanhou vra, en Google wys nou na blaaier-toetse wat bedoel is om die formaat konsekwent te laat optree. Die aankondiging gee krediet aan bydraers insluitend Helmut Januschka.
0:57 Soms is die mees effektiewe padkaart om te weier om die probleem te sluit.
Wat het binne-in die dekodeerder verander?
1:01 Die grootste implementeringsverandering is 'n dekodeerder genaamd jay ex ell R S, geskryf in Rust. Beelddekodeerders neem ingewikkelde lêers wat deur vreemdelinge verskaf word, in, wat dit 'n skouspelagtige plek maak om per ongeluk die internet te vertrou. Rust help om klasse geheuefoute te voorkom voordat dit blaaierkwesbaarhede word. Google hou steeds die sandbox, en die implementering bevat steeds klein, versigtig nagegaan onveilige areas. Sekuriteit kry lae, want die werklikheid bly die nate vind.
1:27 Google sê fuzzing en KI-kode-evaluering het geen geheueveiligheidsfoute in die geskiedenis van hierdie dekodeerder gevind nie. Dit is 'n nuttige verslag van die span wat dit stuur. Toekomstige aanvallers sal waarskynlik nie die blogpos as 'n bindende kontrak aanvaar nie. Eerste vraag beantwoord. Ontwikkelaarsdruk en 'n geoptimaliseerde Rust-dekodeerder het die deur heropen. Google het 'n besluit met ingenieurswese daaragter omgekeer, wat selfs op die internet toegelaat word. Nou die skyfiereeks-maatstawwe.
Klop die kleiner lêers AVIF?
1:48 Google adverteer dertig tot vyftig persent beter kompressie as JPEG. Kleiner aflaaie kan jou gebruikers en bandwydte rekening help, maar daardie reeks hang af van wat jy enkodeer en hoe jy kwaliteit vergelyk. Kompressie-ingenieur Gianni Rosato het 'n September-vergelyking gepubliseer waar moderne avif-enkodeerders JPEG XL oor sy getoetste getrouheidsreeks geklop het. Hy werk aan mededingende avif-instrumente, so hou daardie aansporing langs die grafieke. Hierdie vergelykings gebruik verskillende basislyne.
2:12 Om ou JPEG te klop, laat ruimte vir avif om 'n werklading te wen. Google self beveel aan om albei formate te probeer, wat ongewoon praktiese advies is vir 'n bekendstellingsaankondiging. JPEG XL se ander aantreklikhede sluit in hoë dinamiese omvang, verlieslose beelde en fynkorrelige progressiewe dekodering. Die gemeenskap publiseer interaktiewe demonstrasies om die formaat te verken. Jou gehoor kan 'n nuttige prent sien terwyl die res arriveer. Vir ontplooiing, hou 'n valbakbeeld, en verifieer ondersteuning in die blaaiers wat jou
2:37 kliënte werklik gebruik. Die aankondiging noem Chrome een vyftig vyf. Dit gee jou 'n teikenweergawe, en jou analise vertel jou wanneer jou gehoor daar kom. Tweede vraag beantwoord. Toets jou regte beelde voordat jy die pyplyn verander, en behou die versoenbaarheidspad. 'n Beeldformaat wat grepe bespaar, is nuttig. 'n Migrasie wat jou betaalknoppie versteek, is 'n duur interpretasie van minimalisme. Intussen het OpenAI Dinsdag wiskundige manuskripte en ondersteunende
Wat het OpenAI eintlik gepubliseer?
3:00 bewys-artefakte gepubliseer. Die bewaarplek bevat sewe honderd twee en twintig manuskripte, gegroepeer in verwante families. Die opskriftelling sluit gepaardgaande argumente en alternatiewe bewyse in, so lees wat elke artikel eintlik beweer. Baie het formele bewyse in Lean, wat 'n rekenaar toelaat om wiskundige afleidings na te gaan. Ander wag nog op formalisering, en OpenAI waarsku uitdruklik dat
3:21 sommige ongeformaliseerde resultate probleme kan hê. Die bewaarplek gee navorsers materiaal wat hulle kan inspekteer en uitdaag. Die model bly onuitgereik. OpenAI sê elke resultaat het gemiddeld ongeveer drie uur se ekwivalente ChatGPT Pro denkrekenaar gebruik. Dit beskryf rekenkundige inspanning. Dit gee jou nóg 'n muurhorlosie- waarborg nóg 'n kleinhandelprys vir die produksie van 'n
3:40 stelling. Die vrystelling volg op konsultasie met 'n onafhanklike wiskunde- adviesgroep, en sluit 'n hersienings- en sitasieproses in. Akademia kry 'n nuwe hoop huiswerk, plus die veel nuttiger vermoë om te wys na die presiese bladsy wat reggestel moet word. Die Lean-onderhouers beveel aan om klein gedeeltes op 'n slag te saam te stel. Selfs 'n wiskundige deurbraak ontmoet uiteindelik die antieke vyand van sagteware, om die bouproses te voltooi.
Hoe blokkeer 'n twee-dollar bord domeine?
4:03 Laastens loop 'n oopbron DNS-advertensieblokker op 'n klein twee-dollar mikrobeheerder- bord. Die skepper se truuk is om gesorteerde domein-hashes in flits te stoor, sodat die bloklys nie in skaars werkgeheue hoef te wees nie. Die projek rapporteer ongeveer vyftig kilogrepe RAM-gebruik. Dit soek 'n aangevraagde domein in die flits-tabel op, blokkeer 'n passing en stuur ander navrae stroomop aan. Jou roeteerder kan 'n klein uitsmyter met 'n baie spesifieke gaslys bekom. DNS-filtrering werk op domeinvlak.
4:28 Advertensies wat vanaf dieselfde domein as nuttige inhoud bedien word, kan deurslip, en kliënte wat 'n ander oplosser gebruik, kan dit omseil. Hou jou verwagtinge kleiner as die bord, wat 'n veeleisende grootte-teiken is. En die detail oor jou bestaande JPEG's?
Kan jou bestaande JPEG's by die terugkeer aansluit?
4:40 JPEG XL ondersteun verlieslose JPEG-transkodering, met 'n pad om die oorspronklike JPEG te rekonstrueer. Dit gee 'n ou beeldargief 'n migrasie-opsie sonder 'n verdere generasie van kwaliteitsverlies. Toets die berging- en afleweringskompromieë. As jy dit eerder wil lees as om my dit te hoor sê, land die verskil elke oggend gratis in jou inkassie by the daily diff dot dev, skakel hieronder.
Hoekom sou ek die dekodeerder stuur en die migrasie toets?
4:58 So vandag se uitspraak, SHIP IT. Ek sal die bykomende dekodeerder stuur omdat blaaierondersteuning ontwikkelaars 'n werklike keuse gee, en ek sal die migrasie op ons eie beelde toets. Teken in, druk die klokkie, en vertel my in die kommentaar as jy dit anders gestempel het. En dit is die verskil vir vandag. Ek is Niko van Axrisi. Voeg verantwoordelik saam.
Bronne
- Shipping JPEG XL in ChromeChrome for Developers
- JPEG XL prototype and November 2022 removal discussionChromium Blink developers
- Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
- The case against JPEG XL — competing-encoder benchmarkGianni Rosato
- JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
- HTML picture element and fallback selectionMDN Web Docs
- Progressive loading demoJPEG XL community
- Distance versus effort visualizerJPEG XL community
- Sharing AI progress in mathematicsOpenAI
- Mathematical manuscripts and proof artifactsOpenAI on GitHub
- Lean formalization library build notesOpenAI on GitHub
- ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub



