Hacker News Reader

Comment by WithinReason | Hacker News Reader

AVIF looks better to me at low bitrates, JXL has much more visible block artifacts:

https://afontenot.github.io/image-formats-comparison/#vid-ga...

I think this is definitely the most common response. AVIF, as a video intra-frame based codec, works best at very low bitrates. JPEG XL is considerably better at high bitrates.

I'm guessing the reason is that for predicting video frames hallucinating detail is undesirable, so you would rather remove detail than add non-existent detail. AVIF also seems to have some kind of deblocking filter which JXL lacks, to my surprise.

You can also adjust that deblocking in AVIF.

AVIF deblocking filter is one axis at a time whereas JPEG XL is doing an axis-non-separable filter, 2d selection at once. It is not clear that AVIF can be parameterised to do similar filtering to JPEG XL -- at least it hasn't been done yet.

The worst aspect of JXL is the chroma bleed:

https://afontenot.github.io/image-formats-comparison/#catedr... (glasswork)

https://afontenot.github.io/image-formats-comparison/#end-of... (teeth, fingernails)

https://afontenot.github.io/image-formats-comparison/#steinw... (lights, pianos)

https://afontenot.github.io/image-formats-comparison/#us-ope... (racket, fingernails, jewelry, watch)

This may simply be a case of each codec having its own strengths, however I also wonder whether the issue here isn't also that the "small" compression size you're linking to in these examples in general isn't good enough; you're trading the kinds of artifacts you want - and in general jxl doesn't appear to do as well as avif at low quality settings.

But consider also e.g. https://afontenot.github.io/image-formats-comparison/#reykja... - even at "large" quality settings avif pretty visibly distorts the sky and there's some blur it the nearby trees too.

In any case, comparing to even the fairly good (for jpg) mozjpeg encoder it's clear both of these codes are much better than the status quo, and not that different from each other - neither wins universally vs each other, but both pretty clearly do vs. jpeg.

A fairly simple heuristic seems be that if want images at the tiny size - pick avif. At small, pick avif unless you really, really want to preserve texture over detail. At medium, pick jxl for texture, and avif for detail; and at large, pick jxl.

Browsing through these images in general, I think I'd usually pick jxl at medium or even sometimes large settings; small simply has too many artifacts in general (but if I had to use that - avif), and at better quality I (personally) find the distortion to texture more noticeable than loss of detail. I guess it depends on how important compression ratio is to you?

Photographic JPEG images are used at around 2.0 to 2.5 BPP in the internet, while same for WebP and AVIF is around 1 to 1.7 BPP as the current practice in the internet.

People in the internet don't like to store photos with 0.5 BPP even with the latest and greatest codecs, it gets too blurry and artefacty.

This is not a statement of my personal aesthetic opinion but observing what gets done out in the wild.

Those images are 1.0, 0.57, 0.33, and 0.22 BPP.

Usually we store images at 3.5 - 5 BPP (Cameras), 10+ BPP (Raw or similar for editing) and 1-2 BPP for internet user.

The actual bitrates depend a lot on the image -- graphics with simple backgrounds need less, photos with a lot of sky need less, busy detailed images particularly nature needs more.

While there is one 1.0 in the test, it is for an extremely busy image which would be better stored for internet use at 3+ BPP.

0.22 BPP is almost never used for photographs in the Internet.

See https://almanac.httparchive.org/en/2022/media#fig-15 for median bitrates in 2022 (1.0, 1.4 and 2.1 BPP for lossy formats)

You're probably aware of this, but the comparison tool allows selecting larger images. That first image is 3 bpp if you select "large".

> Usually we store images at 3.5 - 5 BPP (Cameras)

That's appropriate for JPEGs, but given that more recent compression algorithms do a better job, it's probably worth looking at lower bitrates. I pulled some JPEGs off my Canon DSLR for example, and they're around 2-4 bpp for landscape photos.

It's not surprising to see acceptable JPEG XL images with half that bitrate.

Thank you.

Would this be a big challenge to fix in JXL?

much of the gains of AVIF at lowest qualities come from features that don't exist in JPEG XL: wedges, large-support of the blurring filter, directional prediction

these features are non-helpful at normal photography bitrates and only complicate coding at bitrates above 1.5 or so

JPEG XL has similar approaches but its tools have a larger quality operating range

We evaluated these tools for JPEG XL and I rejected them due to them only helping at very lowest bit rates

there are many other ideas on how low quality JPEG XL images could be made, but it seems that it is more of a theoretical question since real use is always relatively high BPP: humans are 1000x more expensive than computers, so human experience can be prioritized over computer working harder for us.

I'm rather sympathetic to the argument of targeting actually used BPPs and think the benchmarks should reflect that (so "low" should be something like covering ~90% of actual images rather than some more arbitrary number), as it's another point of confusion counting against this great new format. Though I miss your last point - how would human experience be harmed by allowing using low BPPs?

> only complicate coding at bitrates above 1.5 or so

these features could be disabled at higher bitrates as they're not helpful there?

I think the point was probably more about complicating the codec by requiring even more features to be implemented, which might hinder adoption

Another practical reason was to keep the level of complexity manageable for us humans implementing and optimizing it.

At the cost of smoothing everything out losing a lot of texture and detail. In some cases it does look better because the artifacts are smoothed over, but it’s not a clear-cut. Especially with photography where the ISO grain is often a part of the art, it’s often completely washed away.

Are you using squoosh.app (That app is crap as it uses default settings optimized for AV1 video?

App? libavif provides avifenc--no need for anything beyond the command line.

On the other hand, AVIF smoothes out the fine details. It struggles to preserve the texture of the receipt and the tiny specks on the inside of the cup blend together.

It's visible even in qualities higher than "tiny", which IMO is unreasonably small.

For me coffee details look better on AVIF, spoon and receipt do lose some texture

Frankly I can't really see much difference between AV1/Tiny and JPEGXL/Large on the [1] middle of the coffee one, everything else around (cup, receipt, spoon) clearly have more detail but not the coffee in the middle

- [1] https://imgur.com/a/PeHlyE4

The sweet spot for jxl is generally in the more "normal" bitrates

Very interesting, thanks for building/sharing (I imagine you are the author of this page?). Questions I would have: a. Is it possible to dig out the exact cli command used for each of this encodings? b. With libavif, did you test film-grain-test and what are your findings if any? c. With libavif, did you test denoise-noise-level and what are your findings if any? Of course I have no wish to put you into any homework mode, so feel free to ignore this.

I am not the author.

That's a very photo heavy corpus. Which is fine if you're evaluating these formats for photo compression, but not very useful if you have a mix of photos, comics, memes, screenshots, etc.

Reply on news.ycombinator.com