A Google visszahozza a JPEG XL-t a Chrome-ba

Amit ez a videó tartalmaz

• A Chrome bejelentése 2026. október 6-án jelent meg, és a Chrome 155-öt nevezi meg. Nem állapítja meg, hogy minden webhelylátogató már támogatott verziót futtatna.
• A Google a kitartó fejlesztői visszajelzéseknek és az Interop folyamatnak tulajdonítja a visszatérést. A jxl-rs dekóder Rustot és optimalizált vektorműveleteket használ, miközben kis, ellenőrzött, nem biztonságos területek és a böngésző "sandbox" megmarad.
• A Google által hirdetett 30-50%-os tömörítési javulás a JPEG-et veszi alapul. A tényleges megtakarítások a képektől, a kódoló beállításaitól és a vizuális minőségtől függenek.
• Gianni Rosato szeptemberi kódoló összehasonlítása az AVIF-et részesíti előnyben a tesztelt veszteséges-hűségi tartományban. Versengő AVIF eszközöket fejleszt; az ő eredménye és a Google JPEG-alapú állítása különböző összehasonlításokat mér.
• Hasonlítsa össze a formátumokat reprezentatív képeken, és tartson kompatibilis tartalékokat. A JPEG XL támogatja a meglévő JPEG fájlok visszafordítható, veszteségmentes átkódolását is.
• Az OpenAI 722 kéziratot adott ki, 372 családba csoportosítva, változatos ellenőrzéssel és sok Lean formalizálással. A modell továbbra is kiadatlan, és a Pro-egyenértékű számítási adatok sem kiskereskedelmi ár, sem eltelt idő garanciája.
• Az ESP32-C3 alkotója körülbelül 50 KB RAM-használatról számol be, rendezett tartományi hash-ek flash-ben tárolásával. A DNS-szintű blokkolásnak vannak azonos tartományra és alternatív feloldóra vonatkozó korlátai; a hash ütközések túlzott blokkolást okozhatnak. A hardveres eredményeket nem mérték függetlenül ebben az epizódban.

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

Miért hozza vissza a Chrome a JPEG XL-t?

0:00 Valószínűleg azt gondolja, hogy a Google eltemette a JPEG XL-t. A Chrome visszahozza, miután eltávolította a kísérleti támogatást, és a Rust segített neki bejutni az ajtón. Ebben a videóban, miért változtatta meg a Google a döntését? És meg kellene változtatnia a képfeldolgozási folyamatát? Szerda, október hetedike van, és ez a The Daily Diff. Tartson észben egy részletet. A meglévő JPEG-jeinek van módja, hogy részt vegyenek ebben a visszatérésben.

0:20 Kedden a Google bejelentette a JPEG XL dekódolását a Chrome százötvenötös verziójától kezdődően. Ma a bejelentés felkerült a Hacker News-ra, az OpenAI matematikai bizonyítékgyűjteménye és egy két dolláros alaplap mellé, amely reklámtartományokat blokkol. A Chrome korábbi kísérlete 2023-ban ért véget.

Miért kapott még egy esélyt az elutasított formátum?

0:35 A Google magyarázata magában foglalta az elégtelen ökoszisztéma-érdeklődést, ami kínos, amikor a legnagyobb böngésző irányítja, hogy az ökoszisztéma valójában használhatja-e a dologát. Az új bejegyzés a kitartó fejlesztői visszajelzéseknek tulajdonítja, beleértve az Interop folyamatot. Azok az emberek, akik ezt kérték, továbbra is kérdezték, és a Google most böngészőtesztekre hivatkozik, amelyek célja, hogy a formátum következetesen viselkedjen. A bejelentés olyan közreműködőket említ, mint Helmut Januschka.

0:57 Néha a leghatékonyabb ütemterv az, ha nem hajlandó lezárni a problémát.

Mi változott a dekóderben?

1:01 A legnagyobb implementációs változás egy jay ex ell R S nevű dekóder, Rustban írva. A képdekóderek idegenek által szolgáltatott bonyolult fájlokat dolgoznak fel, ami látványos hellyé teszi őket az internet véletlen megbízására. A Rust segít megelőzni a memóriahibák osztályait, mielőtt azok böngésző sebezhetőségekké válnának. A Google továbbra is fenntartja a "sandbox"-ot, és az implementáció továbbra is tartalmaz kis, gondosan felülvizsgált nem biztonságos területeket. A biztonság rétegeket kap, mert a valóság folyamatosan megtalálja a réseket.

1:27 A Google szerint a "fuzzing" és az AI kódellenőrzés nem talált memóriabiztonsági hibát ebben a dekóder történetében. Ez egy hasznos jelentés a szállító csapattól. A jövőbeli támadók valószínűleg nem fogadják el a blogbejegyzést kötelező érvényű szerződésként. Első kérdés megválaszolva. A fejlesztői nyomás és egy optimalizált Rust dekóder újra kinyitotta az ajtót. A Google megváltoztatta egy olyan döntést, amely mögött mérnöki munka állt, ami az interneten is megengedett. Most pedig a diavetítés benchmarkjai.

A kisebb fájlok jobbak, mint az AVIF?

1:48 A Google harminc-ötven százalékkal jobb tömörítést hirdet, mint a JPEG. A kisebb letöltések segíthetnek a felhasználóknak és a sávszélesség-számlán, de ez a tartomány attól függ, hogy mit kódol és hogyan hasonlítja össze a minőséget. Gianni Rosato tömörítési mérnök publikált egy szeptemberi összehasonlítást, ahol a modern AVIF kódolók verték a JPEG XL-t az általa tesztelt hűségi tartományban. Versengő AVIF eszközökön dolgozik, ezért tartsa ezt a motivációt a grafikonok mellett. Ezek az összehasonlítások különböző alapokat használnak.

2:12 A régi JPEG legyőzése helyet hagy az AVIF-nek a munkaterhelés megnyeréséhez. Maga a Google is javasolja mindkét formátum kipróbálását, ami szokatlanul praktikus tanács egy bevezető bejelentéshez. A JPEG XL egyéb vonzerejei közé tartozik a nagy dinamikatartomány, a veszteségmentes képek és a finom szemcséjű progresszív dekódolás. A közösség interaktív demókat publikál a formátum felfedezéséhez. A közönség hasznos képet láthat, miközben a többi megérkezik. Telepítéshez tartson egy tartalék képet, és ellenőrizze a támogatást azokban a böngészőkben,

2:37 amelyeket az ügyfelei ténylegesen használnak. A bejelentés a Chrome százötvenötös verzióját nevezi meg. Ez megadja a célverziót, és az analitikája megmondja, mikor éri el a közönsége azt. Második kérdés megválaszolva. Tesztelje a valós képeit a folyamat megváltoztatása előtt, és őrizze meg a kompatibilitási utat. Egy bájtokat megtakarító képformátum hasznos. Egy migráció, amely elrejti a fizetés gombját, a minimalizmus drága értelmezése. Eközben az OpenAI kedden matematikai kéziratokat és támogató

Mit is publikált valójában az OpenAI?

3:00 bizonyítási műtermékeket publikált. A tárház hétszázhuszonkét kéziratot tartalmaz, rokon családokba csoportosítva. A főcímben szereplő szám magában foglalja a kísérő érveket és az alternatív bizonyításokat, ezért olvassa el, mit állít valójában az egyes tanulmányok. Sok Lean-ben formális bizonyítékot tartalmaz, amely lehetővé teszi a számítógép számára a matematikai levezetések ellenőrzését. Mások még várják a formalizálást, és az OpenAI kifejezetten figyelmeztet, hogy

3:21 egyes nem formalizált eredményekkel problémák lehetnek. A tárház olyan anyagokat ad a kutatóknak, amelyeket megvizsgálhatnak és megkérdőjelezhetnek. A modell továbbra is kiadatlan. Az OpenAI szerint minden eredmény átlagosan körülbelül három órányi egyenértékű ChatGPT Pro számítási teljesítményt használt. Ez a számítási erőfeszítést írja le. Nem ad sem időbeli garanciát, sem kiskereskedelmi árat egy

3:40 tétel előállításához. A kiadás egy független matematikai tanácsadó csoporttal folytatott konzultációt követően történt, és tartalmaz egy felülvizsgálati és hivatkozási folyamatot. Az akadémia újabb adag házi feladatot kap, plusz a sokkal hasznosabb képességet, hogy rámutasson a pontosan javítandó oldalra. A Lean karbantartói azt javasolják, hogy egyszerre kis részeket fordítsanak le. Még egy matematikai áttörés is végül találkozik a szoftver ősi ellenségével, a fordítás befejezésével.

Hogyan blokkol tartományokat egy két dolláros alaplap?

4:03 Végül egy nyílt forráskódú DNS reklámblokkoló fut egy apró, két dolláros mikrokontroller lapon. Az alkotó trükkje a rendezett tartományi hash-ek flash-ben tárolása, így a blokklista nem kell, hogy szűkös munkamemóriában éljen. A projekt körülbelül ötven kilobájt RAM-használatról számol be. Megkeres egy kért tartományt a flash táblában, blokkolja az egyezést, és továbbítja a többi lekérdezést felfelé. Az útválasztója szert tehet egy apró kidobóra, nagyon specifikus vendéglistával. A DNS szűrés tartományi szinten működik.

4:28 A hasznos tartalommal azonos tartományból érkező hirdetések átcsúszhatnak, és az más feloldót használó ügyfelek megkerülhetik. Tartsa az elvárásait kisebbnek, mint az alaplap, ami egy igényes méretcél. És a részlet a meglévő JPEG-jeiről?

Csatlakozhatnak a meglévő JPEG-jei a visszatéréshez?

4:40 A JPEG XL támogatja a veszteségmentes JPEG átkódolást, útvonallal az eredeti JPEG rekonstruálásához. Ez egy régi képarchívumnak migrációs lehetőséget ad anélkül, hogy egy újabb minőségromlást szenvedne el. Tesztelje a tárolási és szállítási kompromisszumokat. Ha inkább elolvasná ezt, mint hallaná tőlem, a diff minden reggel megérkezik a postaládájába, ingyenesen a the daily diff dot dev címen, link lent.

Miért telepíteném a dekódert és tesztelném a migrációt?

4:58 Tehát a mai ítélet, SZÁLLÍTÁSRA KÉSZ. Én telepíteném a kiegészítő dekódert, mert a böngészőtámogatás valós választási lehetőséget ad a fejlesztőknek, és tesztelném a migrációt a saját képeinken. Iratkozz fel, nyomd meg a harangot, és mondd el kommentben, ha másképp bélyegezted volna meg. És ez a mai diff. Niko vagyok az Axrisitől. Összevonás felelősségteljesen.

Források

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