Názory k článku
GIMP 2.10.34 nabízí export do JPEG XL ve stabilní verzi
-
Jop, prohlížeč a server si vyjednávají třeba formát ve kterém se obrázky pošlou.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation -
Vite kolik ruzneho kodu je treba v linuxovem kernelu a presto je nikdo nechce udrzovat? Mate lehce naivni predstavu ze to tam jenom tak nekde v kodu je a nic se nemeni. Meni se veci kolem ktere mohou mit dopad na ten dekoder. Z pohledu provozovatele webu je nesmysl abych resil dalsi verzi obrazku kdyz zadnou killer feature neprinaseji. Vetsi maximalni rozmery nez jpeg? Ukazte mi prohlizec ktery zvladne zobrazit stranku s jpegem v maximalnich rozmerech. Lepsi barvy? V situaci kdy 60% uzivatelu ma monitor za $150 je to nezajimave. Mensi velikost? Ano, ale soucasne musim podporovat kvuli kompatibilite i jpeg takze naopak zvysuji sve naklady na storage, bandwidth,… 99.9999% obrazku na internetu si vystaci s existujicimi formaty a tech par kde by se dal vyuzit potencial jpeg xl proste ma smulu, z pohledu prohlizece se to proste nevyplati.
-
L.Stříbrný podporovatel
Přesně tak. Pokud tam ta featura je, tak se prostě musí regresně testovat, i když si myslíme, že se "nemohla" rozbít, upravovat při změnách API, atp.
Už se to tu řešilo několikrát. JPEG XL přináší významnou výhodu jen v malém procentu případů a proto se s největší pravděpodobností neprosadí. Google s tím nemá co dělat.
-
Až na to, že to co jsi zmínil není jediná Killer feature a je celkem nepodstatná. Ale zároveň jsi zmínil jeho hlavní výhodu oproti ostatním akorat jsi to totálně zamotal. Do jpeg xl lze snadno zakódovat jpeg. Takže nejen, že ušetří bandwidth, ale i ušetří náklady na storage protože ti stačí uložit obrázek v jpeg xl a původní jpeg z něho snadno dostat. Z pohledu prohlížeče se jpeg xl, narozdíl od avif nebo webp, rozhodně vyplatí a to už jen kvůli své univerzálnosti.
-
> ale i ušetří náklady na storage protože ti stačí uložit obrázek v jpeg xl a původní jpeg z něho snadno dostat
A ako? Klient, ktory nepozna jpegxl, z neho povodny jpeg nedostane. Takze to musi urobit server.
No a server, pokial je to nejaky s3-kompatibilny storage alebo staticky web, tak to robit nebude. Bude treba nejaky modul do webserveru alebo v cloude aspon lambdu, ktore to urobia pocas obsluhy requestu. A to uz zadarmo nebude, tam bude narastat cpu time. To bude mat moznost urobit 0.01% z webov. Ergo, vo velkom obraze je to nerelevantna ficura.
-
Nemusi to robit server může to klidně dělat JavaScript na clientu. Pokud client podporuje např. WebAssembly může to takhle fungovat skoro pro libovolný formát.
Ne nebude to mít možnost udělat zanedbatelné procento webů, protože to se již dnes běžně dělá.
Tohle, ale není to na co se snažím poukázat, protože tohle onfly encodování můžete dělat již nyní i pro další formáty. Ale rozdíl mezi tím je, že nepřijdete o původní JPEG. Kdežto když to uděláte třeba pro AVIF a originální JPEG smažete tak převodem AVIF od JPEG děláte další ztrátovou kompresy takže u všech těch formátů proběhne minimálně jedna ztrátová komprese, do toho formátu a pak druhá pokud zpět do JPEG, pokud chci mít jenom jeden soubor a ušetřit místo.
-
L.Stříbrný podporovatel
Škoda, že nelze spolehlivě zjistit, na kolika procentech webů ten JPEG XL máte implementovaný, když je pro vás tak zajímavý. Aneb jak říká Linus: "Talk is cheap, show me the code."
-
To je ale nesmyslná argumentace. Pokud ten formát nebudou podporovat prohlížeče, nedává smysl ho poskytovat na straně serverů. Pokud by ho prohlížeče široce podporovaly, tak to naopak smysl dává. Podívej se třeba na video v AV1. To je pro různé webové streaming platformy hodně zajímavá věc, ale kdyby to nešlo v browserech přehrát, tak by to prostě nikdo přes web nestreamoval.
-
L.Stříbrný podporovatel
To je ale nesmyslná argumentace. Pokud servery formát neposkytují, nemá smysl, aby ho prohlížeče podporovaly. Když by ho servery široce podporovaly, smysl to naopak dává.
JPEG XL lze používat i bez přímé podpory v prohlížeči, například pokud mám na webu galerii (kde je typicky víc obrázků a úspora by byla alespoň trochu znatelná), tak ta je často v nějakém JS. Tedy ten JS si může klidně stahovat obrázky ze serveru v JPEG XL, dekódovat a vložit je do IMG tagu jako raw data. Přesto se taková řešení (AFAIK) neobjevují. Protože překážkou není chybějící podpora v prohlížečích, ale (reálně) malé výhody JPEG XL oproti klasickým formátům. Píšu to už asi potřetí, stejně to někteří pořád nechápou...
Ono ani takový AVIF, který je podporovaný a teoreticky lepší než JPEG se moc nerozšířil, protože současný JPEG je prostě "good enough".
-
Tohle už vypadá jako trolling. Začít to pochopitelně musí na straně prohlížečů. Proč by někdo nabízel k prohlížení obrázky ve formátu, který se nedá efektivně prohlížet? Samozřejmě se dá nabídnout ten obsah jen ke stažení (to se dá s jakýmkoli formátem), ale to není masové využití. Jaké procento lidí si pravidelně stahuje z webu obrázky pro offline prohlížení a další zpracování? Stejně tak konverze v javascriptu na klientovi je nepraktické, komplikované a křehké řešení, nevím, jak tě to vůbec napadlo. Snad jestli považuješ moderní HTML5 <video> za nesmysl a vzpomínáš s láskou na Flash Player, pak tvou argumentaci chápu. To by vysvětlovalo mnohé.
-
L.Stříbrný podporovatel
Trollíte akorát vy, když chcete aby prohlížeč uměl formát, který mu servery neposílají.
S tím video tagem jste si hezky naběhl na vidle. Tam to právě bylo tak, že nejdřív byly Flash playery, případně animované gify. A teprve až se ukázalo, že o video v prohlížeči je zájem, tak prohlížeče implementovaly video tag. Vy to ale chcete přesně opačně - aby prohlížeče implementovaly něco, o co není zájem.
-
Dobře, Google ho nezastřelil, Google mu jen umístil kulku do srdce. To by myslím byla odpovídající metafora. Zkrátka Google vyhodil něco, co by jej stálo na údržbě asi tak biliardtinu celkových firemních výdajů a tím tu věc pohřbil pro takřka celý internet, protože průměrný uživatel prostě jede v Chrome nebo nějakém derivátu (myšleno Edge). V problému slepice-vejce tak jsme v situaci, kdy slepice nenese, takže se těžko může narodit další generace, tedy rostoucí podpora tohoto formátu. Třeba se mýlím, ale ...
-
L.Stříbrný podporovatel
Obviňovat Google ze zablokování růstu podpory JPEG XL pod zprávičkou která o růstu podpory JPEG XL informuje, to je tedy mistrovská úroveň double-thinku :-)
-
L.Stříbrný podporovatel
Přesně. To, že Chrome nepodporuje (out of the box) JPEG XL nevylučuje, aby ho podporoval někdo jiný. Tedy za nízkou adopcí JPEG XL nemůže Google, ale to, že ten formát prostě nepřináší dostatek zlepšení pro dostatečné procento lidí.
-
Přináší toho dost, prakticky by sám mohl nahradit tu trojici současných webových formátů pro rastrové obrázky. Když to zjednoduším na ty nejzákladnější vlastnosti, kvůli kterým se dnes používají tři různé formáty: JPEG XL umí bezeztrátovou kompresi a alfa kanál jako PNG, efektivní ztrátovou kompresi jako JPEG, animace jako GIF. Kromě toho se do něj dají všechny tyto formáty převést bez další ztráty informace. Ale pokud nebude podporovaný prohlížeči, tak se pochopitelně na webu používat nebude.
ČLÁNKY DO MAILU