Hacker News Reader

Comment by shmerl | Hacker News Reader

AVIF I think is already well on the way. HEIC is DOA.

AVIF is supported on pretty much every modern browser now. Even Safari is adding support for it with the upcoming Safari release.

At this point AVIF vs JPEG XL is a more interesting discussion than anything vs HEIC.

Accurate. My experience (as someone who has encoded a lot of both AVIF and JPEG XL images) is that JPEG XL tends to have superior detail preservation at medium to high bitrates, as well as preserving grain significantly better at all bitrates. It's also slightly less prone to banding than AVIF, but more prone to noticeable artifacting on sharp edges, which only goes away at higher bitrates.

It's pretty clear at this point that JPEG XL is a superior codec for e.g. photography. I think the question is going to be whether the browsers decide that it's worth supporting on the web, where lower quality images are the norm.

Some comparison images: https://afontenot.github.io/image-formats-comparison/#eaglef...

In many categories of photos or images, JPEG XL [1] actually does better than AVIF in low bitrate settings. Which is the only advantage AVIF has over JPEG XL. And I am increasingly convinced that not losing details is the correct solution rather than smoothing things out in AVIF.

With progressive decoding, JPEG XL is also much a better fit for the web.

I just dont see how we continue to ignore JPEG XL and want to force AVIF adoption everywhere, when XL is technically superior, including encoding and decoding complexity. We literally have representatives from different companies and industries, most have been silent in the image / video codec format war begging for browser vendors to support JPEG XL.

But of course the cult and ideology somehow had people convinced the only accepted codec are AVIF, AV1 and Opus.

[1] https://twitter.com/jonsneyers/status/1563442356493230080

> In many categories of photos or images, JPEG XL [1] actually does better than AVIF in low bitrate settings.

It's not really consistent, but at small sizes JPEG XL sometimes falls apart, especially if the image contains a lot of smooth textures and clean lines that are easily compressed by AV1. https://afontenot.github.io/image-formats-comparison/#air-fo...

I don't think you need any kind of conspiracy here, AV1 is an open codec after all. The problem is more that (a) AVIF has been around for longer, (b) browsers have to implement most of the spec anyway because they need to have AV1 support, and (c) the hardware decoding story for AVIF is probably going to be better for quite a while, given its closeness to video. AV1 is still a great codec, and Opus is best-in-class for general purpose audio.

Also, I agree with you that optimizing an image codec for high quality use cases is the ideal, but a lot of casual users prefer blurred images with missing detail to noticeable artifacts.

One of the surprising fact from Cloudflare stats, was that most image on the web are actually 0.7bpp+ with the median being 1.0bpp. So image with 0.24bpp is surpassing small. And that is where progressive decoding works best, showing 0.3bpp image at launch while continue to download other details. There are problematic scenarios with JPEG XL, but I think a lot more could be optimised with encoder once they have 1.0.

Do you have a link for this? I tried searching for it but couldn't find any details. Mostly I'm wondering if those numbers include just JPEG or also include other formats. E.g. including PNG would tend to drag the median / mean up. Also, if sites are currently using 1.0 bpp JPEGs, I can only assume that they'll want to reduce sizes further when switching to a better codec, since 1.0 bpp is quite low for JPEG.

Note that there are samples where JPEG XL still has way too many artifacts at e.g. 1.3 bpp: https://afontenot.github.io/image-formats-comparison/#pont-d...

I do agree with you, though, that if a site is targeting 1.0 bpp or more, they're usually going to see better results with JPEG XL than AVIF.

> progressive decoding

If I'm not mistaken, it isn't enabled by default for JPEG XL and reduces the encoding efficiency by about 10%.

Late to Reply ( It was Chrome, not Cloudflare, which is arguably more representative )

https://www.spiedigitallibrary.org/conference-proceedings-of...

Figure 1

> The number of transferred bytes is important because it affects the latency and hence the user experience. Using this estimate, we calculated that between June 1st and 28th, 2019, the average BPP (weighted by the number of bytes transmitted with that BPP) was 2.97, 2.24 and 2.03 for small, medium and large images, respectively. We confirmed that there was no considerable difference between mobile and desktop platforms. This data indicates that image compression algorithms should target rich images with a relatively high BPP values, aiming to produce 1 BPP images almost free of artefacts instead of 0.5 BPP images with artefacts that are not too intrusive.

This is excellent, and does indeed suggest that JPEG XL should be broadly preferred in the browser. Thanks for the reference.

As a hobby photographer, this is a deeply interesting topic. I keep all my scans (yes, film still exists) as TIF files, but my clients don't know what to do with a TIF (and even fewer know how to tell a printer that the image uses a particular colorspace) so I usually send them the TIFs, plus some high-quality JPEGs. Why not HEIC/AVIF/etc? Because people know what a JPEG is.

Why TIF vs for example PNG? Are there any benefits?

At least some camera raw files are also TIFF under the hood, e.g. Canon's CR2. TIFF also natively supports more than 8 bits per color channel, so you can still edit the photo and don't necessarily lose information in the process, whereas a single exposure adjustment on a PNG could lead to clipping and irrecoverable highlights or shadows.

EXIF is a TIFF file. I think most modern JPEG files are EXIF packages. A quick way to check, is to look at the first two bytes of a file. They are sort of a “BOM marker,” and will be either “II” or “MM”.

TIFF is really a package format. It’s so flexible, that it’s damn near impossible to write a “full-fat” TIFF reader (I’ve done that. Never again).

TIFF is so flexible, that you can define an image to have a 6-bit R channel, and a 12-bit G channel, for instance. I think some medical or scientific images may have actually done that.

You can also have pretty much any type of compression that you want, for the image data.

But most people use TIFF to store uncompressed “raw” image data. These files can be crazy big, but also won’t have compression artifacts.

Do you have any more information about this? I thought CR2 was floating point. Any details about how they store the mosaiced data in a TIFF would be very interesting, I assume.

I’m under the impression that TIFF is lossless (like FLAC) while png is lossy (like ogg).

PNG is not lossy. However, it doesn't support metadata anywhere nearly as well as TIFF, so I still use that for lossless photography storage.

Ah there you go! Didn’t know that :)

TIFF is a container. The payload it contains can be uncompressed, compressed losslessly with lzw//deflate/lzma/zstd, but it can also be lossy compressed with JPEG, WebP or even JPEG XL.

Meanwhile, PNG is always compressed, lossless.

Ogg is a container, you can have lossless FLAC in ogg.

I also didn’t know that! Thanks for letting me know

Lossless jpeg xl could be a good choice for perfect archive copy, if needed. no idea about metadata though

Is it enabled by default in Firefox yet? I've just tried:

https://libre-software.net/image/avif-test/

on two Linux machines with Firefox 105, and both showed the alt image text, so I guess maybe not, although it's showing up as enabled in about:config.

Edit: https://avif.io/ seems to work and display converted .jpg files, so maybe the first URL is old and doesn't work.

The first URL doesn't even show the fallback JPEG for me on Firefox for Android so there's probably something else interfering with the use of that website.

My browser seems to render AVIF just fine on Ubuntu and Manjaro, with Nvidia and Intel GPU backends. If it works with hardware acceleration on top of Nvidia's shitty drivers, I assume it'll work everywhere.

I've heard some old bug reports about colour management and AVIF not working together well in Firefox, that was the reason support had been baked in for a whole but the format was still locked behind a flag. I suppose they fixed that now that they enable the format by default.

The avif image URLs of these page are broken. at least, give me a nice 404 page

Firefox supports AVIF out of the box for a while already.

Only still images apparently. Not supported in Safari yet (though its coming) and Edge has no support:

https://caniuse.com/avif

HEIF doesn't work in any web browser:

https://caniuse.com/heif

What's the point of animated AVIF vs for example AV1 video file?

My guess is as a drop-in replacement for GIF; use the <img> element instead of the more complicated <video> element, an inherent lack of audio, no need to specify looping or lack of video controls, etc.

I think Safari already supports using at least one actual video format as the `src` in an <img> element but it's weird to do so.

I vote for JPEG XL. The fact that you can completely eliminate things like imagemagick or 3rd party scaling workflows (simply retain the max-size original and truncate the stream proportional to the pixel area requested!) is huge IMHO.

> Even Safari is adding support for it with the upcoming Safari release.

Safari for iOS 16.0 supports it now for still images. Safari for 16.1 apparently adds support for animated image sequences.

AVIF support comes to macOS with macOS Ventura.

https://twitter.com/jensimmons/status/1547693585922789381

What is the patent situation for JPEG XL vs AVIF?

Both officially are free, but AVIF possibly has stronger defensive backing given it's defended from patent aggressors by AOM.

Reply on news.ycombinator.com