Hacker News new | ask | show | jobs
by mort96 1183 days ago
Or is it their desire to be slightly careful about which image formats they have to support in perpetuity? With AVIF you get to re-use a bunch of your AV1 decoding code too. And the reference JPEG-XL decoder is still on version 0.x, with no sign that they'll make a stable release any time soon.

Why everyone is all up in arms about the fact that the industry is finally standardizing on a good royalty-free image format is beyond me.

2 comments

AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. It especially has trouble with lossless.

If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.

> AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec.

Image encoding is a subset of video encoding, so any limits are mostly arbitrary, and in AV1's case image-only encoding was a consideration from the start. AVIF in particular supports color depths up to 12 bits, wide color gamuts, many color spaces and standards for color space signaling, etc., so I'm curious what aspect you consider limited.

> Image encoding is a subset of video encoding

This isn't true. There are a number of things that make sense for images but not videos. 1. Progressive rendering. 2. Big images (up to 2^30 by 2^30) 3. More channels (up to 4099) (this can be useful for transparency, depth, or tracking random other things for scientific purposes) 5. High bit depth (up to 32 bit) (this is mostly useful for sciency stuff) 4. Lossless encoding. Basically no one wants lossless video (it's way too big), but lossless images often make sense.

Also images use a wider range of resolutions. AV1 has a minimum 4x4 block size (compared to 2x2 for jpeg-xl) which will hurt it for small images (e.g. icons). For example, The ycombinator icon is 18 by 18 pixels which would make AVIF store a 20x20 image which is 23% more pixels. (I can't find a source but I think I remember hearing that AV1 actually has a minimum size of 64x64 but I can't find a source for that)
I can think of a few aspects where avif is limited.

12-bit is fine for delivery, but it's not enough for authoring. Cameras are typically 14-bit and during authoring you'll want some footroom on top of that.

Also avif is not usable for lossless: it is slower than png and often worse. Lossless is crucial for authoring workflows.

For high-fidelity lossy compression, avif can be worse than even jpeg.

Avif cannot do CMYK at all, so for printing use cases it is not usable.

Basically it is targeted at web delivery, but it's not really a general-purpose image format that can be applied in a broad range of use cases.

Seemingly half or so of images delivered anywhere currently are VP8-image (webp). You'd expect those to be AVIF instead in the coming years, which is obviously very much superior.

Forget lossless originals, this is about the average images that users see online, like 1000x1000 (or smaller) and 200kb (or so).

The key part is support for real-time hardware decoding. You can't have parts of images refer to far-off parts to save on redundant encoding, and your budget for calculation time and complexity is relatively small.
JXL offers re-encoding of existing jpeg at smaller size with no quality loss, and has an efficient progressive mode.

As the head of tech for a site with a few tb of user-supplied jpeg files (which are thumbnailed), I can see the appeal…

Not just no quality loss. Byte-for-byte identical
If something is 'byte-for-byte identical' wouldn't it be the same size?
It's byte for byte identical once you expand to an array of pixels. The storage format uses more advanced (lossless) compression, but the pixels that come out are identical.
When you transcode back to JPEG, the JPEG is byte-for-byte identical to the original JPEG. But if you decode to pixels you do not always get identical results as the JPEG because the JPEG standard does not specify bit-exact decoding and different decoders may differ slightly.