I'm not okay with this because its author cherry picks images to compare. Those might as well be an outliers. It'd be more convincing when comparing 10k images gallery with a variety of image types, like photos, paintings, sketches, manga, real objects, textures etc and then averaging.
Also subjectively the AVIF lossy compressed flag pic looks better to me because it has less noise, I don't really care about it being more "true" to anything in such use-cases.
The whole point of lossy compression is to lose numerical information in a way that doesn't lose visual information. Computing the amplitude of the numerical loss is not very relevant, since it's the visual loss that matters (and those two things are only weakly correlated).
It isn't. The baseline profile is limited to 9 megapixels, the advanced profile is limited to 36 megapixels, but you can also have a valid avif file that doesn't conform to any profile and that is larger. For software decoders that will not be a problem. Hardware decoders in consumer devices will likely most typically be limited to the baseline profile: only 4:2:0, at most 10-bit, and at most 9 megapixels (e.g. 4K). Tiling can be used to combine several independent bitstreams in a single AVIF; there might be visible seams at the tile edges though.
It's a limitation that makes a lot of sense for a video codec — video requires hardware decoding to keep battery consumption sane, and hardware decoding requires a limit to the frame size since hw implementations need bounded SRAM buffers (and the cost in gate count is more or less proportional to the max frame size).
Something like an image format should either be widely used (ie. At least 5% of websites use it), or it shouldn't exist.
A format existing has a maintenance cost, a security cost, an extra barrier to people designing new browser's or web technology, etc. If fewer than 5% of sites use it, and all features can be achieved another way, then it simply isn't worth keeping support.
Sorry JPEG XL... You were a nice design, but ultimately you weren't popular enough. A bit like Server Push (web server can send your client data you'll need ahead of time saving a round trip), ScriptProcessorNode (JavaScript can mix/make audio realtime) and DANE (security with no certificate authority)... All cool tech that didn't manage to find a userbase.
WebP was supported in Chrome about a decade before it became widely used. It was even already supported before the format was even finalized: lossless and animation were added after the first (lossy-still-only) WebP support was enabled in Chrome.
22 comments
[ 5.0 ms ] story [ 53.6 ms ] threadAlso subjectively the AVIF lossy compressed flag pic looks better to me because it has less noise, I don't really care about it being more "true" to anything in such use-cases.
Such metrics are easy and tempting but one should make sure that they actually correspond to something that matters.
A similar point is made by Zoltan Dienes in his 2008 book “Understanding Psychology as a Science”: https://pbs.twimg.com/media/Ff_BUhTXEAAZZrA?format=png&name=...
> I don't really care about it being more "true" to anything in such use-cases.
I guess I finally understand the reason why AOM has so many support from a "technical" side of things.
It's a limitation that makes a lot of sense for a video codec — video requires hardware decoding to keep battery consumption sane, and hardware decoding requires a limit to the frame size since hw implementations need bounded SRAM buffers (and the cost in gate count is more or less proportional to the max frame size).
https://news.ycombinator.com/item?id=33399940
JXL is pretty amazing - as has been JPEG from a speed/compression perspective. Really sad to see it die like this.
Something like an image format should either be widely used (ie. At least 5% of websites use it), or it shouldn't exist.
A format existing has a maintenance cost, a security cost, an extra barrier to people designing new browser's or web technology, etc. If fewer than 5% of sites use it, and all features can be achieved another way, then it simply isn't worth keeping support.
Sorry JPEG XL... You were a nice design, but ultimately you weren't popular enough. A bit like Server Push (web server can send your client data you'll need ahead of time saving a round trip), ScriptProcessorNode (JavaScript can mix/make audio realtime) and DANE (security with no certificate authority)... All cool tech that didn't manage to find a userbase.
This is a chicken-egg problem, not a popularity contest.
>I support the Chrome team with this one...
WebP ......
How would 5% of sites ever get to use JXL if it isn't supported in web browsers?
Here's one: https://github.com/niutech/jxl.js
Demo: https://niutech.github.io/jxl.js/
Libjxl's own WASM build: https://github.com/libjxl/libjxl/tree/main/tools/wasm_demo