Názory k článku
FSF se vyjádřilo k odstranění JPEG XL z Chrome a Chromia

Tak může mít prioritní zisk z prostředí, které preferencí "homogenizace" určitého formátu vznikne. To je na posouzení.

Většina spíš neřeší formáty vůbec, protože většina ani neví, co to je. U řady webů jsem už např. narazil na to, že používají webp, ale všiml jsem si toho jen proto, že jsem si nějaký obrázek chtěl uložit. A i kdyby se nakrásně stalo, že web pošle obrázek, který prohlížeč nebude umět zobrazit, reakce většinového uživatele nebude "používáte formát, který můj prohlížeč nezobrazí", ale buď "máte to rozbitý" nebo u těch trochu poučenějších "ten X stojí za h...., v Y mi to funguje normálně".

Nejsem až takový znalec JPEG XL, ale pokud by šlo posílat nejprve JPEG kompatibilní data a následně upřesnit (na vyšší rozlišení, HDR), dost možná by stačilo mít takové soubory na serveru předem připravené. Sice by se setřela výhoda vyšší komprese, ale ostatní výhody by mohly zůstat zachovány.
Tohle částečně jde docílit bezdrátovou transformací JPEG do JPEG-XL a zpět, která je rychlá. Co se týká úspory místa, tak je potřeba vzít v potaz i to, že stále musíte držet i původní JPEG, kdyby AVIF klient nepodporoval (takže minimálně 20let to bude nutnost). A nyní můžeme snadno počítat máme fotku v JPEG, co má 10 MB a máme dvě možnosti buď udělat AVIF a zmenšit její velikost na 4MB nebo udělat transformací do JPEG-XL a zmenšit jí na 8MB. Takže u AVIF jsem nakonec místo neušetřil, protože stále musím držet i původní JPEG takže mám 10 + 4 = 14MB oproti tomu mám s JPEG-XL jeden soubor 8 MB. Takže ve skutečnosti s JPEG-XL ušetříme 6 MB oproti AVIF s JPEG. No a když se za 20 let rozloučím s podporou JPEG tak tu fotku mužů zkomprimovat ztrátově a klidně do něčeho jiného AVIF-XL.
Teď se ozve zase nějaký chytrák, že místo je levné atp. ale je třeba si uvědomit, že někdo těch fotek obrázků má terabyty. Nebo třeba pro mě na archivaci rodinných fotek to smysl má, protože v podstatě za nic mužů ušetřit 20% místa bez toho aniž bych přišel o originál a třeba za 20let to můžu prohnat do nového skvělého bezztrátového PIK-XL s kompresí 90%.

Přemýšlím, v jakém případě platí těch 20 let. Před deseti lety tu byl Android 4.3 (chystal se 4.4) a Windows 8. A to zmiňuji OS, které z různých důvodů uživatelé upgradují méně často, ale pro zajímavost tu tehdy byl ještě iOS 6, který ještě neměl Flat design.

Na webu je situace ještě lepší. I pokud uživatel moc neaktualizuje OS, u prohlížeče to nebývá problém. A pro představu, před deseti lety nejnovější verze Firefoxu a Chrome ještě neuměly třeba TLS 1.2.

Pro rodinný archív je situace ještě jednodušší, v podstatě ani nepotřebujeme širokou podporu aktuálního software.

Pro rodinný archív je situace ještě jednodušší, v podstatě ani nepotřebujeme širokou podporu aktuálního software.
To ano, ale potřebuji podporu v prohlížeči. A taky pomíjíte fakt, že ta komprese je ztrátová vs bezztrátová. Já nechci u rodinných fotek přijít ani o jediný bit (i když to můžou být klidně mazaniny, kterým by to nijak neuškodilo), právě proto, že nevím jaký skvělý formát tu bude za 20let a rozhodně bych si nevsadil, že tu AVIF bude resp. že se bude používat.
JPEG-XL lze dnes integrovat např. do foťáku v Android a převádět on fly do JPEG-XL bez toho abyste o cokoliv přišel a nemusíte mít podporu pro kódování do AVIF nebo čehokoliv, protože to jde dobře dělat softwarově. Tím ušetříte až 20% místa a stále můžete snadno poskytnout původní JPEG když bude potřeba.

Podporu v prohlížeči fotek potřebujete, ale není nutná široká podpora v hromadě různého softwaru.

Ano, bezztrátová konverze stávajících fotek do úspornějšího formátu je výhoda JPEG XL oproti jiným jinak lepším formátům.

Podporu v prohlížeči fotek potřebujete, ale není nutná široká podpora v hromadě různého softwaru.
Jenže já potřebuji podporu ve webovém prohlížeči. A na tu asi bohužel můžu zapomenout kvůli odstranění podpory z Chromium.

Nestačí vám podpora ve vašem oblíbeném prohlížeči? Nebo vy používáte ten od zlého Googlu?

18. 4. 2023, 13:56 editováno autorem komentáře

A jakého prohlížeče? Vždyť skoro všechny použitelné jsou postavené na Chromium/Blink.

A kdo za to může? Držel Google ostatním pistoli u hlavy? Proč je Firefox taková mizérie (a tím automaticky ty na něm postavené)? Jinak Chromium není samo o sobě problém, tím jak je opensource, tak se běžně více či méně patchuje (HW video decoding na Linuxu pro slabé ARM/x86 zařízení - roky předtím, než to udělal Google oficiálně, Opera např. revertovala podporu NPAPI pluginů atd.). Očividně tedy nikoho nezajímá podpora tohoto formátu ani tam.

Však jsem odkazoval na knihovnu implementující JPEG XL v Wasm. Ano, na iOS to *dnes* má problém s limitem paměti, ale to se nejspíš podaří vyřešit.

Apple postupně povoluje šrouby, takže časem to pojede. Snaží se jet na hraně, co uživatelé ještě snesou, a je v tom fakt dobrý :-)

To nemusí vyřešit jej Apple. Může to vyřešit třeba autor knihovny pomocí streamování, pokud tomu formát nějak nebrání. Nebo to může vyřešit jiná knihovna – je jich více.

No pokud to autorovi takhle pro jeho platformy stačí a Apple mu čas navíc nezaplatí...

Já nechci u rodinných fotek přijít ani o jediný bit … právě proto, že nevím jaký skvělý formát tu bude za 20let

V tom případě je celá debata o výběru mezi různými ztrátovými formáty zcela nesmyslná, protože tuto podmínku nesplňuje žádný. Ale to je i bádání nad tím, jestli tu ten či onen formát bude za dvacet let. Formát nemůže přestat existovat, nanejvýš nebude podporován v běžně používaném software, ale to mi nebrání ponechat si původní data a zkonvertovat si je pokaždé do formátu, který je momentálně ten správný.

Námět k zamyšlení: zná někdo formát pro rastrové obrázky, který by před dvaceti lety (nebo klidně před třiceti) byl běžně používaný a rozšířený a dnes jsem ho nedokázal převést na nějaký dnes běžně používaný pomocí utilitek z ImageMagick? Nebo aspoň nedokázal rovnou otevřít v GIMPu či Photoshopu?

Pro představu, jak náročné je podporovat JPEG XL: https://github.com/niutech/jxl.js

Ano, pro běžné webové stránky to nebude ono minimálně kvůli velikosti samotného wasm. Pro fotogalerie se to vyplatit může.

Podobně AVIF: https://www.npmjs.com/package/@saschazar/wasm-avif?activeTab=readme

Na tom WASM řešení mě pobavilo, že na iOS to nejede - ani v singlethread režimu - protože Apple blokuje WASM skrze extrémně malý limit RAM, který může alokovat.

V tom případě je celá debata o výběru mezi různými ztrátovými formáty zcela nesmyslná, protože tuto podmínku nesplňuje žádný.
Ne není. Je tu JPEG-XL, který umí ztrátovou i bezztrátovou kompresi (stejně tak WebP o AVIF bych tohle moc nezmiňoval). Pokud si budu jistý, že se JPEG-XL prosadí a nahradí JPEG, tak klidně tu ztrátovou kompresi do něj nakonec udělám.
Navíc debata a je o univerzálním obrazovém formátu ne jenom o ztrátovém nebo jenom bezztrátovém.

Formát nemůže přestat existovat, nanejvýš nebude podporován v běžně používaném software, ale to mi nebrání ponechat si původní data a zkonvertovat si je pokaždé do formátu, který je momentálně ten správný.
Což je, ale problém k čemu jsou mi data a hlavně fotky, které nemůžu najednout otevřít v běžném prohlížeči obrázků.

Námět k zamyšlení: zná někdo formát pro rastrové obrázky, který by před dvaceti lety (nebo klidně před třiceti) byl běžně používaný a rozšířený a dnes jsem ho nedokázal převést na nějaký dnes běžně používaný pomocí utilitek z ImageMagick? Nebo aspoň nedokázal rovnou otevřít v GIMPu či Photoshopu?
Což je přesně ale ten problém, který mám. Nedává smysl komprimovat něco ztrátově, když si nejsem jistý, jestli to nebudu muset za 20let opět ztrátově převádět na něco nového.

Je tu JPEG-XL, který umí ztrátovou i bezztrátovou kompresi

I kdyby uměl bezztrátově uložit bitmapu a třeba i v libovolné bitové hloubce, pořád by to nesplňovalo požadavek nechci ztratit ani bit informace. A asi jen málokdo by ho takovým způsobem používal. Nemluvě o tom, že se tu celou dobu točíme na "killer feature", že se do JPEG-XL dá embednout JPEG bez další ztráty informace. Což je celkem úsměvné, protože si troufám tvrdit, že konverzí JPEGu do jiného kvalitního ztrátového formátu se ztratí podstatně méně informace než se ztratilo už cestou do toho JPEGu.

Což je, ale problém k čemu jsou mi data a hlavně fotky, které nemůžu najednout otevřít v běžném prohlížeči obrázků.

Můžu si je pokaždé z toho původního zkonvertovat do aktuálně preferovaného. Je to mnohem lepší než je nechat postupně degradovat konverzemi mezi různými formáty. Já mám třeba naprostou většinu svých fotek archivovanou ve formátech, které naprostá většina běžných prohlížečů nezobrazí. Výjimku tvoří jen ty nejstarší z Olympusu C-4000 a prvních pár testovacích z Canonu 400D.

Což je přesně ale ten problém, který mám. Nedává smysl komprimovat něco ztrátově, když si nejsem jistý, jestli to nebudu muset za 20let opět ztrátově převádět na něco nového.

Asi si nerozumíme. Pointa toho námětu k zamyšlení je, že já takový formát neznám. Když si vzpomenu na formáty rastrové grafiky, které se běžně používaly kolem roku 1990, tak všechny dodnes zvládá nejen ImageMagick, ale taky mi je rovnou otevře GIMP. Takže si říkám, jestli celá ta diskuse není jen ryze teoretická.

A asi jen málokdo by ho takovým způsobem používal. Nemluvě o tom, že se tu celou dobu točíme na "killer feature", že se do JPEG-XL dá embednout JPEG bez další ztráty informace.
Jenže on to není jenom embeddovaný JPEG. A jenom touhle transformací ušetříte 20%.
Což je celkem úsměvné, protože si troufám tvrdit, že konverzí JPEGu do jiného kvalitního ztrátového formátu se ztratí podstatně méně informace než se ztratilo už cestou do toho JPEGu.
Ano to je problém, ale když už mám data nevratně ztracená, tak nechci přijít o další.
Můžu si je pokaždé z toho původního zkonvertovat do aktuálně preferovaného. Je to mnohem lepší než je nechat postupně degradovat konverzemi mezi různými formáty. Já mám třeba naprostou většinu svých fotek archivovanou ve formátech, které naprostá většina běžných prohlížečů nezobrazí. Výjimku tvoří jen ty nejstarší z Olympusu C-4000 a prvních pár testovacích z Canonu 400D.
No ale pak to není na prohlížení a máte s tím nějakou práci abyste si je vůbec mohl prohlédnout.
Asi si nerozumíme. Pointa toho námětu k zamyšlení je, že já takový formát neznám. Když si vzpomenu na formáty rastrové grafiky, které se běžně používaly kolem roku 1990, tak všechny dodnes zvládá nejen ImageMagick, ale taky mi je rovnou otevře GIMP. Takže si říkám, jestli celá ta diskuse není jen ryze teoretická.
Ano je teoretická, ale to že podporu třeba webové prohlížeče zahodí není zas tak nereálné.

Jenže on to není jenom embeddovaný JPEG.

To, že tam není vložený beze změny, na věci nic nemění. Pokud je to beze ztráty informace, znamená to, že je tam vložený, nanejvýš je prohnaný nějakou revertovatelnou transformací, která ve většině běžných případů zmenší velikost. (Že by ji zmenšila vždy, na to si, doufám, hrát nebudeme.)

No ale pak to není na prohlížení a máte s tím nějakou práci abyste si je vůbec mohl prohlédnout.

Právě že vůbec ne. Prohlížeč, který nejraději používám (geeqie), mi je bez problémů ukáže. Dokonce mi ukáže i ty z nového foťáku, kvůli kterým si musím udržovat opatchované verze libraw a darktable, abych je vůbec mohl rozumně zpracovávat. (OK, s některými sofistikovanějšími variantami geeqie problém má, nevzpomenu si z hlavy, jestli je to C-raw nebo dual pixel raw, ale ty stejně nepoužívám.)

Na naprostou většinu mi stačí právě ten geeqie. Tu výraznou menšinu, se kterou si chci trochu víc pohrát, stejně proženu nějakým workflow (původně ufraw plugin + GIMP, později RawTherapee + GIMP, teď se snažím přeučit na to, že udělám co nejvíc práce v darktable a na GIMP už ideálně ani nedojde) a výsledkem je obvykle JPEG, občas TIFF. Tu ještě menší část, kterou chci ukázat někomu dalšímu nebo někde prezentovat, zpracovávám do JPEGu. Pokud bych měl někdy v budoucnu důvod použít jiný výstupní formát, třeba nějaký budoucí JPEG XXL, pak ho budu generovat opět z těch původních raw souborů, rozhodně ne z toho JPEGu.

Ano je teoretická, ale to že podporu třeba webové prohlížeče zahodí není zas tak nereálné.

Na základě zkušeností z posledních třiceti let si troufám tvrdit, že pravděpodobnost, že za dvacet let běžně používané prohlížeče nezobrazí JPEG, je mizivá. A ani na to, že ho nezobrazí za třicet let, bych peníze nevsadil, to mi spíš přijde reálnější, že do té doby přestane být aktuální web, jak ho dnes známe. Jestli ho nezobrazí za čtyřicet let... možná, ale jsem realista, takže počítám s tím, že mne už to velmi pravděpodobně trápit nebude.

Než bude téměř každý klient podporovat av1 hardwarově, načekáme se ještě hodně dlouho. To bych nebral jako argument pro ani proti avifu.

Klient potřebuje jen dekódování. To maj všechny formáty rychle i v software implementaci.

17. 4. 2023, 22:27 editováno autorem komentáře

Což není ale pravda, protože JPEG-XL umí narozdíl od AVIF progresivní dekódování. Takže když budete mít třeba 20MB fotku tak u AVIF se musí stáhnout celá až teprve ji můžete vykreslit (mají snahu s tím něco udělat, ale protože to není obrazový formát, tak s tím moc nenadělají) oproti tomu JPEG-XL můžete průběžně vykreslovat a dodávat obrázku detaily v průběhu dekódování.
Dokážu si představit, že by tohle šlo využít i pro náhledy, kde se přenese jenom část obrázku a zbytek až když bude potřeba.

Obávám se, že HTTP nemá žádný mechanismus, kterým by klient mohl říct "přenes mi jen první část obrázku a další až ti řeknu". Takže nešlo.

Co pro to (náhled a dohrát) ale využít teoreticky šlo je atribut srcset tagu img, který pak funguje se všemi formáty.

Teoreticky má, range. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range

Ale bylo by to hodně requestů.

Obávám se, že HTTP nemá žádný mechanismus, kterým by klient mohl říct "přenes mi jen první část obrázku a další až ti řeknu"

Říci si o část souboru můžu (a nemusí být ani od začátku), ale musím předem znát rozsah, který mne zajímá. (A je na serveru, jestli mi pošle jen ten kus, o který jsem si řekl, nebo všechno.)

Tak jo. Už se těším, až budu na našich dockerových kontejnerech někde v Azure řešit, jestli umí hardwarově AV1.

To bude záležet, jestli ten docker vidí GPU a jestli ta GPU má příslušný obvod.

Pardon, zase jsem přecenil diskutéry na rootu. Samozřejmě, že jsem po kompresi zkontroloval, jestli vidím nějaký rozdíl v kvalitě mezi původními a novými obrázky. Jinak by ten test neměl žádný smysl, to snad dá rozum.

To jste kontroloval očima? Na jednu stranu je to ve výsledku často to nejrelevantnější, na druhou stranu to má svoje mouchy:

1. Různí lidé to budou hodnotit různě.
2. Trvá to => můžete zkontrolovat omezený vzorek.
3. Dejme tomu, že předchozí dva body zanedbáme. Byl jste schopen konverzí do jiného formátu snížit zabraný prostor o X %. Ale možná by pomohlo i jen snížení kvality komprese JPEG. Pak by nejspíš moderní formáty měly stále výhodu, ale ne už takovou.

ad 1) Zobrazoval jsem střídavě původní a nový obrázek a sledoval, jestli si všimnu nějakých změn. Nevšiml.

ad 2) Artefakty vznikající příliš vysokou kompresí nejsou náhodné, ale objevují se v určitých situacích, typicky na jemných přechodech. Tedy pokud mám pár takových fotek a zkontroluju je, je dost pravděpodobné, že se nevyskytnou ani jinde.

ad 3) Přesně. To říkám lidem, kteří tvrdí, jak hrozně killer feature je ušetření místa - že pokud by lidi chtěli nutně šetřit místo, stačilo by často snížit kvalitu ukládání.

Ale co když lidi nechtějí ztrátovou kompresy (jako například já)? To, že nyní nevidím detail např. na FullHD monitoru s mizernýma barvami neznamená, že za 10let na 8K monitoru se nádherným podáním barev to vidět nepůjde. Nebo to budu chtít za pár let upscalovat a vylepšit pomocí AI. Nechci obětovat ani jediný bit.

Potom je nejlepší se vykašlat na JPEG ať s XL či bez a držet původní RAWy spolu s receptem pro vyvolávací SW. To je nejlepší způsob, jak nepřijít ani o bit informace.

Ad 2) To se může lišit s různými kodeky.
Ad 3) Jenže to vám trošku háže vidle do porovnání úspory místa. Protože základ nebude nutně původní JPEG, ale možná o něco více zkomprimovaný JPEG.

ad 2) "Může" se ledacos. Podstatné je, jestli se to opravdu děje.

ad 3) Jak píšu, nebyl to žádný rigorózní test, byl to test "kolik místa bych ušetřil, kdybych zkomprimoval svoje fotky".

Jenže když se za pár let najde jiný, ještě lepší, ztrátový formát, tak další ztrátovou re-kompresí už můžete přijít o cenné detaily. Ale protože máte už jen předchozí stav, tak s původním to nesrovnáte. Kolikrát to můžete ještě zopakovat, než z fotek uděláte 4K mazanici?

Podívejte se na nějakou vědeckou publikaci o archivaci fotek. Zjistíte, že každou fotku má archiv uloženou alespoň dvakrát - formát na prohlížení a původní foto. Pokud by hrozilo, že původní formát nebude dlouho podporován, tak se bezztrátově konvertuje na aktuální. Na velikost se nehledí. Takže takový JPEG-XL díky bezztrátovosti u JPEGů má sakra výhodu proti ostatním.

Zjistíte, že každou fotku má archiv uloženou alespoň dvakrát - formát na prohlížení a původní foto. … Takže takový JPEG-XL díky bezztrátovosti u JPEGů má sakra výhodu proti ostatním.

To ale automaticky předpokládáte, že původní formát je JPEG, což mi nejde moc dohromady s požadavkem na maximální kvalitu a "na velikost se nehledí".

Pokud se jedná o fotografie, tak tu máme obvykle výběr: RAW a JPEG.

Celá diskuse je o tom, že žádný nový formát není (dostatečně) lepší než 30 let starý JPEG. Opravdu chcete operovat s tím, že se každých pár let podaří prosadit "novému a lepšímu" formátu ztrátové komprese a já budu obrázky pořád překonvertovávat? Navíc aby váš scénář dával smysl, tak by každý takový další formát musel umět ztrátově komprimovaný obrázek rekomprimovat bez další ztráty informací na menší objem a to je prostě technicky nereálné. JPEG XL tak může činit jen kvůli malé efektivitě původního JPEG.

Pokud se na velikost nehledí, proč bych měl vůbec ty JPEGy do nečeho konvertovat? Že by JPEG přestal být podporován je opět dost nereálný scénář. Doteď v Photoshopu otevřu BMP, PCX, TGA, ...

Prostě jsou dvě možnosti:

A) Záleži mí na každém bitu. Potom uchovávám bezeztrátově komprimovaná data - buď přímo surový RAW, nebo je pro toto v grafickém světě etalonem 16-bit TIFF. Něco "pro domácí žvýkání" v menší velikosti / barevné hloubce vyrobím z tohoto masteru. Pokud bych náhodou musel měnit tenhle BFU formát, tak to prostě znovu vyexportuji z původních dat. Tedy možnost takový formát bezeztrátově zkonvertovat ze staršího nevyužiji.

B) Na nějakém bitu mi nesejde. Mám archiv v JPEGu a když by nááááhodou začal mít problémy s adopcí, tak ho překonvertuju do toho, co zrovna frčí a že dojde k nějaké lidským okem nepostřehnutelné ztrátě kvality je mi celkem jedno. A divil bych se, kdybych tohle musel dělat víckrát, než dvakrát za život. Dost možná ani jednou. Opět možnost bezeztrátové konverze není moc zajímavá.

Celá diskuse je o tom, že žádný nový formát není (dostatečně) lepší než 30 let starý JPEG.
Ne tohle je nesmysl v podstatě všechny nové formáty jsou dostatečně lepší než JPEG ale jde o podporu napříč vším.
Opravdu chcete operovat s tím, že se každých pár let podaří prosadit "novému a lepšímu" formátu ztrátové komprese a já budu obrázky pořád překonvertovávat?
To právě nikdo nechce.
Pokud se na velikost nehledí, proč bych měl vůbec ty JPEGy do nečeho konvertovat? Že by JPEG přestal být podporován je opět dost nereálný scénář. Doteď v Photoshopu otevřu BMP, PCX, TGA, ...
Proč používat JPEG místo RAW? Proč používat AV1 místo MPEG-2? To je úplně stejně nesmyslná otázka.

A) Záleži mí na každém bitu. Potom uchovávám bezeztrátově komprimovaná data - buď přímo surový RAW, nebo je pro toto v grafickém světě etalonem 16-bit TIFF. Něco "pro domácí žvýkání" v menší velikosti / barevné hloubce vyrobím z tohoto masteru. Pokud bych náhodou musel měnit tenhle BFU formát, tak to prostě znovu vyexportuji z původních dat. Tedy možnost takový formát bezeztrátově zkonvertovat ze staršího nevyužiji.
Zdrojová data již mám. Takže tenhle tenhle bod je úplně mimo.

B) Na nějakém bitu mi nesejde. Mám archiv v JPEGu a když by nááááhodou začal mít problémy s adopcí, tak ho překonvertuju do toho, co zrovna frčí a že dojde k nějaké lidským okem nepostřehnutelné ztrátě kvality je mi celkem jedno. A divil bych se, kdybych tohle musel dělat víckrát, než dvakrát za život. Dost možná ani jednou. Opět možnost bezeztrátové konverze není moc zajímavá.
Tohle je totální blábol. Když těch ztrátových kompresí uděláte několik, tak už to bude postřehnutelné. Navíc ztrátová komprese na již ztrátové kompresi již nemusí být tak účinná.

JPEG byl dostatečně dobrý formát v posledních cca 20 letech. S nástupem opravdu (až nesmyslně) velkých obrázků a různých HDR, produkovaných nezřídka instantními fotoaparáty v mobilních telefonech, za usilovného přispění umělé inteligence už ve snímacím čipu, vyhovujícím být přestal.
Reálně jsou zhruba čtyři možní nástupci, přičemž v podstatě jen dva jsou reálně k použití: WebP a JPEG XL. Přijde mi, že ten druhý je pro běžné účely lepší.
Otázkou tedy zůstává, který z formátů se nakonec stane JPEGem pro HiRes HDR obrázky.

Historie formátů ukázala, že nemusí vyhrát ten lepší. Google svůj formát má, Apple svůj formát má, Microsoft tohle moc neřeší, tak uvidíme, jak to dopadne.

Právě v tom vidím hlavní problém: Google svůj formát má, Apple svůj formát má, Microsoft.... Všechno to jsou velcí hráči a obávám se situace, kdy zase budeme optimalizovat programy a weby pro jednotlivá zařízení - jako se dělo v dobách Internet Exploreru.

To děláme už teď. Proto jsou Macy tak "oblíbené" mezi vývojáři (web, desktop, mobile). Protože tam odladí Safari/Chrome/Ed­ge/Firefox (desktopová a mobilní verze), macOS/Windows/Linux (i když Linux už jede nativně, tak VM je pohodlnější) a iOS/Android (mimochodem na tomhle umřel WindowsPhone - nešlo vyvíjet na macOS a dualboot byl pro "BFU" vývojáře zbytečná komplikace). Nově je Mac s Apple Silicon vývojářský nástroj i pro největší cloud - Amazon a jeho procesory Graviton, na které postupně přechází. Microsoft taky přidává podporu ARM, zatím vydal devkit, aby se vše naportovalo.

JPEG umí obrázku o straně 64k pixelů, to stále bohatě a bohatě stačí. Co se týče HDR tak mám dojem, že moc nevíte, co to znamená :-)

Pokud to bylo na mne, tak to znamená High Definition Range a jde (zjednodušeně!) o mapování rozsahu do daného bitového prostoru.
Jenže výrobci těch chytrých krabiček to používají jako zaklínadlo pro větší bitovou hloubku, případně i postupy, jak odstranit šum z fotek zpracováním sekvence snímků...
JPEG sice umí hodně velké obrázky, ale trpí některými nectnostmi právě u té bitové hloubky - a obecně mívá problém i s různým mapováním do osmi bitů (sRGB, AdobeRGB...). Alespoň část z toho právě JPEG XL umí řešit.

No výborně. Takže se shodneme, že pro velikost obrázku natož pro HDR JPEG není reálně limitací.

Barevná hloubka je jiná věc. To se u foťáků řeší RAWem, pokud chci v té hloubce víc pracovat, tak TIFFem. Nicméně finální 16-bit výstupy se mimo profi grafiku nepoužívají, takže tam JPEG opět stačí.

> Zdrojová data již mám. Takže tenhle tenhle bod je úplně mimo.

Tak proč řešíte nějakou konverzi z JPEG do JPEG XL a nevygenerujete JPEG XL ze zdrojových dat? Navíc vám tohle dá lepší výsledek, pokud nový formát bude mít lepší možnosti (například vyšší barevnou hloubku).

> Když těch ztrátových kompresí uděláte několik, tak už to bude postřehnutelné.

Můj argument byl, že těch konverzí bude něco mezi 0 a 2 a to fakt není problém.

> Navíc ztrátová komprese na již ztrátové kompresi již nemusí být tak účinná.

Mě AVIF dokázal zkomprimovat bez znatelné ztráty kvality JPEGy na 7% původního objemu. Zdá se vám do nedostatečně účinné?

Tak proč řešíte nějakou konverzi z JPEG do JPEG XL a nevygenerujete JPEG XL ze zdrojových dat? Navíc vám tohle dá lepší výsledek, pokud nový formát bude mít lepší možnosti (například vyšší barevnou hloubku).
Zdrojová data je ten právě ten JPEG.
Můj argument byl, že těch konverzí bude něco mezi 0 a 2 a to fakt není problém.
Ano je to problém, protože každý ten algoritmus komprimuje trochu jinak.

Mě AVIF dokázal zkomprimovat bez znatelné ztráty kvality JPEGy na 7% původního objemu. Zdá se vám do nedostatečně účinné?
Bez znatelné ztráty kvality je velmi subjektivní. Tak sem ten soubor nahrajte ať se můžeme podívat na tu nádheru. Důležitý je poměr kvality komprese a velikosti ne pouhá výsledná velikost.

Kdyby ale byla zdrojová data cokoli jiného než JPEG, tak tenhle number-one argument padá ;-)

> Zdrojová data je ten právě ten JPEG.

Měl jsem na mysli ta data, u kterých tak hrozně záleží na tom, aby se neztratil ani jediný bit.

> Ano je to problém, protože každý ten algoritmus komprimuje trochu jinak.

Ano, je to problém zvlášť u toho případu, kdy to nebudu konvertovat ani jednou :-D