Vlákno názorů k článku
Google přidává podporu AVIF do vyhledávání od martinpoljak - Tak jen škoda, že všechny kompresní knihovny, které...

Viděl bych to na pokus odstřelit konkurenci. Problémyy s tím asi nebudou žádné (proč taky). Thorium.rocks má mj. patch, kterým JPEG XL vrátil zpátky.

Reálně za tím byl nezájem o JPEG XL. Nějakou dobu v Chrome byl, ale stejně to jeho rozšíření nepomohlo. Mít takový složitý kód v prohlížeči je bezpečnostní riziko (jak ukázal zmíněný případ s FF implementací) a tak bylo rozhodnuto o odstranění, alespoň do té doby, než se ten formát více rozšíří.

Počet hvězdiček v ticketovacím systému je irelevantní, protože vzhledem k počtu uživatelů je zanedbatelný, podstatné bylo reálné (ne)používání té featury.

My, Google, pracujeme na našem, lepším, formátu. A tu se objeví těžká konkurence. Ten náš sice taky dohromady nikdo nepoužívá, ale ten konkurenční raději z prohlížeče vyhodíme, aby ho náhodou lidi používat nezačali a my můžeme dál tlačit ten náš.
Kdyby šlo o to, co chtějí spousty uživatelů, tak tam dají podporu HEIC (jasně, otázka licencí).
Mě je to celkem jedno: z mobilu mi leze HEIC, takže na web to musím převést - ale převádím do JPG, rozhodně ne WEBP.

5. 9. 2024, 07:58 editováno autorem komentáře

Tohle je prostě obyčejná lež. Ve stabilním Chrome ani Firefox nikdy nebyl a musel se zapínat feature flagem. Tak proč se přidalo AVIF a drive WebP. O AVIF zájem moc není ani teď, encodovaní je drahé a pomalé a musíte na to musí umět už přímo nějaký čip. WebP na to jak bylo tlačené po takové době, co tam je, taky žádný zázrak není. AVIF ani WebP nejsou formáty primárně určené pro obrázky ale vystříhané z videa tj. jejich výhoda je, že můžete lacině udělat náhledy z videa, když je ve formátu AV1 resp. VP8. Jak se může formát obrazků rozšířit, když není podporovány v browserech? Navíc ta odpověď nebyla až se ten formát rozšíří, ale jenom že o něj není zájem žádné až nebo nějaká podmínka ze strany Google nikdy nezazněla a ticket zavřen.
V diskuzi zájem jasně byl. Deklarovali ho Cloudinary ( které platí tvůrce) a Shopify, kteří podporu JPEG XL mají. Dále tam zazněla podpora od Meta, Intel.
Podpora JPEG XL se odebrala záhadně rychle v momentě, kdy ho začalo podporovat Adobe pro export s HDR a v návodu popsali jak ho v Chrome zapnout. Firefox jenom nechce dělat něco jinak než Chrome. Zajímavé je, že Safari tu podporu má a pomalu jí dostává celý Apple ecosystem.

Počet komentářů a hvězdiček v ticketovacím systému znamená, že zájem o něj je hlavně v komunitě vývojářů a znalých uživatelů, kteří, narozdíl od té masy uživatelů, s tím mohou něco udělat. Možná to pro tebe bude šok, ale většině je úplně zadku jestli je obrázek/fotka v GIF, WebP, AVIF nebo JPEG XL.

Zaznamenal jsem dva důvody nesubjektivního charakteru. Jeden důvod, že dekodér prý nepodporuje progresivní dekódování, tedy dekódovat a zobrazovat data po částech, jak se stahují. Dekodér se neumí na konci dat přerušit, uložit status v úsporné podobě, a později zas status načíst a pokračovat. Takže by trpělo UX. Druhý důvod tu zazněl dnes, že ten kód považují za rizikový, s potenciálními zneužitelnými chybami, a chtějí to přepsat do Rustu. Ale copak kód pro webp nebo avif není podobně "nový", neostřílený desetiletími hackerských pokusů, jako třeba jpeg?

A možná ještě třetí související důvod, že na webp (vp8) a avif (av1) jsou hw dekodéry, zatímco na jxl ne. To ovšem není důvod podstatný, snad jen kdyby to někdo chtěl pojmout skrz ekologii a spotřebu energie.

Spíš by mělo být, že AVIF a AV1 musí být HW dekodéry (aby to dávalo smysl), zatímco JPEG XL nemusí. To že zatím není HW dekodér pro JPEG XL ale neznamená, že nemůže vzniknout.

Jeden důvod, že dekodér prý nepodporuje progresivní dekódování, tedy dekódovat a zobrazovat data po částech, jak se stahují. Dekodér se neumí na konci dat přerušit, uložit status v úsporné podobě, a později zas status načíst a pokračovat. Takže by trpělo UX.
Tohle fakt nechápu. Progresivní dekódování právě JPEG XL narozdíl od AVIF umí. Naopak UX trpí tím, že se to celé vykreslí až když je to celé stažené a né v průběhu stahování. U toho progresivního dekódování by navíc šlo nastavit aby se stahovalo jenom 20% celého obrázku (např. pro náhledy). Ale nikdo nebrání aby se začalo vykreslovat jako s AVIF až po stažení a tím půjde navázat i přerušené stahování, i když mi není jasné proč by to někdo dělal.

5. 9. 2024, 14:19 editováno autorem komentáře

S progresivním dekódováním to je jednoduché:

- jpegXL jako formát to umí, data jsou uložená tak, aby se obrázek dal průběžně vykreslovat

- ukázková implementace tohle neumí, protože to pro tuhle fázi vývoje zatím nebylo potřeba

Nevím co je ukázková implementace, ale referenční to umí.