Hacker News Reader

Related: That can be done on the server-side too.

https://blog.uidrafter.com/conditional-avif-for-video-poster...

> Unlike <img> tags, <video> posters have no standard way of specifying many URLs for fetching the optimal format supported by the client.

Actually, you can do it without needing any scripting, though the technique is convoluted: use as the poster an SVG image (encoded inline as a data URI), containing a <foreignObject>, containing an HTML <picture> element. It ends up roughly this (with superfluous whitespace added):

  <video
    poster='data:image/svg+xml,
      <svg xmlns="http://www.w3.org/2000/svg" …>
          <foreignObject …>
              <picture xmlns="http://www.w3.org/1999/xhtml">
                  …
              </picture>
           </foreignObject>
      </svg>
    '>
  </video>

Thank you. This is handy for requesting with options besides the image format.

> Another great aspect of JPEG XL is that it is a short circuit answer to almost any "what format should you store an image in?" question.

WebP offered that as well. Nobody ended up caring. Animated WebP even exists! A truly universal container that also got basically no usage.

WebP lossy has abysmal quality compared to JPEG, and MozJPEG closed the file size gap quite a lot to make old JPEG a clear winner over WebP.

JPEG XL doesn't fall into the same trappings of basing on a video intraframe and limited chroma support.

Yes, this. ^

> WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.[1]

[1] https://siipo.la/blog/is-webp-really-better-than-jpeg

Jpegli was introduced after this comparison and makes the old jpeg standard perform quite a bit better and to have HDR support (10+ bits), too.

I still can't believe in 2023 there are people supporting WebP.

Let's be fair, WebP lossless is pretty good, it has a couple advantages:

1. Almost always produces smaller files than PNG, even after PNG optimizers

2. Supported by all web browsers.

WebP lossless' disadvantage comes in that the maximum dimensions of the file are limited to 16383×16383. I find images larger than that on a frequent basis, it's not a very high limit. It also only supports 8-bit per color images. Good enough for screenshots, not good enough for some editors.

Lossless is a category of codecs where file size is almost the only factor anyone cares about. Pretty much all of them are fast enough to not bother measuring with encode or decode speeds.

JPEG XL will perform even better in lossless mode than WebP lossless does, but it's not currently supported by any browser (it's in Safari beta and behind a config flag in Firefox Nightly).

>but it's not currently supported by any browser (it's in Safari beta and behind a config flag in Firefox Nightly)

Your comment is 100% accurate, but it's notable that JPEG XL is coming this fall across the release versions of macOS, iOS, iPadOS, and then standalone Safari (itself being compatible back to macOS 12). Not just in Safari, but in the core media content subsystem of the core OS as well, meaning it can be immediately supported by third party apps as well effortlessly.

Given the extremely rapid uptake of Apple OS updates, by year end it will have a substantial compatible base.

Of course webp has a massive compatible base right now yet sees almost no adoption. Hopefully the quality and functional benefits of JPEG XL finally get us over that hump.

You could see another comment I made on this story. :) WebP lossy has poor enough visual quality and poor enough file size gains over JPEG (especially after MozJPEG has really squeezed the most they could out of the 1993 format), that it's wholly unappealing to anyone that would possibly care about lossy formats. Google never really advertised that WebP lossless is a thing, so in the minds of many, WebP is a failed JPEG replacement and PNG stands unopposed (even though that's untrue for a subset of images PNG supports).

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?

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-ba...

---

About the Accept header, currently they include `image/avif` so I have no reason to believe that `image/jxl` won't be added.

I see, I was not aqare that the ordering of the source tags mattered

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]

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

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.

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.

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.

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

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/, 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-processi...>; and Sharp, a Node.js library used by eleventy-image, defaults to q=80 on 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.

I like the images to be at or above quality 94, d1.0 or smaller in jpeg xl. Some other user cares less. Some user thinks that quality 75 is as they came from the camera and it cannot be helped.