> To do these tests I took this photo taken by Alessio Soggetti. I then down-scaled and cropped it. I started at 0 quality for all encoders and worked my way up in 10 step increments. I tried to aim for a little over 100KB. I did bump JPEG XL a few steps (50 to 53) to keep it competitive with AVIF (JXL came in at 100KB at q50 while AVIF came in at 110KB at q40).

Correct me if I am wrong on the calculation.

The down-scaled PNG is showing 5 images at 6106 x 1200. At 100KB per one image would be at bpp of ~0.55. So despite the favourable results, I need to state again JPEG XL isn't yet optimised for low bpp yet ( bpp below 1 ).

Reposting My previous comment ( https://news.ycombinator.com/item?id=27577701 ) on JPEG XL from a few months ago.

Comment from Facebook Infra [1],

>Erik Andre from the Images Infra team at Facebook here. I'd like to share a bit of our view on JPEG XL in the context of new image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser adoption will let us move forward with our plans to test and hopefully roll out JPEG XL.*

>After spending the last 5 months investigating and evaluating JPEG XL from both a performance and quality point of view, it's our opinion that JPEG XL has the most potential of the new generation of image formats that are trying to succeed JPEG.

>This opinion is based on the following findings:

>JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content.
Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that we can reach parity with JPEG when using multiple threads to decode. This matches and in many cases surpasses the decoding performance of other new image formats.
The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.

>Having browser support from all the major browsers is going to make our lives a lot easier in upcoming WWW experiments and ensure that we can deliver a consistent experience across platforms and browsers.

Blink Tracking Bug [2] currently behind a flag ,Firefox on both [1] and [3], currently in about:preferences#experimental on Firefox Nightly. If I remember correctly it is supported on Edge behind a parameter as well. I thought it was all very quiet after the standard was published, turns out both Chrome and Firefox intent to support it.

AFAIK, neither Webkit nor Safari has any plan or intention to support JPEGXL. I think ( someone correct me if I am wrong ) Safari uses macOS image decoding library. So supporting JPEGXL may come from an OS update and not browser?

Finally, an open standard, Royalty Free, open-source reference implementation, and it is nearly better than all other alternative. As an image format on the web it is quite possibly close to perfect [4]. It is exciting and I hope JPEG XL will succeed.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1707590

[4] I remember the conversion from a little more than 6 months ago current encoder is not optimised for image quality below bpp 1.0, those are going to be the focus once all the initial reference encoder and decoder standards and issues are done. So in case anyone wondering it doesn't look as good as other competitors ( but still a lot better than JPEG ), those improvements are coming later.