Revert “flag_descriptions: Add note about JPEG XL removal”

Those single-frame next-gen formats don't support progressive rendering.

video based image formats have a ton of downsides. Modern video codecs are all designed for large resolutions, while things like icons are often pretty small (64x64 or less). Videos don't support transparency, don't care about progressive scans, and are more lenient for certain types of errors because people don't spend time looking at every frame. As such, there are a lot of reasons why it is beneficial to use an image first format. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... has some comparisons showing how much better JPEG-XL is than HEIC/webp.

At the kind of high quality settings many still images are encoded at, jpeg XL often beats all those other formats in quality/bit (at _low_ bitrates the video-derived formats win). Furthermore, in lossless mode it does significantly better than png; many of the formats you list either don't have a lossless mode, or aren't at all competitive in lossless mode. It also supports bitwise-identical jpeg recompression (which naturally isn't quite as efficient as from-scratch compression as jpegXL), making for a very, very easy transition story that immediately provides significant savings, while also having a seemless path to use native jxl images in the future. It supports per-pixel alpha and animation. It allows for very high bit depths and images sizes, making it convenient in authoring workflows too. Another authoring feature that matters is generation loss - decoding and recompressing repeatedly causes much less distortion in the reference jxl encoder than typically seen in heif, avif or webp. And it's also computationally much, much cheaper - HEIF and particularly AVIF can be quite expensive to encode. Unlike HEIF, there don't seem to be patent issues yet.

In essence: it's best or near-best at almost all workloads, all in one, while being more practical to use to boot. It's just the still image codec you _want_ to be using, instead of having to fiddle with the various tradeoffs the others have.

Need to support non-modern clients or have lots of existing jpegs? jxl allows jpeg recompression with cheap and exact jxl->jpeg reconstruction.

Have tons and tons of images that aren't necessarily going to be viewed often; or have dynamic image generation? Compression is much faster than other competing modern formats; decoding speed

Have some pixel art or geometric diagrams? Jxl does better here than png, and better than all other competing formats (excluding a few very niche hyper-slow research formats).

Just don't want to worry too much about your exact workload? Jxl does well at pretty much everything.

Have users that have the bad habit of opening, editing, and resaving lossy images? Jxl introduces less generation loss.

Have huge images, but don't want to wait for the whole thing to load? Jxl supports progressive decoding.

Have various layers or other editing-workflow-related (meta)data? Jxl supports that, while also having best-in-class compression rates at high or lossless quality, and also having fast encode and decode times

JpegXL is probably the best format to use for almost every image you encounter. That's why it's a shame to see chrome dragging its feet here.

JPEG XL is about one image codec generation ahead of HEIF and AVIF in my own experiments and personal evaluations. Butteraugli, an objective metric I developed originally for guetzli, during 2014 to 2022, also agrees with this evaluation, as well as the large-scale human rater study by cloudinary.

Many objective metrics get really confused about JPEG XL as it uses some pretty advanced psychovisual modeling that is not implemented in usual metrics.

The best metrics to try in my opinion are butteraugli, ssimulacra 2 and -- with some reservations -- dssim.