6 ms·

AVIF looks better to me at low bitrates, JXL has much more visible block artifacts: https://afontenot.github.io/image-formats-comparison/#vid-gajsek&avif=t&jxl

AVIF looks better to me at low bitrates, JXL has much more visible block artifacts: https://afontenot.github.io/image-formats-comparison/#vid-gajsek&avif=t&jxl=t https://afontenot.github.io/image-formats-comparison/#vid-ga...

bscphil 3y ago
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.
- WithinReason 3y ago
  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.
  - worldofmatthew 3y ago
    You can also adjust that deblocking in AVIF.
    - JyrkiAlakuijala 3y ago
      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.
toastal 3y ago
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.
- worldofmatthew 3y ago
  Are you using squoosh.app (That app is crap as it uses default settings optimized for AV1 video?
  - toastal 3y ago
    App? libavif provides avifenc--no need for anything beyond the command line.
peppermint_gum 3y ago
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.
- ilyt 3y ago
  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 https://imgur.com/a/PeHlyE4
Retr0id 3y ago
The sweet spot for jxl is generally in the more "normal" bitrates
CodesInChaos 3y ago
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.
vitorsr 3y ago
The worst aspect of JXL is the chroma bleed: https://afontenot.github.io/image-formats-comparison/#catedral-de-toledo&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#catedr... (glasswork) https://afontenot.github.io/image-formats-comparison/#end-of-show&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#end-of... (teeth, fingernails) https://afontenot.github.io/image-formats-comparison/#steinway&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#steinw... (lights, pianos) https://afontenot.github.io/image-formats-comparison/#us-open&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#us-ope... (racket, fingernails, jewelry, watch)
- eviks 3y ago
  Would this be a big challenge to fix in JXL?
  - JyrkiAlakuijala 3y ago
    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.
    - eviks 3y ago
      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?
brontosaurusrex 3y ago
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.
- WithinReason 3y ago
  I am not the author.

bscphil 3y ago

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.

WithinReason 3y ago
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.
- worldofmatthew 3y ago
  You can also adjust that deblocking in AVIF.
  - JyrkiAlakuijala 3y ago
    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.

toastal 3y ago

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.

worldofmatthew 3y ago
Are you using squoosh.app (That app is crap as it uses default settings optimized for AV1 video?
- toastal 3y ago
  App? libavif provides avifenc--no need for anything beyond the command line.

peppermint_gum 3y ago

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.

ilyt 3y ago
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 https://imgur.com/a/PeHlyE4

Retr0id 3y ago

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

CodesInChaos 3y ago

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.

vitorsr 3y ago

The worst aspect of JXL is the chroma bleed: https://afontenot.github.io/image-formats-comparison/#catedral-de-toledo&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#catedr... (glasswork) https://afontenot.github.io/image-formats-comparison/#end-of-show&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#end-of... (teeth, fingernails) https://afontenot.github.io/image-formats-comparison/#steinway&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#steinw... (lights, pianos) https://afontenot.github.io/image-formats-comparison/#us-open&avif=s&jxl=s https://afontenot.github.io/image-formats-comparison/#us-ope... (racket, fingernails, jewelry, watch)

eviks 3y ago
Would this be a big challenge to fix in JXL?
- JyrkiAlakuijala 3y ago
  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.
  - eviks 3y ago
    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?

brontosaurusrex 3y ago

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.

WithinReason 3y ago
I am not the author.