Vlákno názorů k článku
Google zveřejnil důvod pro zrušení JPEG XL od ???????????? - No tak lidi přestanou používat Chrome, když se...

No vsak rikam, ze dneska je ta situace o dost jina...

Nemyslím, že je dostatečně jiná, aby to změnilo výsledek. Troufám si tvrdit, že dokud se zásadně nezmění zastoupení prohlížečů, formát, který vývojáři chrome odsoudili jako neperspektivní, žádné významnější rozšíření očekávat nemůže.

Staré IE uměly alpha kanál u PNG přes DirectX filtry (např.). Ano, musel jsi mít kus CSS zvlášť pro IE, ale to tehdy bylo běžné (zas jiný kus CSS pro Safari, jiný pro Operu, ...).

EDIT: Já na firemním webu zesvětlal pro IE pomalý webshop po odeslání formu pomocí GIFu, kde jsem střídal bílý a průhledný pixel (pro pořádné prohlížeče bylo PNG s 50% průhledným bílým pixelem).

1. 11. 2022, 13:19 editováno autorem komentáře

Protože kdyby to nenastavoval, ale dělal to sám prohlížeč, bude to ještě daleko horší. To, zda uživatel používá LTE/3G/EDGE vůbec nesouvisí s FUP. Nesouvisí to ani s rychlostí, na přetíženém LTE se to bude stahovat déle, než na EDGE, kde budete sám. Nahrát na server velký soubor a pak trvale poskytovat jen jeho část také nedává smysl.

To, že je na pomalém spojení lepší progresivní vykreslování, o tom není sporu. Jenže všichni se snaží spíš o zrychlení těch pomalých připojení – ono nemá moc smysl řešit, že místo 1 MB stačí nahrát 100 kB, když uživatel chce vidět video, které má desítky MB.

Ta profilová fotka je sice hezký příklad, ale to by bylo potřeba implementovat do prohlížeče ještě logiku, aby při zmenšení obrázku stahoval jenom jeho část. A to už jsme u toho, že ten kód musí někdo napsat a udržovat. A použitelné by to bylo asi jen u těch profilových fotek. Stojí to za to?

Nic proti, ale LTE je třeba u nás přetížená naprosto pravidelně, rychlost klesá cca na desetinu ale rozhodně nelze říci, že by byla pomalejší i než EDGE v plné rychlosti. To je zase demagogie. Ano, když bude cokoliv dostatečně přetížené, bude to pomalejší než cokoliv jiného. To je skutečně úvaha za tři body.

Ovšem získal jsem dalších šest bonusových bodů za to, že místní troll martinpoljak měl potřebu na to reagovat, aby nakonec potvrdil, že je to tak, jak jsem napsal.

Tak další příklad. V Chromu na Android byla možnost aby veškerý provoz byl "komprimován" Googlem a tím šetřil FUP. Proč by tam takový mód nemohl stále být s tím, že bude stahovat jenom část obrázků.
Nahrát na server velký soubor a pak trvale poskytovat jen jeho část také nedává smysl.
Tohle právě smysl dává. Můžete snadno poskytovat např. náhledy, šetříte traffic a úložiště (protože máte jenom jeden soubor).

Jenže všichni se snaží spíš o zrychlení těch pomalých připojení – ono nemá moc smysl řešit, že místo 1 MB stačí nahrát 100 kB, když uživatel chce vidět video, které má desítky MB.
Na tohle můžu napsat jenom: "Halíře dělají talíře". Jasně všude se to nevyužije, ale jsou oblasti kde ta úspora má smysl. Dokážu si to např. představit u leteckých map, poskytovatelů fotek, komixů atp. Internet není jenom o videu.

Ta profilová fotka je sice hezký příklad, ale to by bylo potřeba implementovat do prohlížeče ještě logiku, aby při zmenšení obrázku stahoval jenom jeho část. A to už jsme u toho, že ten kód musí někdo napsat a udržovat. A použitelné by to bylo asi jen u těch profilových fotek. Stojí to za to?
Nemusel by to řešit prohlížeč, ale klidně by to mohl dělat server, je to jednoduchá operace není potřeba nic enkódovat. Nebo si dokážu představit nový atribut u img např. quality
<img src="profilove_fo­to.jxl" quality="10%" />
Takže ano stojí to za to. Těch možností, jak využít progresivní dekódování je hodně. V podstatě jakýkoliv náhled.

Proč by tam takový mód nemohl stále být s tím, že bude stahovat jenom část obrázků.
Protože ta googlovská komprese byla nastavená tak, aby nebyla viditelná. Byla tedy založená především na tom, že na spoustě serverů nebyla komprese nastavená tak dobře, jak by mohla být. Těžko věřit, že by tam najednou byl „tak akorát“ špatně udělaný JPEG XL.

A pak se samozřejmě nabízí otázka, proč to v Chrome na Androidu bylo a už to tam není.

Tohle právě smysl dává. Můžete snadno poskytovat např. náhledy, šetříte traffic a úložiště (protože máte jenom jeden soubor).
Pokud k těm náhledům budete chtít zobrazovat i originální fotky, nebudete trvale poskytovat jen jeho část, ale budete poskytovat někdy jen část souboru a někdy celý soubor. Ale hlavně – kvalitní náhledy se nevytvářejí tak, že by se jen vzal originál a odstranily z něj detaily. Náhled se doostřuje, případně ořezává.

Jasně všude se to nevyužije, ale jsou oblasti kde ta úspora má smysl.
Velmi malý počet uživatelů krát malý počet oblastí nevypadá jako něco hodně užívaného.

Nemusel by to řešit prohlížeč, ale klidně by to mohl dělat server, je to jednoduchá operace není potřeba nic enkódovat.
Ovšem to klidně může dělat server i dnes a nepotřebuje k tomu JPEG XL.

Těch možností, jak využít progresivní dekódování je hodně.
Progresivní dekódování má i obyčejný JPEG.

V podstatě jakýkoliv náhled.
Nikoli, viz výše.

Protože ta googlovská komprese byla nastavená tak, aby nebyla viditelná. Byla tedy založená především na tom, že na spoustě serverů nebyla komprese nastavená tak dobře, jak by mohla být. Těžko věřit, že by tam najednou byl „tak akorát“ špatně udělaný JPEG XL.
Tohle nemá žádný argument. Jako, že Google jednou dokáže udělat kompresi u JPEG aby nebyla viditelná, ale pokud by to bylo v JPEG XL, tak to je problém.

Pokud k těm náhledům budete chtít zobrazovat i originální fotky, nebudete trvale poskytovat jen jeho část, ale budete poskytovat někdy jen část souboru a někdy celý soubor.
Bingo proto se to jmenuje náhled.

Velmi malý počet uživatelů krát malý počet oblastí nevypadá jako něco hodně užívaného.
Skoro každý člověk má nějaké JPEG, fotky takže ano počet uživatelů je obrovský a oblast použití obří.

Ovšem to klidně může dělat server i dnes a nepotřebuje k tomu JPEG XL.

Nemůže. Musel by to enkódovat. Zkuste tohle udělat u AVIF a odstrouháte.
Progresivní dekódování má i obyčejný JPEG.
Tohle je trochu pokročilejší progresivní dekódování než má JPEG. Stačí se podívat na některé příklady. Už FLIF mě s tím fascinoval.

Jako, že Google jednou dokáže udělat kompresi u JPEG aby nebyla viditelná, ale pokud by to bylo v JPEG XL, tak to je problém.
Myslel jsem, ž epíšete o obecném použití JPEG XL kdekoli na webu. Pokud jste ale psal o kompresi mezi Google proxy a Google prohlížečem na Google operačním systému, tam mohou používat jaký formát chtějí a nemusí ho podporovat nikdo jiný.

Skoro každý člověk má nějaké JPEG, fotky takže ano počet uživatelů je obrovský a oblast použití obří.
Jenže vy jste psal o malém počtu uživatelů, kteří mají pomalé připojení a možná by chtěli dostávat obrázky v nižší kvalitě, než ostatní, o speciálních případech použití, např. letecké snímky.

Nemůže. Musel by to enkódovat.
Takže může. To enkódování evidentně není takový problém.

Tohle je trochu pokročilejší progresivní dekódování než má JPEG.
Ano, je. Takže by to nebylo hodně možností, jak využít progresivní dekódování, ale hodně možností, jak využít pokročilejší progresivní dekódování. Akorát se pak vkrádá otázka, proč se nepoužívá alespoň to méně pokročilé progresivní dekódování. A proč se nepoužívá ani to pokročilé progresivní dekódování, když je v tuto chvíli v Chrome dostupné. Přitom by to nebylo nic těžkého, na straně serveru není potřeba žádná podpora, stačilo by obrázky vyexportovat v novém formátu.

Myslel jsem, ž epíšete o obecném použití JPEG XL kdekoli na webu. Pokud jste ale psal o kompresi mezi Google proxy a Google prohlížečem na Google operačním systému, tam mohou používat jaký formát chtějí a nemusí ho podporovat nikdo jiný.
Zajímavé jak se vám tady hodí obecné využití a hned následně píšete o úzké skupině uživatelů s pomalým připojením.
Jenže vy jste psal o malém počtu uživatelů, kteří mají pomalé připojení a možná by chtěli dostávat obrázky v nižší kvalitě, než ostatní, o speciálních případech použití, např. letecké snímky.
Ne nepsal to jenom vy jste zaměřil jenom na určitou část jako vždy.

Takže může. To enkódování evidentně není takový problém.
Tohle je slabé i na vás. Navíc je to nesmysl a totální nepochopení výhody JPEG XL. Vlastně k čemu je JPEG vždyť můžeme přenášet vše v RAW. A ano i kráva může létat pokud letí v letadle.

Ano, je. Takže by to nebylo hodně možností, jak využít progresivní dekódování, ale hodně možností, jak využít pokročilejší progresivní dekódování. Akorát se pak vkrádá otázka, proč se nepoužívá alespoň to méně pokročilé progresivní dekódování. A proč se nepoužívá ani to pokročilé progresivní dekódování, když je v tuto chvíli v Chrome dostupné. Přitom by to nebylo nic těžkého, na straně serveru není potřeba žádná podpora, stačilo by obrázky vyexportovat v novém formátu.
Srovnejte si progresivní dekódování u JPEG a JPEG XL do té doby se nemáme vůbec o čem na tohle téma bavit.

Zajímavé jak se vám tady hodí obecné využití a hned následně píšete o úzké skupině uživatelů s pomalým připojením.
O obecném použití píšete vy. Ale jako příklad jste uvedl jen pomalé připojení a speciální typy obrázků jako letecké snímky.

Vlastně k čemu je JPEG vždyť můžeme přenášet vše v RAW.
JPEG je řádově menší než RAW. JPEG XL není řádově menší než JPEG.

Pořád jste neuvedl nějaký důvod, proč už se tedy JPEG XL na webu dávno nepoužívá, když je to takové terno.

O obecném použití píšete vy. Ale jako příklad jste uvedl jen pomalé připojení a speciální typy obrázků jako letecké snímky.
Ano píšu o obecném použití ale všechny tyhle příklady se týkali progresivního dekódování.
JPEG je řádově menší než RAW. JPEG XL není řádově menší než JPEG.
Né vždy řádově, ale výrazně menší než JPEG určitě. Ale ano může být i řádově menší než JPEG. Záleží na porovnání.

Pořád jste neuvedl nějaký důvod, proč už se tedy JPEG XL na webu dávno nepoužívá, když je to takové terno.
Děláte si srandu nebo vůbec nevíte o čem píšete nebo jste tak omezený? Standard je schválený celkem nedávno, tento rok. Referenční software je standardizované teprve v srpnu. Není podpora v prohlížečích na kterou se čeká/čekalo.
Pokud píšete takové nesmysly (ne že by mě to překvapilo, protože to není poprvé), tak se opravdu už nemáme o čem bavit.

Akorát se pak vkrádá otázka, proč se nepoužívá alespoň to méně pokročilé progresivní dekódování.

Ono se celkem běžně používalo... v době, kdy se obrázek (tehdy) běžné velikosti stahoval řádově sekundy. Jak se rostly přenosové rychlosti běžných připojení, význam klesal a dnes už na to asi všichni kašlou. Někdy před dvaceti lety jsem při exportu do JPEG ten checkbox ještě zaškrtával, dnes už v tom smysl nevidím.

Kolikrát za mnou přicházejí lidé z rodiny, že už se jim do telefonu nevejde a když se podíváte, tak je většinou telefon plný fotek zase v JPEG. Když jedete na dovolenou také víc asi fotíte než nahráváte videa.

Pokud se bavíme o fotkách ponechaných tak, jak vylezou z foťáku, tak potom už je rozdíl mezi JPEG, JPEG XL, AVIF, atd. úplně bezpředmětný. Taková fotka má několik MB (při dnešních absurdních rozlišeních senzorů spíš i víc), přičemž pro prezentaci na obrazovce počítače by bohatě stačilo 200-300 KB, na webu 100-200 KB, a vezmu-li v úvahu, že cílová skupina si to stejně bude prohlížet jen na smartphonu, tak spíš 50-100 KB. A to i při použití obyčejného "zastaralého" JPEG. Jestli mi z toho nějaký efektivnější formát srazí dalších 10-20 procent, nehraje roli, důvod, proč ty fotky zabírají tolik místa, je úplně jinde.

Což je IMHO důvod, proč se žádný z těch formátů neprosadil natolik, aby se v dohledné době dalo očekávat, že JPEG nahradí: JPEG je prostě pořád pro běžné použití dostatečně dobrý na to, aby výhody nových formátů nestačily přebít jeho všudypřítomnost a univerzální podporu. (Taky IMHO moc nepomáhá ani to, že těch kandidátů je vždycky několik.) Ostatně i ten GIF, který už měl dávno upadnout v zapomnění, je pořád běžně k vidění, a co mne děsí, dodnes se v něm běžně dělají animace, a to včetně animací z fotek/videí, nejen kreslené. Proti tomu je 10-20 procent úspory prkotina.

JPEG není dostatečně dobrý už patnáct let.

JPEG není dostatečně dobrý už patnáct let.

Pro kolik procent lidí? Jedno? Dvě? Většina ze zbytku nevidí rozdíl mezi fotkou ze smartphonu a ze zrcadlovky, ani když to bije do očí a ukážu jim kde; ze zbytku to většina sice pochopí, ale mávne nad tím rukou, že se v tom moc nimrám.

Ale hlavně se tu bavíme o použití na webu - a tam dostatečně dobrý je pořád a nejspíš ještě dlouho bude. Zkuste vyhlédnout ze své bubliny, většině lidí nevadí JPEG ani když je použitý na to, na co se absolutně nehodí, třeba na nascanovaný text.

Pro kolik procent lidí? Jedno? Dvě? Většina ze zbytku nevidí rozdíl mezi fotkou ze smartphonu a ze zrcadlovky, ani když to bije do očí a ukážu jim kde; ze zbytku to většina sice pochopí, ale mávne nad tím rukou, že se v tom moc nimrám.
Právě pro tyhle lidi by jiný formát byl lepší. Ušetří místo ve svém telefonu a najednou tam místo 10 000 fotek uloží třeba 50 000 fotek. To je dostatečná výhra pro všechny. Když jim to takhle prezentujete, tak pro ně budete hrdina a kouzelník.

Ale hlavně se tu bavíme o použití na webu - a tam dostatečně dobrý je pořád a nejspíš ještě dlouho bude. Zkuste vyhlédnout ze své bubliny, většině lidí nevadí JPEG ani když je použitý na to, na co se absolutně nehodí, třeba na nascanovaný text.
Ne právě kvůli webu je tu snaha s tím něco udělat a právě proto, že JPEG dostatečný není. Spousta firem investovalo nemalé prostředky, aby poskytovali alespoň dva druhy formátů grafiky JPEG pro zařízení která nic jiného neumí a WebP nebo v budoucnu AVIF nebo JPEG XL pro ostatní s podporou. Proč by to jinak dělali kdyby JPEG byl dostatečný a bavíme se o firmách které ukládají/poskytují neskutečná kvanta obrázků (ebay, aliexpress, google atp.)

Což je IMHO důvod, proč se žádný z těch formátů neprosadil natolik, aby se v dohledné době dalo očekávat, že JPEG nahradí: JPEG je prostě pořád pro běžné použití dostatečně dobrý na to, aby výhody nových formátů nestačily přebít jeho všudypřítomnost a univerzální podporu.
Ale o tom to právě je, pokud budu mít formát, z kterého jsem velmi snadno schopný poskytnout starý JPEG pro někoho, kdo ho ještě neumí zobrazit a navíc ušetřím místo, tak se takový formát, pokud mu nebude Google házet klacky pod nohy, prosadí. Ono nejde ani tak o těch 20%, ale o to, že s ostatními formáty musím ten samí obrázek ukládat 2x a nebo víckrát, kdybych chtěl podporovat JPEG, WebP a AVIF. Takže například kdybych měl JPEG který má 10 MB a WebP bude mít 2MB a AVIF 1MB, tak už to je to celkem 13MB oproti tomu kdybych to uložil jako JPEG XL tak budu mít jeden soubor co bude mít 8MB, takže ta úspora pro web je vlastně 20% z JPEG + velikost souborů v jiném formátu. Takže ona ta úspora klidně může být 40% (vycucal jsem si to z prstu) oproti nynějšímu stavu.
Navíc JPEG se pěkně blbě konvertuje do AVIF nebo WebP na mobilu. AVIF dává smysl jenom z HW akcelerací. WebP HW akceleraci nemá. JPEG XL je od začátku navržen tak, aby to ta konverze byla snadná.

Teď ten hlavní důvod proč nechci nic konvertovat do jiného loss formátu: Co když za 20let nebude HW podpora pro AVIF standardem, protože to bude velmi zastaralí formát a budu muset (aby to někdo třeba zobrazil) fotky znovu konvertovat do AV3F (jasně je to jenom teoretické), pak už původní fotka bude 3x enkódovaná a to se mi prostě nelíbí. Když JPEG XL za 10 let umře stále budu mít možnost z něho sestavit původní JPEG a třeba ho opět konvertovat do JPEG XXXL a stále budu mít původní data. Takže konverzí do JPEG XL nic neriskuji a o nic nepřijdu.

AVIF určitě JPEG nenahradí a nevytlačí, jenom zakonzervuje současný stav, že se musí poskytovat JPEG a nový formát.

pokud mu nebude Google házet klacky pod nohy

Spousta lidí má představu, že společnosti jako IBM, Microsoft, Apple nebo Google mají nějaké zvrácené potěšení z toho, že lidem škodí. Ale tak to není, pokud Google zruší nějaký projekt, nedělá to naschvál, aby naštval jeho uživatele, ale typicky proto, že usoudí, že nepřináší to, co od něj očekával, nebo rovnou, že se ekonomicky nevyplatí. Stejně tak když Google odstraní podporu formátu z chrome, není to proto, že by "mu chtěl házet klacky pod nohy", ale proto, že si vyhodnotili, že formát není dost rozšířený ani perspektivní na to, aby jim stálo za to ho podporovat. Že tím zároveň přispějí k tomu, aby to tak opravdu bylo, je už jen takový vedlejší efekt.

Normálně bych s tím souhlasil, ale to prohlášení neobsahuje jediný objektivní důvod, proč to by to měli udělat (kromě toho, že by to nemělo být experimentální navždy). Formát pro web se nemůže rozšířit bez podpory ve většině webových prohlížečích. Takže mě to opravdu přijde jako, že se chtěli JPEG XL zbavit ve prospěch WebP a AVIF.

to prohlášení neobsahuje jediný objektivní důvod, proč to by to měli udělat (kromě toho, že by to nemělo být experimentální navždy)

To mi zrovna připadá jako docela dobrý důvod: zkusili to, po čase vyhodnotili, že to nikam nevede, tak to odpískali. Dává mi to víc smyslu než když je něco označené jako experimentální ještě po dvaceti letech.

To mi zrovna připadá jako docela dobrý důvod: zkusili to, po čase vyhodnotili, že to nikam nevede, tak to odpískali. Dává mi to víc smyslu než když je něco označené jako experimentální ještě po dvaceti letech.
Tohle nedává smysl. Co nikam nevede? Aby to nikam nevedlo musí být objektivní důvody a ty teda nebyly prezentované. Všichni přidávají podporu JPEG XL jak na běžící páse v posledních měsících jenom Chromium jí odebírá. Nikdo by neřekl ani popel, kdyby přišli s nějakým rozumným odůvodněním. Napsat, že o to není zájem, když to skoro nikdo nemůže používat kvůli tomu, že je to stále v chromium jako experimentální funkce, je opravdu paradox. To, že JPEG XL nepřináší dostatek výhod, je obyčejná lež. Navíc když vidíme co všechno za nesmysly se do chromium v poslední době dostává, tak opravdu nevidím jediný objektivní důvod proč by měla být podpora pro JPEG XL z chromium, místo povolení pro všechny, odstraněna.

Aby to nikam nevedlo musí být objektivní důvody a ty teda nebyly prezentované.
To, že vám se ty důvody nelíbí, neznamená, že neexistují.

Všichni přidávají podporu JPEG XL jak na běžící páse v posledních měsících
Kdo všichni?

To, že JPEG XL nepřináší dostatek výhod, je obyčejná lež.
No, vy jste jako výhody jmenoval samé okrajové případy.

To, že vám se ty důvody nelíbí, neznamená, že neexistují.
Rozumíte psanému textu? Já napíšu, že nebyly prezentovány a vy mi vyčtete, že se mi ty neznámé důvody nelíbí. Opravdu?

Kdo všichni?
Qt, KDE, Krita, Gimp, digiKam, Darktable, XnView. To mi přijde jako dostatečný vzorek, že o JPEG XL je zájem.

No, vy jste jako výhody jmenoval samé okrajové případy.
Výborná kompatibilita s JPEG (snadná transformace tam i zpět), už jenom tohle vyvrací, že je to okrajový případ. Progresivní dekódování. Jeden z nejlepších kompresních poměrů. Snadná enkódování a dekódování, které je nenáročné na zdroje. Možnost paralelizace. Lossless a lossy. Univerzální formát. Nevím o žádném jiném grafickém formátu, který by všechny tyhle věci řešil a podporoval. WebP to určitě není a AVIF je hodně náročný.

Rozumíte psanému textu? Já napíšu, že nebyly prezentovány a vy mi vyčtete, že se mi ty neznámé důvody nelíbí. Opravdu?
Ano, opravdu. Protože ty důvody prezentovány byly – najdete je třeba i ve zprávičce, pod kterou diskutujete.

To mi přijde jako dostatečný vzorek, že o JPEG XL je zájem.
Já tam nevidím ani jediný program, který by měl něco společného s webovými technologiemi. Nijak jsem nerozporoval, že o něj někde zájem je. Ale nevidím ten zájem v ekosystému webu.

Výborná kompatibilita s JPEG (snadná transformace tam i zpět), už jenom tohle vyvrací, že je to okrajový případ.
Když vytvoříte formát, který vznikne z JPEG tím, že všechny bity otočíte, bude pro něj také snadná transformace tam i zpět. Ale něco mi říká, že se neuchytí.

Progresivní dekódování.
Tohle je právě okrajový případ. Prakticky to skoro nikdo nevyužije.

Navíc ten vámi popisovaný příklad by načítání stránek ve skutečnosti zpomaloval – a to všem, i když by nepoužívali JPEG XL. Protože prohlížeč by při každém požadavku na obrázek musel požadovat jenom hlavičku, tu byl dostal, zjistil by, že nejde o obrázek typu JPEG XL a teprve pak by si mohl říci o zbytek souboru. Takže by se přidal jeden roundtrip. I kdyby to byl JPEG XL, pořád by tam byl roundtrip, během kterého by se jinak ten obrázek možná stáhl celý.

Snadná enkódování
Další okrajový případ. Dneska je přístup přesně opačný – ničemu nevadí, když je enkódování náročné, protože se dělá jednou a pak se nahraje na servery, odkud se ten soubor bude poskytovat tisíckrát nebo milionkrát.

Nevím o žádném jiném grafickém formátu, který by všechny tyhle věci řešil a podporoval.
Jestli to nebude tím, že podporu všech těchhle věcí nikdo nepotřebuje.

Protože prohlížeč by při každém požadavku na obrázek musel požadovat jenom hlavičku, tu byl dostal, zjistil by, že nejde o obrázek typu JPEG XL a teprve pak by si mohl říci o zbytek souboru.

Musel. Saljack chce využívat progresivní dekódování k tomu, aby se nestahoval celý soubor. Tj. prohlížeč by musel nejprve stáhnout jen hlavičku, aby měl informace o celém souboru a mohl se rozhodnout, kolik z toho souboru bude chtít. Ale hlavičku Range nelze podmínit mime typem způsobem „pošli mi tenhle soubor, a pokud to bude image/jxl, pošli jen prvních 10 kB, jinak pošli celý soubor“.

Prohlížeč může klidně poslat header JXL-QUALITY: 20% a server může vrátit jenom 20% souboru. Navíc ten mime type browser ví. To, že to akorát nedokážete domyslet neznamená, že to nejde.

Mimochodem, když už jsme u těch hlaviček, tak hlavička JPEG XL je řádově menší než u AVIF: JPEG XL: 12 bytes AVIF: 298 bytes

Prohlížeč může klidně poslat header JXL-QUALITY: 20% a server může vrátit jenom 20% souboru.
Takže z jednoduché změny, která server neovlivňuje vůbec nijak a v prohlížeči je to jenom jiný formát souboru, to najednou vyžaduje úpravu serveru a další úpravu prohlížeče.

Jinak tohle je právě největší problém JPEG XL. Aby bylo možné využívat všechny vámi uváděné výhody, je to mnohem větší zásah do všech částí webového ekosystému – nejen prohlížeč, ale i server a buildovací nástroje. A to všechno kvůli okrajovým případům.

Navíc ten mime type browser ví.
Teprve po té, co mu server začne soubor posílat a s tím pošle i typ souboru.

Mimochodem, když už jsme u těch hlaviček, tak hlavička JPEG XL je řádově menší než u AVIF: JPEG XL: 12 bytes AVIF: 298 bytes
Tenhle argument nemyslíte vážně, že ne?

Takže z jednoduché změny, která server neovlivňuje vůbec nijak a v prohlížeči je to jenom jiný formát souboru, to najednou vyžaduje úpravu serveru a další úpravu prohlížeče.

Jinak tohle je právě největší problém JPEG XL. Aby bylo možné využívat všechny vámi uváděné výhody, je to mnohem větší zásah do všech částí webového ekosystému – nejen prohlížeč, ale i server a buildovací nástroje. A to všechno kvůli okrajovým případům.
Opět vytrženo záměrně z kontextu. Pro podporu JPEG XL na úrovni již podporovaných formátů tohle potřeba není. Záměrně opět lžete a ohýbáte fakta. Pokud bychom chtěli tohle pokročilejší využití, tak to lze snadno doimplementovat, nikdo nechce aby bylo vše ihned, ale je super mít tuhle možnost.

Teprve po té, co mu server začne soubor posílat a s tím pošle i typ souboru.
Lež (navíc záměrná, protože již vám bylo dokázáno, že to to tak není)! Ví to již při přijmutí HTML (už asi po 3. ten samý kus HTML kódu, takže přestaňte lhát):

<picture>
<source srcSet="image.jxl" type="image/jxl" />
<source srcSet="image.avif" type="image/avif" />
<source srcSet="image.webp" type="image/webp" />
<img
width="1280" height="720" decoding="async" loading="lazy"
src="image.jpg" alt="hopefully an jxl image" />
</picture>

Přestaňte psát o něčem, čemu zřejmě vůbec nerozumíte.

Tenhle argument nemyslíte vážně, že ne?
Zcela myslím. Chcete znát výhody JPEG XL? Tohle je sice jenom malá výhoda, ale stále výhoda.

Opět vytrženo záměrně z kontextu. Pro podporu JPEG XL na úrovni již podporovaných formátů tohle potřeba není. Záměrně opět lžete a ohýbáte fakta. Pokud bychom chtěli tohle pokročilejší využití, tak to lze snadno doimplementovat, nikdo nechce aby bylo vše ihned, ale je super mít tuhle možnost.
Sice se v tom pokoušíte udělat guláš, ale neúspěšně. Když použijeme jen implementaci na úrovni jiných formátů v prohlížeči, získáme jedinou výhodu – cca o 20 % lepší kompresi oproti JPEG. Tím ale není JPEG XL nijak výjimečný, toho dosahují i jiné formáty.

Když chcete využít ostatní vámi uváděné výhody, potřebujete už implementaci v celém ekosystému.

Lež (navíc záměrná, protože již vám bylo dokázáno, že to to tak není)! Ví to již při přijmutí HTML (už asi po 3. ten samý kus HTML kódu, takže přestaňte lhát)
Klíííd. Nejde o žádnou lež, jenom dělám pořádek v tom vašem guláši. Když build systém nebo redakční systém neví nic o JXL, nemůže to přidávat do sourcesetu tím pádem je to odkázáno jenom na vyjednání typu na základě hlavičky Accept. Tedy teprve z odpovědi serveru se prohlížeč dozví, o jaký se jedná typ.

Ten kód, který uvádíte, se použije v situaci, kdy build systém nebo redakční systém nebo to, co generuje HTML, ví o JXL, je schopno do toho konvertovat obrázky a může tedy vygenerovat jak soubor JXL tak odpovídající záznam v sourcesetu.

Zcela myslím. Chcete znát výhody JPEG XL? Tohle je sice jenom malá výhoda, ale stále výhoda.
Aha. Tak nezapomeňte jako výhodu uvést také to, že má v názvu X, což vypadá moderně.

Pokud chcete psát výhody něčeho, očekává se, že dokážete posoudit jejich relevanci. A že nebudete uvádět „výhody“ na úrovni statistického šumu. Jinak to může svádět k otázce, zda stejně nezveličujete i ty ostatní výhody.

Sice se v tom pokoušíte udělat guláš, ale neúspěšně. Když použijeme jen implementaci na úrovni jiných formátů v prohlížeči, získáme jedinou výhodu – cca o 20 % lepší kompresi oproti JPEG. Tím ale není JPEG XL nijak výjimečný, toho dosahují i jiné formáty.
Opakovaná lež. 20% oproti JPEG je jenom pokud se transformuje lossless JPEG do JPEG XL. Loss kompresní poměr je zcela srovnatelný s AVIF a mnohem lepší než WebP. Už jsem vám to několikrát psal. Přestaňte záměrně lhát!
I kdybych vzal tenhle váš nesmyslný argument, tak získáte oproti současným formátům nenáročné dekódování (ve srovnání s AVIF a WebP) a navíc progresivní. Tohle jsou velké výhody oproti těm ostatním formátům.

Klíííd. Nejde o žádnou lež, jenom dělám pořádek v tom vašem guláši. Když build systém nebo redakční systém neví nic o JXL, nemůže to přidávat do sourcesetu tím pádem je to odkázáno jenom na vyjednání typu na základě hlavičky Accept. Tedy teprve z odpovědi serveru se prohlížeč dozví, o jaký se jedná typ.
Lež. Vy v tom máte naprostý guláš. Mícháte věci co spolu naprosto nesouvisí. Argumentujete úplně zcetsně. Opět znovu výsledný html kód je:

<picture>
<source srcSet="image.jxl" type="image/jxl" />
<source srcSet="image.avif" type="image/avif" />
<source srcSet="image.webp" type="image/webp" />
<img
width="1280" height="720" decoding="async" loading="lazy"
src="image.jpg" alt="hopefully an jxl image" />
</picture>

Ten přijde prohlížeči, ten podle podpory zvolí jaký typ obrázku bude stahovat podle atributu type v tuhle chvíli prohlížeč ví, že bude stahovat JPEG XL a může k němu tak přistoupit. Všimněte si, že ani v téhle době nemusí kontaktovat server, jestli tenhle soubor je JXL a už to ví.
Váš totálně nesmyslný argument s tím, že to ale do toho source set musí někdo/něco přidat a zkonvertovat na tom vůbec nic nemění. Tohle už je úplný nesmysl co píšete.
Aha. Tak nezapomeňte jako výhodu uvést také to, že má v názvu X, což vypadá moderně.
Opět došli argumenty.

Pokud chcete psát výhody něčeho, očekává se, že dokážete posoudit jejich relevanci. A že nebudete uvádět „výhody“ na úrovni statistického šumu. Jinak to může svádět k otázce, zda stejně nezveličujete i ty ostatní výhody.
Vy jste za celou dobu diskuze nebyl schopný vyvrátit jediný argument. Několikrát jste napsal nesmysl (20% oproti JPEG, prohlížeč musí ), můžeme hádat zda záměrně, či svojí neznalostí. Ale i přesto, že vám to bylo vysvětleno (někde i několikrát), že to není pravda jste neváhal to použít znovu, čímž jste již zcela záměrně lhal.

Opakovaná lež. 20% oproti JPEG je jenom pokud se transformuje lossless JPEG do JPEG XL. Loss kompresní poměr je zcela srovnatelný s AVIF a mnohem lepší než WebP. Už jsem vám to několikrát psal. Přestaňte záměrně lhát!
Děkuji, takže jste konečně potvrdil, že kompresní poměr JPEG XL není lepší, je s AVIF srovnatelný.

I kdybych vzal tenhle váš nesmyslný argument, tak získáte oproti současným formátům nenáročné dekódování (ve srovnání s AVIF a WebP) a navíc progresivní. Tohle jsou velké výhody oproti těm ostatním formátům.
To, že je dekódování oproti AVIF a WebP nenáročné, to umíte něčím doložit? Progresivní dekódování prakticky nikdo nechce, takže to není žádná výhoda.

Opět znovu výsledný html kód je:
Jo, jenže vy pořád ignorujete to, že se tenhle kód musí odněkud vzít.

Váš totálně nesmyslný argument s tím, že to ale do toho source set musí někdo/něco přidat a zkonvertovat na tom vůbec nic nemění. Tohle už je úplný nesmysl co píšete.
Že to není nesmyslný argument pochopíte, až pochopíte, jak se to v tom HTML vezme. Vy si patrně představujete, že se to tam objeví samo od sebe, ale tak to není.

Opět došli argumenty.
Ano, asi vám došly argumenty, když u obrázků, jejichž velikost se pohybuje od desítek kilobajtů po megabajty, a velikost paketů je obvykle 1,5 kilobajtu, argumentujete úsporou 300 bajtů.

Děkuji, takže jste konečně potvrdil, že kompresní poměr JPEG XL není lepší, je s AVIF srovnatelný.
Gratuluji, nikdy jsem netvrdil opak. V loss je někdy lepší, někdy horší, u toho taky velmi záleží na subjektivním vnímání. Ale například v lossless je vždy lepší.

To, že je dekódování oproti AVIF a WebP nenáročné, to umíte něčím doložit? Progresivní dekódování prakticky nikdo nechce, takže to není žádná výhoda.
https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11353/2556264/Benchmarking-JPEG-XL-image-compression/10.1117/12.2556264.short
JPEG XL was designed to benefit from multicore and SIMD, and actually decodes faster than JPEG

Progresivní dekódování nechcete hlavně asi vy. Tady je vyjádření člověka z Facebook (což mi na vyvrácení, že to nikdo nechce celkem jako důkaz stačí)
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18
The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.

Ano, asi vám došly argumenty, když u obrázků, jejichž velikost se pohybuje od desítek kilobajtů po megabajty, a velikost paketů je obvykle 1,5 kilobajtu, argumentujete úsporou 300 bajtů.
Zde chybí naprosto jakýkoliv argument a jakákoliv spojitost. Běžně se také přenáší grafika o velikostech 10MB a více, ale to má s tím společného asi stejně, jako váš "argument".

Gratuluji, nikdy jsem netvrdil opak.
Ah, a tohle teda psal kdo?

+-20% menší soubor, možnost snadno nenáročně poskytnout "legacy" JPEG. Co vám něco říká netuším, ale tahle vlastnost umožňuje využití JPEG XL ihned na webu pokud bude v prohlížečích jeho podpora. Tohle není jediná dobrá věc na něm, je to jenom obrovská výhoda oproti ostatním formátům.

— To, že je dekódování oproti AVIF a WebP nenáročné, to umíte něčím doložit?
— JPEG XL was designed to benefit from multicore and SIMD, and actually decodes faster than JPEG
A znovu, ptám se na AVIF a WebP, a vy odpovídáte o JPEG.

Tady je vyjádření člověka z Facebook
To vyjádření ovšem neříká, že to někdo chce.

Zde chybí naprosto jakýkoliv argument a jakákoliv spojitost. Běžně se také přenáší grafika o velikostech 10MB a více, ale to má s tím společného asi stejně, jako váš "argument".
Společného to má to, že řešíte 0,01 ‰ velikosti souboru. Tedy neprostý nesmysl.

Ano, opravdu. Protože ty důvody prezentovány byly – najdete je třeba i ve zprávičce, pod kterou diskutujete.
Ne to co bylo prezentováno není objektivní důvod proč to odstranit. To, že o to není zájem bylo vyvráceno, už jenom, že tady o tom diskutujeme, že je pod tím ticketem tolik komentářá, že existují společnosti, co se to chystali využít.
To, že nepřináší dostatek výhod oproti stávajícím formátům je obyčejná lež.

Já tam nevidím ani jediný program, který by měl něco společného s webovými technologiemi. Nijak jsem nerozporoval, že o něj někde zájem je. Ale nevidím ten zájem v ekosystému webu.
Podpora pro editaci a vytváření grafiky je první krok k tomu aby se ten formát mohl rozšířit i na web. Tohle JPEG XL splňuje nyní je možný druhý krok povolit ho v prohlížečích aby začalo masivní rozšíření a servery ho začali poskytovat.

Když vytvoříte formát, který vznikne z JPEG tím, že všechny bity otočíte, bude pro něj také snadná transformace tam i zpět. Ale něco mi říká, že se neuchytí.
Došly argumenty? Tak já vám opět nějaké dám: +-20% menší soubor, možnost snadno nenáročně poskytnout "legacy" JPEG. Co vám něco říká netuším, ale tahle vlastnost umožňuje využití JPEG XL ihned na webu pokud bude v prohlížečích jeho podpora. Tohle není jediná dobrá věc na něm, je to jenom obrovská výhoda oproti ostatním formátům. A je to přesně to co se dá označit za dostatečnou výhodu.

Tohle je právě okrajový případ. Prakticky to skoro nikdo nevyužije.
Viděl jste to? Podívejte se na to, jak to vypadá a pak se k tomu vyjadřujte.

Navíc ten vámi popisovaný příklad by načítání stránek ve skutečnosti zpomaloval – a to všem, i když by nepoužívali JPEG XL. Protože prohlížeč by při každém požadavku na obrázek musel požadovat jenom hlavičku, tu byl dostal, zjistil by, že nejde o obrázek typu JPEG XL a teprve pak by si mohl říci o zbytek souboru. Takže by se přidal jeden roundtrip. I kdyby to byl JPEG XL, pořád by tam byl roundtrip, během kterého by se jinak ten obrázek možná stáhl celý.
Nesmysl. Prohlížeč ví co je nabízeno i nyní:

<picture>
<source srcSet="image.jxl" type="image/jxl" />
<source srcSet="image.avif" type="image/avif" />
<source srcSet="image.webp" type="image/webp" />
<img
width="1280" height="720" decoding="async" loading="lazy"
src="image.jpg" alt="hopefully an jxl image" />
</picture>

Takže tenhle blábol je vyvrácen.

Další okrajový případ. Dneska je přístup přesně opačný – ničemu nevadí, když je enkódování náročné, protože se dělá jednou a pak se nahraje na servery, odkud se ten soubor bude poskytovat tisíckrát nebo milionkrát.
Jasně, ale jenom v některých případech a navíc potřebujete HW support. Máme dva srovnatelné formáty jeden je na enkódování nenáročný a lze udělat kdekoliv a druhý bez HW supportu je nepoužitelný. Zajímavé je, že jste záměrně vynechal dekódování, asi proto (nebudeme si nic nalhávat určitě), že se vám nehodilo do vaší argumentace.

Ne to co bylo prezentováno není objektivní důvod proč to odstranit.
Tak znovu. To, že vás se ten důvod nelíbí nebo ho nepovažujete za podstatný, neznamená, že to není objektivní důvod.

To, že o to není zájem bylo vyvráceno, už jenom, že tady o tom diskutujeme, že je pod tím ticketem tolik komentářá, že existují společnosti, co se to chystali využít.
Ne, diskuse pár lidí na Rootu opravdu není důkazem toho, že je o to zájem v celém ekosystému okolo webu.

To, že nepřináší dostatek výhod oproti stávajícím formátům je obyčejná lež.
Žádnou podstatnou výhodu jste nepopsal. Popsal jste spoustu okrajových případů použití, které by vyžadovaly další úpravy jak v prohlížeči, tak na serveru.

Podpora pro editaci a vytváření grafiky je první krok k tomu aby se ten formát mohl rozšířit i na web.
Nikoli. Na web se to dostává z buildovacích nástrojů, které mohou mít na vstupu úplně jiný formát.

Tohle není jediná dobrá věc na něm, je to jenom obrovská výhoda oproti ostatním formátům.
To, že je ten soubor o 20 % menší, je výhoda oproti JPEG, ne oproti ostatním formátům.

A je to přesně to co se dá označit za dostatečnou výhodu.
Jenže tuhle „dostatečnou“ výhodu mají i další formáty. A prohlížeče asi nebudou implementovat každý formát, který nabídne úsporu oproti JPEG.

Viděl jste to? Podívejte se na to, jak to vypadá a pak se k tomu vyjadřujte.
Stále nechápete, že nejde o to, jak to vypadá, ale jestli to řeší nějakou potřebu, která dnes není vyřešena jiným způsobem. Velikost souborů pro mobilní zařízení se řeší sourcesety, často je tam i jiný obrázek, takže tam JPEG XL nijak nepomůže. Zmenšování velikosti obrázku na úkor jeho viditelné kvality prakticky nikdo nechce – týkalo by se to jen pomalých připojení v případě, že někoho ten obrázek moc nezajímá. Takže je to velmi okrajový případ použití.

To, že je něco velmi zajímavé z technického hlediska ještě neznamená, že je to užitečné. Smiřte se s tím.

Nesmysl. Prohlížeč ví co je nabízeno i nyní:
Tohle ovšem vyžaduje podporu na straně buildovacího nástroje nebo redakčního systému.

Máme dva srovnatelné formáty
Jenže ony to nejsou dva srovnatelné formáty. On je to jeden formát, který se používá, a druhý formát, který by ho chtěl nahradit. Je ta nenáročnost na enkódování opravdu tak podstatná, aby se kvůli tomu prosadil nový formát?

Zajímavé je, že jste záměrně vynechal dekódování, asi proto (nebudeme si nic nalhávat určitě), že se vám nehodilo do vaší argumentace.
Ano, vynechal jsem ho záměrně, protože pokud vím, není v tom výrazný rozdíl.

Ne, diskuse pár lidí na Rootu opravdu není důkazem toho, že je o to zájem v celém ekosystému okolo webu.
Záměrně vytrženo z kontextu. Zbytek jste záměrně vynechal.
že je pod tím ticketem tolik komentářá, že existují společnosti, co se to chystali využít.
viz:
POTVRZOVACÍ ZKRESLENÍ
Mluvčí účelově vybírá z komplexního tématu jen ty aspekty, které se hodí pro jeho argument a ignoruje ty, které ho naopak vyvrací.

Žádnou podstatnou výhodu jste nepopsal. Popsal jste spoustu okrajových případů použití, které by vyžadovaly další úpravy jak v prohlížeči, tak na serveru.
Popsal záměrně je ignorujete.

Nikoli. Na web se to dostává z buildovacích nástrojů, které mohou mít na vstupu úplně jiný formát.
Píšete úplně k jiné věci. Otázka zněla: Všichni přidávají podporu JPEG XL jak na běžící páse v posledních měsících Kdo všichni?
Držte se toho na co vám odpovídám a nestavěte vzdušné zámky.

To, že je ten soubor o 20 % menší, je výhoda oproti JPEG, ne oproti ostatním formátům.
Opět záměrné vytržení z kontextu. Správně je, že je soubor o 20% menší při beztrátové transformaci. U konverzi do JPEG XL je na tom stejně jako AVIF. Buď neznalostí nebo záměrně ohýbáte fakta. Tohle je obyčená lež.

Stále nechápete, že nejde o to, jak to vypadá, ale jestli to řeší nějakou potřebu, která dnes není vyřešena jiným způsobem. Velikost souborů pro mobilní zařízení se řeší sourcesety, často je tam i jiný obrázek, takže tam JPEG XL nijak nepomůže. Zmenšování velikosti obrázku na úkor jeho viditelné kvality prakticky nikdo nechce – týkalo by se to jen pomalých připojení v případě, že někoho ten obrázek moc nezajímá. Takže je to velmi okrajový případ použití.
Stále stejná písnička. Která záměrně ignoruje výhody progresivního dekódování. Již jsem vám několikrát popsal, že díky tomu není potřeba mít jíný obrázek a nemusíte tedy ukládat dva totožné obrázky jinak zkomprimované. Ale záměrně nebo neznalostí to zcela ignorujete. To, že se to dá využít jinde už úplně ignorujete (např. náhledy). Ještě jednou a naposled: Viděl jste to? Podívejte se na to, jak to vypadá a pak se k tomu vyjadřujte.

Tohle ovšem vyžaduje podporu na straně buildovacího nástroje nebo redakčního systému.
Obyčejná lež. Takhle se to dnes používá (prosím přestaňte lhát):
<picture>
<source srcSet="image.jxl" type="image/jxl" />
<source srcSet="image.avif" type="image/avif" />
<source srcSet="image.webp" type="image/webp" />
<img
width="1280" height="720" decoding="async" loading="lazy"
src="image.jpg" alt="hopefully an jxl image" />
</picture>


Jenže ony to nejsou dva srovnatelné formáty. On je to jeden formát, který se používá, a druhý formát, který by ho chtěl nahradit. Je ta nenáročnost na enkódování opravdu tak podstatná, aby se kvůli tomu prosadil nový formát?
Další lež. Jestli myslíte WebP, tak ten opravdu s JPEG XL srovnatelný není. Pokud o AVIF, tak ten se opravu nepoužívá (to je holý fakt). A ano nenáročnost na enkódování je podstatná, protože díky tomu ten formát můžete používat ihned i na zařazeních, které nemají HW podporu. Ale to snad dobře víte a záměrně to ignorujete.

Ano, vynechal jsem ho záměrně, protože pokud vím, není v tom výrazný rozdíl.
Tohle už je lež jako věž. Pokud tohle tvrdíte, tak nemá vůbec cenu o čem na tohle téma diskutovat.

Zbytek jste záměrně vynechal.
Ano, zbytek jsem záměrně vynechal. Protože zbytek by možná mohl být relevantní argument – ale musel bych si to ověřovat. Protože jste to uvedl ve stejné rovině s absolutně irelevantním argumentem. Jinými slovy, když uvedete vedle sebe několik tvrzení, z nichž první je úplně irelevantní, nemůžete se divit, že se nikomu nechce ověřovat vaše další tvrzení, zda některé z nich není náhodou relevantní.

Držte se toho na co vám odpovídám a nestavěte vzdušné zámky.
Bavíme se o webovém prohlížeči, tedy se celou dobu evidentně bavíme o webu. Je irelevantní, zda to někdo použije třeba pro dlouhodobou archivaci – podstatné je, jakou to má podporu v nástrojích pro web.

Opět záměrné vytržení z kontextu. Správně je, že je soubor o 20% menší při beztrátové transformaci. U konverzi do JPEG XL je na tom stejně jako AVIF. Buď neznalostí nebo záměrně ohýbáte fakta. Tohle je obyčená lež.
Co je na tom za lež? JPEG XL je o 20 % menší než AVIF? Pokud to chcete tvrdit, tak do dokažte.

Která záměrně ignoruje výhody progresivního dekódování.
Už jsem vám několikrát vysvětloval, že o progresivní dekódování není na webu zájem. Aby se dalo použít tak, jak popisujete, znamenalo by to úpravu vytváření stránek, úpravu serverů a úpravu prohlížečů. A získal byste tím podporu velmi okrajového případu užití, co ve skutečnosti nikdo nepovažuje za problém. Já nezpochybňuju, že je to hezká technologie. Jenom pro ni prostě na současném webu není použití.

To, že se to dá využít jinde už úplně ignorujete (např. náhledy).
Neignoruju. Vy ignorujete, že náhledy se takhle nedělají.

Obyčejná lež. Takhle se to dnes používá (prosím přestaňte lhát)
Aha. A ten řádek:

<source srcSet="image.jxl" type="image/jxl" />

se v HTML podle vás objeví jak? Čára máry fuk a je tam? Nebo ho tam musí vložit redakční systém nebo nástroj, který provádí generování artefaktů pro web? Ano, když máte svůj webík se třemi stránkami a dvěma obrázky, tak to tam vložíte ručně. Ale kvůli vašim dvěma obrázkům se nebude udržovat podpora dalšího formátu v prohlížeči.

A ano nenáročnost na enkódování je podstatná, protože díky tomu ten formát můžete používat ihned i na zařazeních, které nemají HW podporu.
Zase jen další příklad něčeho, co technicky jde, je to technicky hezká věc, akorát o to nikdo nemá zájem. To enkódování se dělá buď při buildu webu nebo při zpracování obrázků (na počítači grafika). Ani jedno není případ slabého HW.

Ano, zbytek jsem záměrně vynechal. Protože zbytek by možná mohl být relevantní argument – ale musel bych si to ověřovat. Protože jste to uvedl ve stejné rovině s absolutně irelevantním argumentem. Jinými slovy, když uvedete vedle sebe několik tvrzení, z nichž první je úplně irelevantní, nemůžete se divit, že se nikomu nechce ověřovat vaše další tvrzení, zda některé z nich není náhodou relevantní.
Takže vám došli argumenty.

Bavíme se o webovém prohlížeči, tedy se celou dobu evidentně bavíme o webu. Je irelevantní, zda to někdo použije třeba pro dlouhodobou archivaci – podstatné je, jakou to má podporu v nástrojích pro web.
Ne, opět jste si akorát domýšlel něco co nikdy nebylo napsáno.

Aha. A ten řádek:

<source srcSet="image.jxl" type="image/jxl" />
se v HTML podle vás objeví jak? Čára máry fuk a je tam? Nebo ho tam musí vložit redakční systém nebo nástroj, který provádí generování artefaktů pro web? Ano, když máte svůj webík se třemi stránkami a dvěma obrázky, tak to tam vložíte ručně. Ale kvůli vašim dvěma obrázkům se nebude udržovat podpora dalšího formátu v prohlížeči.
Krásně se snažíte stočit diskuzi (na podporu v UI frameworcích), ale bohužel mluvíte úplně z cesty k úplně k jinému tématu. Vy jste tvrdil, že prohlížeč musí doptat serveru, aby mu server mohl poskytnout jxl. Důkaz, že nemusí jste dostal, dále nemá na tohle téma diskutovat. Prostě uznejte, že jste se mýlil a nesnažte se z toho vybruslit.

Už jsem vám několikrát vysvětloval, že o progresivní dekódování není na webu zájem. Aby se dalo použít tak, jak popisujete, znamenalo by to úpravu vytváření stránek, úpravu serverů a úpravu prohlížečů. A získal byste tím podporu velmi okrajového případu užití, co ve skutečnosti nikdo nepovažuje za problém. Já nezpochybňuju, že je to hezká technologie. Jenom pro ni prostě na současném webu není použití.
To je jenom jeho pokročilé využití. Pro základní využití není potřeba udělat nic a funguje out of box.

Co je na tom za lež? JPEG XL je o 20 % menší než AVIF? Pokud to chcete tvrdit, tak do dokažte.
Tady máte srovnání (je to sice od autora, takže to nemusí být pravda a může to být zkreslené): https://cloudinary.com/blog/the-case-for-jpeg-xl
Průměrně to je JPEG XL 30-35% menší než MozJPEG, dle jejich zatím nezveřejněné studie.

Zase jen další příklad něčeho, co technicky jde, je to technicky hezká věc, akorát o to nikdo nemá zájem. To enkódování se dělá buď při buildu webu nebo při zpracování obrázků (na počítači grafika). Ani jedno není případ slabého HW.
Dobrý blud. Problém je, že berete v potaz jenom část webu s malým počtem grafiky. Pokud se ale podíváte na weby s obřím množství grafiky, rázem to začíná být problém. Dále tu máme zpracování grafiky kterou nahraje uživatel a tam už to problém je. Pokud budu moci poskytnout srovnatelnou grafiku ale zpracování jedné je rychlé a druhé pomalé a navíc náročnější na zdroje. Kterou budou moci použít bez rozdílu (bude mít stejnou podporu), tak bych chtěl vidět člověka, který by zvolil tu pomalejší a náročnější, když výsledek bude stejný.

Vy jste tvrdil, že prohlížeč musí doptat serveru, aby mu server mohl poskytnout jxl.
Ano, to jsem tvrdil, protože jsme se bavili o situaci, kdy nikde mimo prohlížeč není žádná podpora pro JPEG XL, takže prohlížeč dostane základní

<img src="/obrazek" />

a pomocí content negotiation vyjedná se serverem, že chce JPEG XL. A v takovém případě se dozví, že dostává JPEG XL až teprve v okamžiku, kdy mu server pošle hlavičky. A to už je pozdě na to, aby si prohlížeč řekl, že vlastně nechce celý soubor ale jenom jeho část.

Pro základní využití není potřeba udělat nic a funguje out of box.
Což nic nemění na tom, že ji skoro nikdo nechce.

– Co je na tom za lež? JPEG XL je o 20 % menší než AVIF? Pokud to chcete tvrdit, tak do dokažte.
– Tady máte srovnání (je to sice od autora, takže to nemusí být pravda a může to být zkreslené): https://cloudinary.com/blog/the-case-for-jpeg-xl
Průměrně to je JPEG XL 30-35% menší než MozJPEG, dle jejich zatím nezveřejněné studie.
MozJPEG je AVIF? Nebo proč si myslíte, že je to relevantní odpověď na mou otázku?

Dobrý blud. Problém je, že berete v potaz jenom část webu s malým počtem grafiky. Pokud se ale podíváte na weby s obřím množství grafiky, rázem to začíná být problém.
Jasně, protože web s velkým množstvím grafiky se připravuje na co nejslabším HW.

Dále tu máme zpracování grafiky kterou nahraje uživatel a tam už to problém je.
Jako že grafika nahraná uživatelem se zpracovává na nevýkonném HW?

Pokud budu moci poskytnout srovnatelnou grafiku ale zpracování jedné je rychlé a druhé pomalé a navíc náročnější na zdroje.
Nenáročnost na CPU už je zahrnuta v tom „rychlé“. Takže co jsou ty další zdroje, na které je JPEG XL méně náročný? RAM? Máte k tomu nějaké další informace?

3. 11. 2022, 16:44 editováno autorem komentáře

Ano, to jsem tvrdil, protože jsme se bavili o situaci, kdy nikde mimo prohlížeč není žádná podpora pro JPEG XL, takže prohlížeč dostane základní
<img src="/obrazek" />
a pomocí content negotiation vyjedná se serverem, že chce JPEG XL. A v takovém případě se dozví, že dostává JPEG XL až teprve v okamžiku, kdy mu server pošle hlavičky. A to už je pozdě na to, aby si prohlížeč řekl, že vlastně nechce celý soubor ale jenom jeho část.
Co to proboha pořád melete? Proč by měl dostat jenom <img src="/obrazek" /> a nepoužil by

<picture>
  <source srcSet="image.jxl" type="image/jxl" />
  <img
width="1280" height="720" decoding="async" loading="lazy"
src="image.jpg" alt="hopefully an jxl image" />
</picture>

? Jedině, že vůbec netuší co dělá a pak asi nebude chtít ani využít tuhle vlastnost. Snažíte si to ohnout, ale vůbec se vám to teda nedaří. Jestli myslíte, že by to byla adresa něco jako otevřít rovnou url jako https://jpegxl.io/comparison/frog.jxl , tak tam opravdu nedává smysl uživatel omezovat na kvalitě obrázku.

MozJPEG je AVIF? Nebo proč si myslíte, že je to relevantní odpověď na mou otázku?
Jenom jsem vám chtěl ukázat co je na tom za lež. Nikdy jsem netvrdil, že JPEG XL je o 20% menší než AVIF. Snažil jste se pouze bagatelizovat možnost transformace JPEG do JPEG XL. Snažil jste se tvrdit, že rozdíl mezi JPEG XL je menší o 20% než JPEG.

Jako že grafika nahraná uživatelem se zpracovává na nevýkonném HW?
Výkon je naprosto nepodstatné. Podstatné je kolik jste schopný těch souborů zpracovat za jednotku času se stejným HW. Pokud jste schopny zpracovat 500 souborů nebo 1000 (zcela náhodná čísla, netýkající se ani jednoho z formátů) za minutu, tak už je to podstatný rozdíl.
Nenáročnost na CPU už je zahrnuta v tom „rychlé“. Takže co jsou ty další zdroje, na které je JPEG XL méně náročný? RAM? Máte k tomu nějaké další informace?
Nepsal jsem vyloženě o JPEG XL a AVIF myslel jsem to obecně. Ale uznávám, že spotřebu RAM nemám nijak u JPEG XL vs AVIF nijak podložené.

Co to proboha pořád melete? Proč by měl dostat jenom <img src="/obrazek" /> a nepoužil by [sourceset]? Jedině, že vůbec netuší co dělá.
Kdo by nepoužil? Server tam tohle bude vkládat sám od sebe, aniž by věděl něco o JPEG XL? Nebo to tam bude vkládat WebPack, aniž by měl jakoukoli podporu JPEG XL? Vypadá to, že vůbec nevíte, jak vůbec vzniká HTML, které pošle server do prohlížeče.

Nikdy jsem netvrdil, že JPEG XL je o 20% menší než AVIF.
Tvrdil jste, že je menší než jiné formáty.

Snažil jste se tvrdit, že rozdíl mezi JPEG XL je menší o 20% než JPEG.
Ne, nic takového jsem netvrdil. Jenom jsem vyvracel vaši lež, že JPEG XL je menší než jiné formáty, tedy i WebP nebo AVIF.

Podstatné je kolik jste schopný těch souborů zpracovat za jednotku času se stejným HW.
Opravdu? Proč? Připomínám, že se bavíme o publikování na web.

Mě se zdá, že v diskuzi se řeší okrajové případy.
* Pokud má JXL proti WebP minimální výhody, tak nikoho nezajímá. Facebook dokonce neposílá ani ten WebP. Nextcloud posílá JPEG zmenšený za chodu, možná sám o sobě umí JPEG dekódovat částečně a jeho prohlížeč si o něj nějakým způsobem řekne. Tím, že se neukládá obraz ve třech skoro stejně dobrých formátech (příklad picture) se ušetří místo a tím, že se obrázek stáhne celý jen při downloadu i přenosová linka.
* Překódování fotek na disku. Mám 50000 fotek, průměrná velikost je 15MB, celkem to dělá 750GB. K tomu mám jen tak mimochodem asi 1,6GB RAWů po 32MB. Pokud je úspora až 22%, znamená to nejvyšší stupeň komprese? Jak dlouho pak rekomprese trvá? Aha, řádově možná 15-20s. Fajn, mám 12 jader s HT, pokud se zatíží všechny, trochu klesne výkon, popere se to o paměť a tak ... dobře, 3s na fotku průměr, to dělá ... dva dny ... pro úsporu 150-200GB. To nezní lákavě. (ne parallel -j 24 cjxl ... ::: *.jpg jsem nezkoušel, je to pustý odhad)
* Přechozí bod úplně irelevatní, protože cjxl bezztrátovou rekompresi k dnešnímu datu ve verzi 0.7 nepodporuje
* Pro čistě cloudové služby které řeší obrázky je otázkou, jestli nemají bezztrátovou rekompresi implementovanou už teď, JPEG lze rozložit na prvočinitele a překódovat, když není požadavek na to, že co nahraju, dostanu zpět ve stejné podobě (facebook, instagram)

Jasně, uznávám, že JPEG je formát z počítačového pravěku se spoustou vad, prediktory v PNG jsou primitivní, deflate kompresi překonává zstandard ve všech ohledech a nový formát by se hodil. Jenže když máme webp (který není perfektní, ale na 98,3% případů stačí) a ani ten se po deseti letech moc neuchytil tak to mají další formáty těžké. Ale sám úsporu dat řeším jen tam, kde je omezená a/nebo drahá kapacita. A tady je ke zvážení, jestli prostě nesnížit kvalitu JPEGu, nezmenšit obrázky, které s někým sdílím. nevypnout cleartype, když dělám screenshoty apod.

Zajímavosti:
* JXL jde uploadovat na Facebook, ale zpět to pošle JPEG.
* JXL používá Brotli od Google, zajímavé, že ne třeba zstandard s rychlejší dekompresí

Pokud má JXL proti WebP minimální výhody, tak nikoho nezajímá.
WebP je ale použitelný jenom pro web a ne pro fotky. Nikdo do něj fotky nikdy ukládat nebude. Oproti tomu JPEG XL je univerzální formát s lepší kompresí, který poskytuje vše co WebP a další věci navíc.

Nextcloud posílá JPEG zmenšený za chodu, možná sám o sobě umí JPEG dekódovat částečně a jeho prohlížeč si o něj nějakým způsobem řekne. Tím, že se neukládá obraz ve třech skoro stejně dobrých formátech (příklad picture) se ušetří místo a tím, že se obrázek stáhne celý jen při downloadu i přenosová linka.
Ale u JPEG XL a WebP (u AVIF těžko ten je náročný na encoding, možná s HW podporou) to lze udělat úplně stejně. Navíc tohle umí JPEG XL out of box s progresivním dekódováním a nemusíte to dělat na serveru.

dva dny ... pro úsporu 150-200GB. To nezní lákavě.
Tohle vám nebudu rozporovat, je to osobní názor každého. Mě to třeba příjde dost. Tu možnost máte a můžete jít využít, ale nikdo vás do toho nenutí. Můžete to klidně dělat jenom pro nově přidané soubory. Kdybyste to dělal do WebP nebo AVIF, tak by to nebyly "pouze" 2 dny. Navíc je můžete konvertovat i ztrátově pak ta úspora bude mnohem větší. Můžete si vybrat se vám hodí.

Přechozí bod úplně irelevatní, protože cjxl bezztrátovou rekompresi k dnešnímu datu ve verzi 0.7 nepodporuje
cjxl - encoding djxl - decompresion

djxl input.jxl output.jpg

Pro čistě cloudové služby které řeší obrázky je otázkou, jestli nemají bezztrátovou rekompresi implementovanou už teď
Ale to je něco nestandardního a musíte to stále převádět zpět aby uživatel dostal JPEG (čímž zatěžujete server). Právě proto je tohle součástí JPEG XL.

Jenže když máme webp (který není perfektní, ale na 98,3% případů stačí) a ani ten se po deseti letech moc neuchytil tak to mají další formáty těžké.
WebP nemá/nikdy neměl šanci se prosadit, právě kvůli tomu, že je to formát jenom pro web a není dostatečně univerzální. V podstatě se nikde jinde nepoužívá. Používá se jenom díky masivní podpoře od Google, který ho tlačil na sílu a i přesto je jeho zastoupení po deseti letech velmi malé. Kdyby ho Google netlačil tak by ho nikdo nepoužil, ale to je jenom co kdyby. WebP není špatný, ale jak již víme musíme stále poskytovat i JPEG.

Formát pro web se nemůže rozšířit bez podpory ve většině webových prohlížečích.
Za prvé, prohlížeče s jádrem Blink mají na trhu podíl kolem 70 %. Já bych to za většinu považoval. Za druhé, zrovna formát médií se může rozšířit bez podpory ve většině prohlížečů, protože prohlížeče posílají serveru informaci, které formáty podporují. A u mediálních formátů (obrázky, videa) je docela běžná situace, že nějaký formát podporují jen některé prohlížeče.

Nechápu co se snažíte říct, ale začínáte být trapný.
Pořád jste neuvedl nějaký důvod, proč už se tedy JPEG XL na webu dávno nepoužívá, když je to takové terno.
Za prvé, prohlížeče s jádrem Blink mají na trhu podíl kolem 70 %. Já bych to za většinu považoval.
1. JPEG XL nemá výchozí podporu (uživatel si musí zapnout experimentální flag) skoro v žádném prohlížeči. Takže nechápu co píšete za nesmysly, že Blink má velký podíl na trhu, to všichni vědí ale nechápu jakou to má souvislost.
Za druhé, zrovna formát médií se může rozšířit bez podpory ve většině prohlížečů, protože prohlížeče posílají serveru informaci, které formáty podporují. A u mediálních formátů (obrázky, videa) je docela běžná situace, že nějaký formát podporují jen některé prohlížeče.
Nechápu co se snažíte napsat, ale nedává to smysl. K čemu je formát pro web, který 70% (v současné chvíli asi i víc než 99%) lidí nezobrazí? Jako, že servery budou mít u sebe JPEG XL, aby to mohl jednou za 10 let někomu poslat. Nenechte se vysmát.
Buď pište k věci nebo nepište vůbec. Tyhle vaše slepé výstřely nikam nevedou.

JPEG XL nemá výchozí podporu (uživatel si musí zapnout experimentální flag) skoro v žádném prohlížeči.
Vy jste psal, že to chcete používat pro nějaký svůj archiv fotek. To si v prohlížeči neumíte tu podporu zapnout?

Nechápu co se snažíte napsat, ale nedává to smysl. K čemu je formát pro web, který 70% (v současné chvíli asi i víc než 99%) lidí nezobrazí? Jako, že servery budou mít u sebe JPEG XL, aby to mohl jednou za 10 let někomu poslat. Nenechte se vysmát.
Buď pište k věci nebo nepište vůbec. Tyhle vaše slepé výstřely nikam nevedou.
Psal jste, že je potřeba, aby to podporovala většina prohlížečů. Jenže když to bude zajímavý formát, bude stačit, když to na začátku bude jen pod experimentálním příznakem, a ten, kdo s tím bude chtít experimentovat, si to zapne. Pak to implementuje třeba prohlížeč používající 10 % uživatelů. A servery už to budou podporovat, protože v některých případech to ušetří traffic a provozovatelé v tom uvidí budoucnost. Dokonce někdo možná uloží obrázky na serveru jenom v tomhle formátu a bude je online enkódovat do jiného formátu, když to prohlížeč nebude podporovat. Protože v tom provozovatelé uvidí budoucnost, budou na to chtít být připraveni. A protože udělat tu změnu je jednoduché, když v tom vidí ostatní také budoucnost – někde stačí jen jednorázově vyexportovat obrázky v jiném formátu, někde stačí jejich enkódování přidat do procesu sestavení webu. Proč se tohle všechno dávno neděje? Proč Cloudflare v rámci optimalizace obrázků nenabízí jako cílový formát JPEG XL? Proč to nepodporuje Next.js při optimalizaci obrázků?

To si v prohlížeči neumíte tu podporu zapnout?
Ooo jak velké překvapení, že to zapnuté mám jenže za pár měsíců mi to bude k ničemu, když to odeberou. Na tohle argument asi nemáte co?
Psal jste, že je potřeba, aby to podporovala většina prohlížečů. Jenže když to bude zajímavý formát, bude stačit, když to na začátku bude jen pod experimentálním příznakem, a ten, kdo s tím bude chtít experimentovat, si to zapne.
Ten experimentální příznak je, ale pro experimenty (překvapivě), jestli to funguje a ne pro okamžité nasazení všude a nikdo soudný na tom nebude stavět řešení pro masy.
Pak to implementuje třeba prohlížeč používající 10 % uživatelů.
No a co s tím. To nic nezmění.
A servery už to budou podporovat, protože v některých případech to ušetří traffic a provozovatelé v tom uvidí budoucnost. Dokonce někdo možná uloží obrázky na serveru jenom v tomhle formátu a bude je online enkódovat do jiného formátu, když to prohlížeč nebude podporovat. Protože v tom provozovatelé uvidí budoucnost, budou na to chtít být připraveni. A protože udělat tu změnu je jednoduché, když v tom vidí ostatní také budoucnost – někde stačí jen jednorázově vyexportovat obrázky v jiném formátu, někde stačí jejich enkódování přidat do procesu sestavení webu.
Servery to nebudou podporovat když to nebude podporovat browsery. Navíc pokud uvidí, že ta podpora pro 70% nebude, tak to určitě nebudou podporovat jako budoucí formát.

Proč se tohle všechno dávno neděje?
Ale děje, Facebook si s tím hraje, Shopify deklarovalo, že ho chce použít. Adobe navádí na zapnutí toho flagu. Ostatní software dostává podporu.

Proč Cloudflare v rámci optimalizace obrázků nenabízí jako cílový formát JPEG XL? Proč to nepodporuje Next.js při optimalizaci obrázků?
Protože není podpora v browserech. Je to na sobě závislé pokud browsery nedeklarují, že grafický formát budou umět zobrazit, tak se ten formát na web nikdy nemůže rozšířit.

Uvědomte si jak dlouho trvalo silou prosadit aspoň WebP (o AVIF vůbec nemluvě ten se skoro nepoužívá i když má podporu) a teď by to někteří chtěli aby JPEG XL byl ve stejném stavu po pár měsících.

1. 11. 2022, 19:42 editováno autorem komentáře

Ten experimentální příznak je, ale pro experimenty (překvapivě), jestli to funguje a ne pro okamžité nasazení všude a nikdo soudný na tom nebude stavět řešení pro masy.
Jenže už z toho se dá zjistit, jestli s tím vůbec někdo experimentuje.

No a co s tím. To nic nezmění.
Změní. Budou to podporovat poskytovatelé obsahu, protože se jim to vyplatí.

Servery to nebudou podporovat když to nebude podporovat browsery.
A browsery to nebudou podporovat, když to nebudou podporovat servery. Tuším tady začarovaný kruh.

Protože není podpora v browserech.
Ta podpora v browserech je, jenom se musí zapnout. A třeba Cloudflare často experimentuje s technologiemi, které jsou v prohlížečích experimentální.

teď by to někteří chtěli aby JPEG XL byl ve stejném stavu po pár měsících.
Ne, nechtěli. Vy se stále tváříte, jako by život webové technologie začínal teprve tehdy, když je dostupná všem ve všech prohlížečích. Jenže ve skutečnosti se s nimi experimentuje mnohem dřív a a už během těch experimentů se vyhodnocuje, zda je o to zájem a zda to přináší něco dostatečně nového.

Pokud měl JPEG XL nějaké nápady, které jinde nejsou a u kterých se ukázalo, že je o ně zájem, pravděpodobně se objeví v nějakém dalším formátu. Ve kterém ale nebudou ty zbytečnosti z JPEG XL, které skoro nikdo nechce.

Změní. Budou to podporovat poskytovatelé obsahu, protože se jim to vyplatí.
Nezmění pokud to nebude v chromium/blink, tak to prostě nikdo používat na webu nezačne. To je prostě holí fakt. Nikdo do toho nebude investovat.

A browsery to nebudou podporovat, když to nebudou podporovat servery. Tuším tady začarovaný kruh.
Ne to opravdu není kruh. Servery už nyní mohou poskytovat JXL, vše je připraveno jako pro ostatní formáty, stačí zapnout jenom podporu v browserech. Jenom není bez podpory v browseru rozšířený (kdo by to byl čekal po pár měsících od finální verze).

Ne, nechtěli. Vy se stále tváříte, jako by život webové technologie začínal teprve tehdy, když je dostupná všem ve všech prohlížečích. Jenže ve skutečnosti se s nimi experimentuje mnohem dřív a a už během těch experimentů se vyhodnocuje, zda je o to zájem a zda to přináší něco dostatečně nového.
Tak přidejte jediný důkaz, že o to není zájem. To, že přináší něco dostatečně nového už vám bylo několikrát vysvětleno. Nevím co dalšího byste chtěl aby to umělo komprimovat i zvuk. Opravdu by mě zajímalo co by musel nějaký formát poskytnout aby poskytoval něco dostatečně nového (je tam dostatek výhod oproti stávajícím) podle vás.

Pokud měl JPEG XL nějaké nápady, které jinde nejsou a u kterých se ukázalo, že je o ně zájem, pravděpodobně se objeví v nějakém dalším formátu. Ve kterém ale nebudou ty zbytečnosti z JPEG XL, které skoro nikdo nechce.
Jaké zbytečnosti? Opravdu jmenujte jich pár.

Nezmění pokud to nebude v chromium/blink, tak to prostě nikdo používat na webu nezačne. To je prostě holí fakt. Nikdo do toho nebude investovat.
Vaše tvrzení je v rozporu s realitou.

Servery už nyní mohou poskytovat JXL, vše je připraveno jako pro ostatní formáty, stačí zapnout jenom podporu v browserech.
Aby bylo možné využít to, co popisujete jako výhody JXL, je potřeba změny i v produkci obsahu (build, redakční systémy) i na straně serverů.

Tak přidejte jediný důkaz, že o to není zájem.
Ten už jsem vám psal. Kdo z provozovatelů poskytování obsahu to podporuje? Cloudflare ne, Next.js/Vercel ne, WordPress ne…

To, že přináší něco dostatečně nového už vám bylo několikrát vysvětleno.
Ano. Jenže vy stále nechápete, že to, že je něco dostatečně nové, neznamená, že je to dostatečně užitečné.

Jaké zbytečnosti? Opravdu jmenujte jich pár.
Např. progresivní dekódování.

Vaše tvrzení je v rozporu s realitou.
Ne není.
Aby bylo možné využít to, co popisujete jako výhody JXL, je potřeba změny i v produkci obsahu (build, redakční systémy) i na straně serverů.
Ne není. Stačí pro začátek poskytovat JPEG XL stejně jako WebP nebo AVIF. Tady není vůbec žádný rozdíl.

Ten už jsem vám psal. Kdo z provozovatelů poskytování obsahu to podporuje? Cloudflare ne, Next.js/Vercel ne, WordPress ne…
Opět záměrné ignorování faktů. Coudinary (podporuje), Facebook, Shopify (deklarovili zájem) se vám záměrně nehodí.

Např. progresivní dekódování.
Za 1. pár se nerovná 1, stále čekám na ty zbytečnosti, které níkdy nechce. Ale toho se nedočkám, protože to jenom plácáte. Za 2. "Viděl jste to? Podívejte se na to, jak to vypadá a pak se k tomu vyjadřujte."