4 ms·

Here's a question I have for when e.g. Chrome supports JPEG XL: currently, if you have a <picture> with avif, webp, jpeg, it prioritises them in that order. But

Here's a question I have for when e.g. Chrome supports JPEG XL: currently, if you have a <picture> with avif, webp, jpeg, it prioritises them in that order. But with JPEG XL added into the mix, which one is chosen by the browser? AVIF or JPEG XL? Will different browsers make different choices of priority? And finally, how much longer will the HTTP "Accepts" header continue to get with these new formats?

efortis 3y ago
It will select the first supported format, webp in the example below. <picture> <source srcset="foo.webp" type="image/webp"> <source srcset="foo.jxr" type="image/vnd.ms-photo"> <img src="foo.jpg" alt="" width="100" height="150"> </picture> https://html.spec.whatwg.org/dev/images.html#image-format-based-selection https://html.spec.whatwg.org/dev/images.html#image-format-ba... --- About the Accept header, currently they include `image/avif` so I have no reason to believe that `image/jxl` won't be added.
- chocolatkey 3y ago
  I see, I was not aqare that the ordering of the source tags mattered
themerone 3y ago
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.
        3y ago

efortis 3y ago

It will select the first supported format, webp in the example below. <picture> <source srcset="foo.webp" type="image/webp"> <source srcset="foo.jxr" type="image/vnd.ms-photo"> <img src="foo.jpg" alt="" width="100" height="150"> </picture> https://html.spec.whatwg.org/dev/images.html#image-format-based-selection https://html.spec.whatwg.org/dev/images.html#image-format-ba... --- About the Accept header, currently they include `image/avif` so I have no reason to believe that `image/jxl` won't be added.

chocolatkey 3y ago
I see, I was not aqare that the ordering of the source tags mattered

themerone 3y ago

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