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

Published: 2026-10-07

A Google bejelentette a JPEG XL dekódolását a Chrome 155-től, miután korábbi kísérletét eltávolították. Ez az október 7-i kiadás a fejlesztői visszajelzéseket, az új Rust dekódert, a versengő tömörítési állításokat és a telepítési tartalékokat vizsgálja, majd az OpenAI újonnan publikált matematikai bizonyítási műtermékeit és egy ESP32-C3 DNS "sinkhole" hash-in-flash tervezését tekinti át.

Canonical: https://thedailydiff.dev/hu/video/chrome-jpeg-xl-comeback/

## 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.

## Fejezetek

- 0:00 Miért hozza vissza a Chrome a JPEG XL-t?
- 0:33 Miért kapott még egy esélyt az elutasított formátum?
- 1:01 Mi változott a dekóderben?
- 1:47 A kisebb fájlok jobbak, mint az AVIF?
- 2:56 Mit is publikált valójában az OpenAI?
- 4:03 Hogyan blokkol tartományokat egy két dolláros alaplap?
- 4:38 Csatlakozhatnak a meglévő JPEG-jei a visszatéréshez?
- 4:58 Miért telepíteném a dekódert és tesztelném a migrációt?

## 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

- [Shipping JPEG XL in Chrome](https://developer.chrome.com/blog/jpeg-xl-in-chrome) — Chrome for Developers
- [JPEG XL prototype and November 2022 removal discussion](https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k) — Chromium Blink developers
- [Contemporaneous JPEG XL deprecation commentary](https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats) — Free Software Foundation
- [The case against JPEG XL — competing-encoder benchmark](https://giannirosato.com/blog/post/case-against-jxl/) — Gianni Rosato
- [JPEG XL FAQ and reversible JPEG transcoding](https://jpegxl.info/resources/faqs.html) — JPEG XL community
- [HTML picture element and fallback selection](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture) — MDN Web Docs
- [Progressive loading demo](https://jpegxl.info/resources/progressive-loading-demo.html) — JPEG XL community
- [Distance versus effort visualizer](https://jpegxl.info/resources/distance-vs-effort-visualizer.html) — JPEG XL community
- [Sharing AI progress in mathematics](https://openai.com/index/sharing-ai-progress-in-mathematics/) — OpenAI
- [Mathematical manuscripts and proof artifacts](https://github.com/openai/math) — OpenAI on GitHub
- [Lean formalization library build notes](https://github.com/openai/math/blob/main/lean/README.md) — OpenAI on GitHub
- [ESP32-C3 hash-in-flash DNS ad blocker](https://github.com/M-Abozaid/esp32-c3-adblock) — M-Abozaid on GitHub