Hacker News new | ask | show | jobs
by CharlesW 1187 days ago
> 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.

3 comments

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