3 ms·

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/

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?
    - bmicraft 3y ago
      I think the point was probably more about complicating the codec by requiring even more features to be implemented, which might hinder adoption
      - JyrkiAlakuijala 3y ago
        Another practical reason was to keep the level of complexity manageable for us humans implementing and optimizing it.
emn13 3y ago
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/#reykjavik&avif=l&jxl=l 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?
- JyrkiAlakuijala 3y ago
  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.
JyrkiAlakuijala 3y ago
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 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)
- bscphil 3y ago
  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.
  - JyrkiAlakuijala 3y ago
    Thank you.

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?
  - bmicraft 3y ago
    I think the point was probably more about complicating the codec by requiring even more features to be implemented, which might hinder adoption
    - JyrkiAlakuijala 3y ago
      Another practical reason was to keep the level of complexity manageable for us humans implementing and optimizing it.

emn13 3y ago

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/#reykjavik&avif=l&jxl=l 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?

JyrkiAlakuijala 3y ago
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.

JyrkiAlakuijala 3y ago

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

bscphil 3y ago
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.
- JyrkiAlakuijala 3y ago
  Thank you.