5 ms·

If chrome adopts JPEG XL, there won't be any reason to use avif or webp. Picture tags should only need two combinations [jpeg xl, jpeg], and [jpeg xl, png]

masklinn 3y ago
> If chrome adopts JPEG XL, there won't be any reason to use avif or webp. Yes, absolutely, there is definitely no browser or version of a browser which lacks jxl support and could make use of avif or webp over jpeg.
- chrismorgan 3y ago
  No, seriously, there’s not generally much point in supporting more than the latest fairly widely-supported format, and a universal fallback format. The advantages of the intermediate format are typically too slight and too transient. If, for example, you deal with photos and currently serve AVIF, WebP and JPEG, around 80% of viewers will take AVIF despite the implementations all being under three years old (less than one in Apple-land), and that number will continue to climb, so that the WebP in this chain will be helping practically no one within two years. Moreover, adding WebP is already imposing a tiny cost for every viewer and a likely-noticeable cost for storage and maintenance, while frankly only slightly reducing the cost over JPEG for WebP-but-not-AVIF viewers.
  - JyrkiAlakuijala 3y ago
    It is not that clear. AVIF (and WebP) seems to be performing worse than JPEG at qualities above 90. That is likely 30-40 % of all the images in the internet. Why would these users want to send more bytes of AVIF than they use for JPEG today to maintain their quality choice? They would also lose lightweight decoding and progressive viewing while doing that.
    - chrismorgan 3y ago
      That’s completely irrelevant to what we were talking about. We were discussing whether, if providing JPEG XL and JPEG, there would be any value in also providing AVIF or WebP. > … qualities above 90. That is likely 30-40 % of all the images in the internet. I don’t know whether it is, but it shouldn’t be anything like that. For browsing, a JPEG of quality q=90 is ridiculous overkill: that’s the kind of quality you should only get if you’re deliberately downloading high-quality images. A more commonly used figure is q=75, which produces files around 40% of the size of q=90, and most of the time q=60 (around ¼ of the size of q=90) is entirely adequate (perceptually sufficiently indistinct). I would also expect that such excessive-quality images would be found primarily in systems that don’t support multi-format serving.
      - JyrkiAlakuijala 3y ago
        re-reading your arguments with more thought, I agree with you however, I believe that web median quality is 85, and 75 is closer to 10 percentile bad quality
        chrismorgan 3y ago
        I should clarify that when I say “a more commonly used figure”, I mean “among things that have put any consideration into optimisation”. Where not controlled deliberately, tools tend to use the quality of the source image (which is probably around q=90 to q=94), or choose an unnecessarily high value like q=90. But take tools that have put at least some effort into sanity, and you find things like: https://squoosh.app/ https://squoosh.app/, a human-friendly tool for manual image optimisation and conversions, defaults to q=75 on JPEG; and the Zola static site generator defaults to q=75 for JPEG <https://www.getzola.org/documentation/content/image-processing/ https://www.getzola.org/documentation/content/image-processi...>; and Sharp, a Node.js library used by eleventy-image, defaults to q=80 on JPEG <https://sharp.pixelplumbing.com/api-output#jpeg https://sharp.pixelplumbing.com/api-output#jpeg>. The considerable majority of images on the web are way higher-quality than they need to be.
        JyrkiAlakuijala 3y ago

masklinn 3y ago

> If chrome adopts JPEG XL, there won't be any reason to use avif or webp. Yes, absolutely, there is definitely no browser or version of a browser which lacks jxl support and could make use of avif or webp over jpeg.

chrismorgan 3y ago
No, seriously, there’s not generally much point in supporting more than the latest fairly widely-supported format, and a universal fallback format. The advantages of the intermediate format are typically too slight and too transient. If, for example, you deal with photos and currently serve AVIF, WebP and JPEG, around 80% of viewers will take AVIF despite the implementations all being under three years old (less than one in Apple-land), and that number will continue to climb, so that the WebP in this chain will be helping practically no one within two years. Moreover, adding WebP is already imposing a tiny cost for every viewer and a likely-noticeable cost for storage and maintenance, while frankly only slightly reducing the cost over JPEG for WebP-but-not-AVIF viewers.
- JyrkiAlakuijala 3y ago
  It is not that clear. AVIF (and WebP) seems to be performing worse than JPEG at qualities above 90. That is likely 30-40 % of all the images in the internet. Why would these users want to send more bytes of AVIF than they use for JPEG today to maintain their quality choice? They would also lose lightweight decoding and progressive viewing while doing that.
  - chrismorgan 3y ago
    That’s completely irrelevant to what we were talking about. We were discussing whether, if providing JPEG XL and JPEG, there would be any value in also providing AVIF or WebP. > … qualities above 90. That is likely 30-40 % of all the images in the internet. I don’t know whether it is, but it shouldn’t be anything like that. For browsing, a JPEG of quality q=90 is ridiculous overkill: that’s the kind of quality you should only get if you’re deliberately downloading high-quality images. A more commonly used figure is q=75, which produces files around 40% of the size of q=90, and most of the time q=60 (around ¼ of the size of q=90) is entirely adequate (perceptually sufficiently indistinct). I would also expect that such excessive-quality images would be found primarily in systems that don’t support multi-format serving.
    - JyrkiAlakuijala 3y ago
      re-reading your arguments with more thought, I agree with you however, I believe that web median quality is 85, and 75 is closer to 10 percentile bad quality
      - chrismorgan 3y ago
        I should clarify that when I say “a more commonly used figure”, I mean “among things that have put any consideration into optimisation”. Where not controlled deliberately, tools tend to use the quality of the source image (which is probably around q=90 to q=94), or choose an unnecessarily high value like q=90. But take tools that have put at least some effort into sanity, and you find things like: https://squoosh.app/ https://squoosh.app/, a human-friendly tool for manual image optimisation and conversions, defaults to q=75 on JPEG; and the Zola static site generator defaults to q=75 for JPEG <https://www.getzola.org/documentation/content/image-processing/ https://www.getzola.org/documentation/content/image-processi...>; and Sharp, a Node.js library used by eleventy-image, defaults to q=80 on JPEG <https://sharp.pixelplumbing.com/api-output#jpeg https://sharp.pixelplumbing.com/api-output#jpeg>. The considerable majority of images on the web are way higher-quality than they need to be.
        JyrkiAlakuijala 3y ago