JPEG XL vs. AVIF: A Comparison | Hacker News Reader

JPEG XL vs. AVIF: A Comparison

tonisagrista.com

28 pointsksec20 comments

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.

It would also be better to compute the min/max/avg difference of luma/chroma over the whole image than only do a manual comparison by eye.

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).

Beware the streetlight effect: https://www.discovermagazine.com/the-sciences/why-scientific...

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'm not okay with this because its author cherry picks images to compare.

> 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 would have been nice if a comparison to plain old JPEG was included so we had an idea of how much space JXL saves for the same quality.

I support the Chrome team with this one...

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.

A format cannot and will not get adoption until there is support. Who would sign off on using JXL when any of the large browsers don't support it?

This is a chicken-egg problem, not a popularity contest.

>Something like an image format should either be widely used (ie. At least 5% of websites use it), or it shouldn't exist.

>I support the Chrome team with this one...

WebP ......

WebP actually is pretty widely used... I suspect over half of browsing sessions load at least one WebP image.

And was WebP widely used before Chrome enabled support for it?

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.

Yes sorry jonsneyers. I was just trying to point out the obvious.

How exactly are you supposed to use a format that isn't supported?

How would 5% of sites ever get to use JXL if it isn't supported in web browsers?

By implementing the decoder in WebAssembly. It'd be lower performance than native decoding but probably not that bad.

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

Why is AVIF limited to 4k. Thats sound kinda arbitrary.

That's too limiting even for a video encoder

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).

How does that matter even anymore? Google removed JXL support.

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.

Dear Google, if you read dis, bring JPEG XL back to Chrome!

Reply on news.ycombinator.com