[janwas]

At a guess, probably because it matches or at least is in the same order of magnitude encode speed as JPEG XL? It starts to feel like bait and switch if we say "look what we can do with >1000x slower encode", without noting that JPEG XL can also do a bit better with more encode time, and yet practical encoders, especially HW, use much higher speed settings.

Note: the 20-35% is BDrate, which in this context likely(?) involves some form of PSNR, which has almost nothing to do with human perception and IMO should not be used to guide such decisions.

[unlord]

Encoding speed is not really a concern for web uses, where the image is decoded potentially millions or even billions of times more than it is encoded.

I agree, PSNR is a terrible measure of quality. The study "Benchmarking JPEG XL lossy/lossless image compression" (https://research.google/pubs/benchmrking-jpeg-xl-lossylossle...) which you are an author on included a controlled subjective evaluation done by EPFL using an ITU recommend methodology. The subjective results concluded:

"HEVC with SCC generally results in better rate/distortion performance when compared to JPEG XL at low bitrates (< 0.75), better preserving sharp lines and smooth areas"

It is known that AVIF performs better than HEVC. Can you say why it was not included in your 2020 subjective evaluation? It would be nice to not need to speculate on the relative quality of AVIF v JPEG XL at web bitrates.

[janwas]

> PSNR is a terrible measure of quality

Glad we can agree on that. Unfortunately many evals use that or plain SSIM, which is still L2 at heart.

> Encoding speed is not really a concern for web uses

hm, in many discussions with Jon of Cloudinary, I did not get the impression that this is the case. Imagine their enthusiasm about 100x-ing their compute costs.

> Can you say why it was not included in your 2020 subjective evaluation?

The paper's comment on this is: "The selection of anchors is based on the general popularity of the codecs and the availability of the software implementations. We only intended to use codecs which are standardized internationally."

> using an ITU recommend methodology

While this has some helpful guidance on viewing conditions, it is unfortunately still subjective (what parts are observers looking at, what counts as "annoying") and is more useful for detecting severe artifacts, which less relevant in practice because that's hopefully not the quality range people are using.

Also, these results are quite old and both encoders have changed since then.

> need to speculate on the relative quality of AVIF v JPEG XL at web bitrates.

No need to speculate :) Just to first agree on what are actual web bitrates. From Chrome metrics, IIRC it was over 1bpp. Here's some newer data: https://discuss.httparchive.org/t/what-compression-ratio-ran... Even for AVIF, the median is 0.96 and q3 is 1.79(!).

Jon has written several articles on comparisons, including https://cloudinary.com/blog/contemplating-codec-comparisons and https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#med....

[kodabbb]

> The paper's comment on this is: "The selection of anchors is based on the general popularity of the codecs and the availability of the software implementations. We only intended to use codecs which are standardized internationally."

how very convenient, looks like politics outweigh any benchmarking

I have no game in the matter, but as a large website provider perspective, handling millions of images and processing thousands per day, I am glad not to have to deal with yet another format that would double our cache costs and force eternal support on the web. Not everybody has infinite google money to afford any kind of image format existing on the planet, and google can get only so much leeway after poisoning the web with webp.

j2c

[kodabbb]

small typo in the article https://research.google/pubs/benchmarking-jpeg-xl-lossylossl... (very interesting read!)