Hacker News Reader

Comment by xnx | Hacker News Reader

Visual quality, file size, compression time, decompression time, browser support, toolchain support, patent restrictions. Considering any one of those in isolation is insufficient for evaluating image formats.

View on HN

> Visual quality, file size, compression time, decompression time, browser support, toolchain support, patent restrictions. Considering any one of those in isolation is insufficient for evaluating image formats.

Additionally, use cases are critical for understanding which of these and other properties matter, as well as their relative importance. Authoring formats (e.g. Apple ProRes, DNG) are evaluated much differently than distribution formats (e.g. AV1, JPEG).

And not to forget the third category: storage/archival formats. JPEG XL is unlikely to get widespread browser support, but that doesn't mean it isn't a good format to store high qualitiy originals. Either because they never touch a browser (my image viewer supports JXL) or because all images go through the resizing proxy anyways.

Also features like alpha support, yuv444 support in addition to yuv420, progressive rendering are interesting. Do jxl and avif both have all of these?

Also 16-bit colors support! The fact that AVIF does not have it is a bummer (although, understandable given the fact AVIF is for a video codec, not for editing HDR images).

Honestly that plus the awful tiling behavior at relatively low resolutions should have been enough to disqualify it from being mangled into something resembling an image format. It was made and tuned for movies, not stills. But its image format gets to inherit all of the drawbacks of that initial use case, including awful encode/decode performance.

Wait, after decades they are introducing a new image format, and it doesn't even have HDR support?! But surely AV1 supports HDR, so why not AVIF?

Edit: According to this table, AVIF does in fact support HDR:

https://jpegxl.info/

There's a neat table on https://jpegxl.info/ which shows all features of both formats. In general JXL has more features than AVIF, although some of them may be more important for special purposes like medical imaging.

And I'm sure we can expect a perfectly unbiased opinion regarding the matter from jpegxl.info.

In which world are technical features like "how many channels the format supports" or "maximum bit depth" or "progressive decoding" opinions, exactly?

You can pick and choose which facts to present or misrepresent which/what is important but... that's not going on here. JXL is actually just better by very many metrics. It's only lacking in adoption. There's not something that jpeg-xl.info is ignoring or glossing over. This is just lazy cynicism.

I was mostly joking, but you can compare a skateboard and a car and make the skateboard look better if you just mention weight and pollution but not top speed, autonomy, etc.

Well, ok, that's a fair point: from this table alone you can't say anything about computational complexity or implementation difficulty. And I cannot honestly say anything about that. I agree that it's a valid question to ask.

I'm afraid that your first reply misfired a bit if that was what you wanted to get across though.

Very good and informative table indeed, great base from which to start the codec comparison, pity it's an image and not fully interactive with extra info

AVIF has progressive support in the spec, but it has not yet been implemented in an encoder and it is very likely going to be less dense than the non-progressive coding. My guesswork is that it will be ~10 % less dense than non-progressive once implemented, but it is just a guess with my pass experiences of other codec experiments trying to do such things.

Otherwise both formats have all features. JPEG XL is yuv444 by default whereas AVIF tends to favor yuv420 and some encoding/decoding hardware is going to be yuv420 only, so with AVIF one would often need to go software coding to get yuv444 quality.

Reply on news.ycombinator.com