Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too.
Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
I'm not finding any. Mind listing them?
> Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
> I'm not finding any. Mind listing them?
I don't know much about JXL vs AV1 from a technical perspective, both seem significantly better than JPEG. But JXL has the practical advantage that it can losslessly recompress JPEG images for a size improvement without an image quality improvement. When converting JPEG to AV1, you're stuck decompressing the JPEG into raw pixel data, with JPEG artefacts and all, and then compress that pixel data with AV1, so you get the artefacts from JPEG and the artefacts from AV1. Decompressing the resulting AV1 image will result in different and almost certainly worse quality pixel data.
So the ability to do a risk-free lossless conversion from JPEG to a better format and get a size improvement is a pretty darn big domain that's not served by AV1.
Keyframes are still images embedded in the video stream.
Keyframes don't disappear with the next frame — they're the basis of all the delta (P- and B-) frames that follow until the next I-frame.
Also, AVIF does support features like progressive encoding/decoding¹, which may be the kind of "still image only" tradeoff you're thinking of.
¹ https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-...
Exactly this. P/B-frames are not encoded as a delta to the input I-frame; it is encoded as a delta to once compressed then decoded I-frame, otherwise errors in the I-frame will accumulate. So any imperfection in I-frames has a chance to be fixed by subsequent P/B-frames, but this is impossible in a still image.
You have a good point that AVIF layered image items can act like such P/B-frames. Do libavif (or other AVIF implementations if any) make use of them? JPEG XL has the same feature (zero-duration frame) but I think libjxl doesn't use it to encode a residue when the input image is not animated---in fairness such residues are very hard to compress though.
Seemingly! https://github.com/AOMediaCodec/libavif/blob/main/CHANGELOG.... inclues the notes "Support for progressive AVIFs and operating point selection" and "Update the handling of 'lsel' and progressive decoding to AVIF spec v1.1.0" in 2021.
Getting a cache miss with Cloudinary on large avifs can sometimes result in a multi second delay while they’re generated
Lack of JXL support is going to cost sites that server huge numbers of images e.g. Cloudinary millions of dollars in extra compute power
For about 10 years I have been thinking about new file image file formats, it wasn’t until last year that I started really using them. For the web there is the cost of data transfer and the cost of data storage. You can save on data transfer by adding more files in more formats but you pay more in storage cost. To fully realize the economy of better file formats you need to retire JPEG and not add more files.
I finally got convinced that WEBP was supported well enough that it was worth using 𝐚𝐧𝐝 that the image quality was really good with small files. I learned that the disadvantages of new file formats that claim to compress better are real but the better compression isn’t always real. I see people write a blog post where they compress three sample images but a real evaluation project is a lot more than that.
So the world may well be better off with a second-best file format that people really use than being stuck with JPEG because people are struggling to make up their mind about what new format to use, support, etc.
No one wants this. The benefits just don't outweigh the headaches in compatibility and content duplication. JPEG is good enough, and always has been. We'll all be happier by celebrating such a impactful technology than grousing and constantly trying to fix what ain't broken.
JPEG for lossy image formats, PNG for lossless.
If anything, SVG is the one image format most in need of replacement.
ISOBMFF is also used for MPEG-4, AV1, etc. If nothing else, the world appears to have settled on a flexible, extensible container format that can support any future media formats we can come up with.
Apple has also shipped AVIF support in iOS 16 and Ventura, and AVIF-enabled Safari in the same.
HEIF support was never enabled in Safari. Still isn't.
There is no war. HEIF support was mostly a way to optimise storage on iPhones.
I don't see this changing either, most browser vendors are going to decide that AVIF is good enough and not pay to license the HEIF patents from the MPEG group.