Názory k článku
Google řekl, co je potřeba pro navrácení podpory JPEG XL do Chrome
-
Filip JirsákStříbrný podporovatelNo, vlastně je. Přesně takhle to s Internet Explorerem bylo – nepodporoval spoustu standardů, které ostatní podporovali; ale za to měl pár svých funkcí, které měly stejný cíl, jako některý standard, ale používaly se jinak.
-
a za druhé řečnická otázka: je na tom Google tak špatně, aby kromě miliónu aspektů v Chromiu nemohl sám podporovat i JPEG XL a nečekat, najde-li se nějaký Samaritán?
To jim imho poradil pravnik at maji paky na to prokazat, ze Chrome NENI produkt googlu, ale verejny OSS - tudiz neni jim to pak potreba zakazovat kvuli monopolnimu postaveni.
-
Ten formát se narodil už mrtvý. JPEG XL řeší problémy, které tu již 20 let nejsou a přidává další problémy s kompatibilitou/podporou. Načítání webových stránek už dávno nezdržuje velikost obrázku a postupné vykreslování už lovím jen ze vzpomínek, takže úžasná feature s ukládáním od středu je jen snake oil.
-
Postupné vykreslování se dnes děje v podstatě v každém prohlížeči. A jak moc to "nezdržuje" si můžete vyzkoušet na každém pomalejším nebo méně kvalitním připojení v praxi. Začít můžete třeba ve vlacích ale je jich spoustu včetně 4G na kdejaké na vsi. Máte tu paměť atokonto poněkud selektivní.
Nemluvě teda o tom, že já ho třeba v bezestrátové podobě používám pro archivaci. Najednou nejsou dvěstěmegová PNG dvěstěmegová ale třeba jen osmdesátimegová. Mimochodem zajímat jsem se o něj začal právě proto, že ho Google začal odmítat. Udělal mu slušnou reklamu.
A mimochodem: JPEG XL se narodil mrtvý ale asi desetkrát pomalejší AVIF prosazovaný Googlem se narodil živý? Nebo o čem to mluvíte? Implementoval jste někdy jakýkoliv generátor obrázků? Tam, kde na JPEG/JPEG XL potřebujete malou VPS potřebujete na AVIF několik silných serverů. Asi vás to překvapí, ale obrázky se nejen dekódují ale také enkódují.
-
Tak ještě jednou. Linka má limit 1 obrázek za sekundu mám 10 obrázků na stránce. Nemám progresivní decoding a stahují všech 10 obrázků paralelně. Za jak dlouho bude stránka načtená? A teď přidáme ještě, že důležitý pro tebe bude zrovna ten první obrázek? Kdy se ti takový obrázek zobrazí, když to bude paralelně a kdy když to bude za sebou nebo progresivně?
-
Nevím, jestli jsi někdy programoval weby, ale technická odpověd je velice jednoduchá: stránka funguje po onDomReady (a v tu dobu se aplikují rozšíření ve webovém prohlířeči):
https://stackoverflow.com/questions/26985800/what-is-the-difference-between-onload-ondomready-no-wrap-in-head-and-no-w#answer-26986242 -
Filip JirsákStříbrný podporovatel
Autor stránky může dát prohlížeči nápovědu, které obrázky jsou důležité a které méně. Prohlížeč sám to také dokáže odhadnout – třeba obrázky, které jsou až pod zlomem stránky (nejsou aktuálně vidět), jsou méně důležité a může je stáhnout později.
Když se pak obrázky stejné důležitosti stahují paralelně a mají progresivní dekódování, budou se ty obrázky objevovat jakoby najednou, budou rozmazané a postupně se budou zaostřovat. Když nemají progresivní dekódování, budou se také zobrazovta obrázky najednou, ale každý obrázek se bude zobrazovat shora dolů – což je ve většině případů k ničemu.
Takže má smysl u větších obrázků (kde se očekává delší stahování) použít progresivní dekódování vždy.
-
Jasně že to autor té stránky může říct, já chtěl jenom poukázat jaká je blbost tvrdit, že to řeší paralelní stahování. Protože v případě špatného připojení to neřeší nebo to ještě zhoršuje, protože místo aby měl aspoň část tak nemá nic. Mě už přijde, že lidé už vůbec nepřemýšlí, že připojení může být pomalé.
26. 11. 2025, 18:20 editováno autorem komentáře
-
Pokud máš hodně pomalý internet, tak použíješ např Operu s tím akceleračním módem, kdy to jde komprimovaně přes její servery. Komprimuje HTML, JS a rekóduje obrázky, kvalita nastavitelná. Prohlížeč obecně pozná, co je hlavní, např. co je v prostředním sloupci, elementu content či divu s podobným id. Plus samozřejmě co je vidět a na co je nutné odskrolovat. Taky co je na 3rd party serverech., pokud nejde o CDN k tomuto webu (např. web stahuje jQuery z CDN). Taky jde nastavit počet paralelních spojení na server. Např. u throttlovaných free mobilních dat po FUPu může být větší problém latence requestů než rychlost samotná. Myslím, že ten akcelerační mód v Opeře automaticky sníží počet paralelních requestů. Nevím, jestli něco neslučuje. Autoři webu mohou použít techniky jako obrázkový atlas (např. opakované UI prvky na stránce).
26. 11. 2025, 18:26 editováno autorem komentáře
-
Tak určitě bych použil nějaký akcelerační mód od třetí strany, to je opravdu skvělé řešení. Nic z toho co jsi napsal ale neřeší, že když paralelně neco stahuješ dva stejně velké obrázky, se stejnou prioritou, a máš kapacitu linky na jeden, tak je prostě jedno jestli to stahuješ paralelně nebo sériově, ten čas bude stejný. To co popisuješ je vlastně to samé pro HTML renderování jako progresivní dekódování u obrázků.
-
Filip JirsákStříbrný podporovatel
Protože v případě špatného připojení to neřeší nebo to ještě zhoršuje, protože místo aby měl aspoň část tak nemá nic.
Mně teda přijde lepší mít alespoň rozmazané obrázky, už když jsou hodně rozmazané, dá se podle nich orientovat. Než mít načtený kousek jednoho obrázku, v perfektní kvalitě – a pokud možno obrázku, který mne na té stránce vůbec nezajímá. -
Mám 1Gbps... Webtoons.com trebárs mi poriadne webtoon ani nenačíta, lebo načítať 80 panelov (obrázkov) je pre server riadna malina. A to používajú image/jpeg, kde je to cez 100 requestov a 15 MB resources vo viewery. A to stačí že majú server v Japonsku a ping je teda 400ms pretože nemajú vlastnú optimalizovanú páternú sieť. Používajú formát image/jpeg ťahané z pstatic.net. Packet loss na niektorých nodoch po ceste hrozný najmä keď si pozrieť mtr, krásne vidíš ae-14.r33.tokyjp05.jp.bb.gin.ntt odpovedá náhodne, 70% packet loss bežná vec. Vo viewery často vidím len "alt="image"" s ikonkou rozbitého obrázku.
To len taký príklad. O takých galériách už radšej ani nehovorím.
JPEG XL má veľký zmysel.
I keď samozrejme toto je aj issue že je krátky poll time a keep alive, ako aj to že to nemá retry mechanizmus (ten by im ale server zaťažil ešte viac, takže je otázka či nedáva zmysel teda optimalizovať aj formát). Waiting for server response 13.43 sekundy u Webtoons.com no to je úžas.
26. 11. 2025, 22:18 editováno autorem komentáře
-
Já dřív pro čtení stahoval mangy, a na to aplikace jsou, včetně toho delšího timeoutu a opakování. Dnes s neomezenými mobilními daty za pár korun čtu přímo online. Nevím, jestli je něco takového i pro webtoons - komixy typu "dlouhá nudle" určené pro skrolování na mobilu. Takové nečtu, protože obsahově je to pro modernější publikum (napsat mladší by bylo nepřesné, protože tam jsou i dospělá témata).
-
Na AVIF jsou hw kodeky. Na JXL je prt. To je možná důvod, proč ho preferují. Aby mobily déle vydržely.
O tom progresivním vykreslování jsem před časem četl, že ho ta implementace v chromiu neměla, čímž trpělo UX. Buď by se čekalo na načtení celého obrázku, nebo by se ten dekodér s každou další dávkou dat musel spouštět opakovaně od začátku. -
HW kodeky jsou tu protože "softwarově" je to moc náročné a jenom pokud se formát používá opravdu hodně, tak se vyplatí dělat HW kodek. Ale zrovna si nemyslím, že by tohle měla být přednost u grafiky. AVIF nebyl vymyšlený kvůli HW kodekům, je to jenom část z AV1, proto má taky dost nevýhod a hodí se jenom tam kde bylo AV1 zamýšleno (např. lossless).
-
Jsou. Ale ukažte mi, kde se při enkódování používají. Na většině konfigurací někde v AWS nebo Azure si budete moci tak leda trhnout nohou. A podpora pro hardwarové enkódování statických obrázků je také slabá.
Takže tu řešíme ledatak dekódování u klienta na mobilních platformách, jenomže tam to už dost dlouho problém fakt není. Jestli se něco narodilo mrtvé, je to AVIF.
-
I pro servery existuje podpora HW kodeků. Některé např používají Intel CPU s integrovanou grafikou pro zpracování obrázků a videa. Samozřejmě je jasné, že většina serverů v cloudu je čistě CPU, ale zas jsou levné, takže nevadí "plýtvání výkonem".
Dekódování u klienta problém na mobilech není, ale nechceš čekat sekundu pro uložení každé vyfocené fotky. To nevadí jen lidem s levným mobilem, kteří vědí, že kvůli něčemu levný je a jim se nechtělo připlácet.
-
Ano, "plýtvání výkonem" by teoreticky "nevadilo" (teda ono vadí vždycky; vždycky to jsou peníze navíc a ty jsou tím dražší, čím jste menší) pokud by rozdíl byl 30 %. Jenomže on je tak 300 % a spíš bych řekl, že mnohem víc. Jako chápu, že Googlu to je s jim dostupným výkonem jedno. Ale není ani náhodou na světě jenom on.
A sekundu na uložení fotky čekat klidně budu. Mimochodem, to se tu fakt bavíme o sekundě při ukládání fotky? Přemýšlím, v jaké galaxii jsem se to ocitl.
-
V galaxii telefonů za 40 tisíc a tak tenkých, že baterka vydrží sotva den. A nikdo tě nenutí kódovat obrázky na serveru. Většinou jen kopíruješ bajty souborů na disku, v RAM, od/do klienta. Taky si můžeš zvolit jiný typ obrázků nebo část práce přenést na klienta (viděl jsem i WebAssembly na iPhone pro nepodporované formáty obrázků).
-
Ano, musím jenom umřít. To je objev! Jen to jaksi není argument naprosto pro nic. Právě proto, abych mohl kódovat obrázky na serveru což když ty obrázky generuju tak nějak jaksi, ehm, potřebuju, nezaplatil za to jak za bitcoinovou výpočetní farmu a neroztavil sousedící jaderný reaktor je to JPEG XL podstatně vhodnější. Výkonu je na těch smartphonech dnes už celkem přebytek.
Takže děkuji, jsme zpět tam, kde jsme byli.
26. 11. 2025, 14:23 editováno autorem komentáře
-
I v dnešní době je to, co jste popsal dvojitý rovnák na vohejbák kombinovaný s koronárním bypassem pro možnost pošrabat se levou rukou za pravým uchem. S takovýmhle "řešením" by vás hnal kdekdo. Ano, dnes už to možné je. Ale to je tak vše.
To, že je něco jakž takž možné ještě opravdu neznamená, že je to rozumné nebo nedejbože dokonce praktické či žadoucí a chtěné.
-
Děkuji za radu, Vývojem webových aplikací se zabývám jenom asi pouhých patnáct let a vůbec to neřeším denně, ani trochu. Prostě to, co navrhujete je z mnoha důvodů řešení, které je možné ale na většině projektů není ani praktické ani rozumné a v některých ohledech nedává smysl vůbec. To prostě není argument.
Navíc jste, mám dojem, ani nepochopil, že enkódování do AVIFu je řádově náročnější než do JPEG XL s effort 1 až 8. Takže ano, s tím, že potřebuji místo malé VPS tři silné servery by mě skutečně hnali. Proto to taky řešíme.
26. 11. 2025, 16:48 editováno autorem komentáře
-
Chápete point celé téhle diskuze nebo jen plácáte? Pointa je, že AVIF není alternativa, vy seniore. Jste úplně mimo. AVIF je prostě bez hardwarové akcelerace na obou stranách -- jak v enkodéru, kde není skoro nikde tak v dekodéru, kde je jen sem tam a to tak maximálně na mobilních zařízeních -- v praxi úplný úlet.
26. 11. 2025, 16:54 editováno autorem komentáře
-
Takže ano, nechápete point celé téhle diskuze. Nemluvě o tom, že představu o běžném webovém vývoji máte evidentně taky nulovou. Ano, představte si, že obrázky se rutinně generují na serverech a představte si, že na většině projektů nemáte kvůli generování obrázků k dispozici dedikovanou serverovou farmu ani hardwarovou akceleraci. Vy hrubý výkone.
-
L.Stříbrný podporovatel
Ne, že by ty problémy co JPEG XL řeší neexistovaly vůbec, ale jsou to corner casy. Proto tipuju, že ani podpora v Chrome k nějakému většimu rozšíření JPEG XL nepřispěje, jako k němu nepřispěla za tu dobu co tam už jednou byla. A taky tipuju, že ani to nepřiměje jeho proponenty k přehodnocení názoru na jeho úžasnost a najdou si nějakého jiného zlotřilce, který jeho rozšíření brání.
26. 11. 2025, 10:40 editováno autorem komentáře
-
L.Stříbrný podporovatel
Přesně.
Jinak (ne)rozšíření standardu není až tak zjevné, protože jestli obrázek co prohížeč zobrazuje na stránce je JPG, PNG, AVIF, WEBP nebo JPEG XL se na první pohled (většínou) nepozná. Ale alespoň s WEBP jsem se už párkrát potkal (zjistil jsem, když jsem ubrázek uložil).
To jste pochopl špatně. Já naopak říkám, že to ideologický boj není. Ano, je to úlet, přesto tu názor, že se JPEG XL nerozšířil protože tomu Google schválně brání jeho nepodporou v diskusích objevoval dost často. Ostatně, zmiňuje to i třeba v téhle diskusi Saljack ve svém příspěvku z pondělka 17:13.
-
OK. Znělo to tak. Tak pardon. On ani ten WebP není moc potřeba. A ten existuje o deset let déle. Přitom nějak zásadně rozšířený na to, jak dlouho je k dispozici taky není a ještě ho Google aktivně protlačoval víc než AVIF.
S Chrome a JPEG XL je problém ten, že pokud nebude podpora v prohlížečích, kde je to ale velice praktický formát, bude vždy známý jen pár nadšencům nebo profesionálům a lidem, co archivují velká obrazová data. Tak to možná myslel.
-
Tak řeší 3 hlavní problémy 1. lepší ztrátová komprese než JPEG 2. Mnohem lepší bezztrátová komprese 3. bezztrátová komprese JPEG. Jestli tohle jsou corner cases, tak fakt nevím co víc chtít. Už jenom to, že si bezztrátově mužů zmenšit své staré fotky v JPEG aspoň o 10% je pro mě dostatečný důvod.
JPEG XL nebyl součástí Chrome. Byl vždy jen v beta (nebo canary) a za flagem.
-
Teoreticky by to bolo fajn.
Prakticky si ukusuju z dalsej vrstvy abstrakcie (ako ked filesystem zacne riesit volume management) a nie som si isty, ci su ten problem pripraveni riesit (pretoze globalne je to este nedoriesene).
Totiz tak ako v SDR (referencny jas 100 nit) tie iste pixely mozu vyzerat inac v zavislosti od gamma krivky, v HDR mozu tie iste pixely vyzerat inac v zavislosti od transferovej krivky. Hodnota jasu bieleho bodu je len jeden z parametrov; percepciu riesi transferova krivka. Enkoder teda musi poznat vsetky zname a vediet, ktoru pouziva zdroj a tomu prisposobit postup kodovania.
Druhy problem je, ze uz dnes existuju farebne priestory, kde hodnota pixelu moze byt > 1.0, takze potom nastupuje bud tone mapping alebo na hulvata to orezat, v oboch pripadoch to znamena stratu dat.
Takze enkodery, ktore toto neriesia a nechaju na dalsiu vrstvu aktualne robia spravnu vec, aj ked mozu stratit nejaku efektivitu.
-
Gamma křivku a přenosové funkce potřebujete znát, když to reprezentujete v generické RGB formě. RGB bez barevného profilu barvu opravdu nedefinuje.
Ale JPEG-XL podle popisu reprezentuje barvu jako hodnoty v konkrétním barevném prostoru XYB, takže víte s absolutní jistotou, co je to za přesnou barvu.
https://facelessuser.github.io/coloraide/colors/xyb/
Znamená to ovšem, že převod do JXL musí vědět jaký je barevný prostor zdrojových dat, aby to spočítal správně.
-
Byva zazitym zvykem, ze neoznaceny RGB prostor je sRGB - jak primaries, tak transfer curve.
Az v pripade ze se jedna o cokoliv jineho (typicky z obdobi rustu digitalni fotografie), se musi prostor identifikovat.
A pak jeste tady mame RAW RGB z kamer a snimacu, ale to se vi ze to ma sve specifika per model a nejedna se o standardni prostor.
-
Neni to prvni ani posledni kodek, ktery pouziva "skrytou" krivku pro translaci mezi I/O rozhranim a internim kompresorem. Ostatne krivka je nekdy lossy komprese, jindy zase nutna kompenzace protoze sumovy profil jadra kodeku je jiny na malych a velkych cislech.
Samozrejme je vhodne, pokud kodek umi akceptovat override teto interni servisni krivky (zatim znam jen jeden takovej), a je mozne proces komprese/dekomprese trocha optimalizovat pro dany use case ci zarizeni/snimac/format.
