Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly.

Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95.

The same kind of individualism exist also in temporal cognition and perception.

Also, it is not a competition for the shortest specification. If it was, still good. Jpeg xl spec is about half the size of the original jpeg spec.

Jpegli is still a hidden gem. People don't yet understand how great it is.

Chrome decided not to be an early adopter for good reasons that they have publicly documented, but that did nothing to JPEG XL. Particularly, it did not kill JPEG XL. Others, DNG, DICOM, PDF, EPUB, iOS, Safari, etc. integrated it early regardless.

This article is not about the entropy codes and predictors, memory bandwidth and decision trees, but about the long horizon planning in corporate-driven OSS efforts and being connected to both community and cross-industry.

On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.

In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:

1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.

2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.

Skal also took care of integrating the lossless format into the lossy as an alpha layer.

JPEG XL is not that massive.

JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.

A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.

A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.

A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.

The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.

I designed WebP lossless alone. The rest of the WebP folks added a RIFF header and an artificial size limitation (16383x16383) to match with the size limitation of lossy WebP.

In JPEG XL I believe I had more influence on the lossy ("VarDCT") format than anyone else, but stayed relatively far from the lossless part (except the delta palette, two predictors, 2d lz-codes, and a few other smaller things). I believe Jon and Luca had most influence there.

the decoder is something around 30 kloc

The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.

It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.