The specification was frozen "only" in December 2020. It is enough time for a lot of software to add support to it (Gimp, ImageMagick, Krita, FFMpeg, Adobe Camera Raw). But it will take a long time before camera start using it. And since a lot of popular graphic software cannot export to JXL yet (photoshop, clip studio, lightroom, ...) most professional just can't use JXL (short of saving a lossless image and then converting it to JXL in another software). And in general, since the format is pretty new, most people don't know about it. That is why being able to use it for the biggest browser would have been huge for speeding its adoption.

Software support for WebP was also a massive problem up until the last few weeks. Because Chrome forcibly converts image files to WebP, it made my Photoshop work a hassle.

Wow, Photoshop only got WebP support two weeks ago. That's ridiculous.

Chrome doesn't forcibly convert images to WebP.

Yes it does.

https://www.zdnet.com/article/how-to-get-around-chromes-new-...

>Chrome forcibly converts image files to WebP

What does this mean? Does chrome automatically convert images to webp when you click 'save as' on a jpeg image?

I’ve mainly had it on png, but yeah! When I open a png, mainly on Fandom sites, the URL will say its a “.png” extension yet will only attempt to download as a “.webp”.

You can read more about it here: https://www.zdnet.com/article/how-to-get-around-chromes-new-...

Seems odd that ACR supports it and lightroom doesn't.

Yeah, since Chrome doesn't support it, why would anyone use it? It's a chicken and egg problem

If you use a service like Cloudinary then it will detect the appropriate image format to serve to the browser based on the request. I would expect JPEG-XL to start being served to Safari clients once macOS 14 and iOS 17 are released.

Chrome can hold out but ultimately all they are doing is hurting their users.

You don't even have to use a service. A picture element containing sources by priority, and then finally an img fallback for the obsolete browsers, allows you to use the best possible codec that the client supports.

Certain company that commented on the thread already turned their image processing pipelines to use jpeg xl instead, given the significant bandwidth savings. Now all they got is the significant hole in budgets since it may never pay off.

We can't know how many are using jpeg xl since there is no available metrics to find out.

We can easily scrap the internet. There should be a statistic about it.

But for companies they should have two formats anyway: the original file and the optimized file.

Changing the optimized file should be an existing batch process

With the high cost of cloud storage I see it as a pretty big burden to host multiple copies of an image, particularly if you feel compelled to have multiple optimized images such as JPEG, WEBP, AVIF, ... That's why I didn't start using WEBP for images until support was universal enough that I could give up JPEG.

(For a large image collection you have some images that are heavily requested and most of the cost is network transfer, but you also have many images that are infrequently requested and for those the cost of storage in the dominant factor. I launched a large image collection in the late 2000's and many sites that did the same thing at the same time were ultimately crushed by running costs, Pinterest and Instagram were survivors, overall the economics of video collections turned up to be better than images.)

I guess technically you could store original and encode to <whatever format is popular> on-demand then just cache the most popular ones

In internet-scale systems complex delivery systems involving transformation and caching are not necessarily a win for performance insofar as once you give up a millisecond of latency you cannot get it back. You very much can get a win out of a CDN but somebody has to do aggressive tuning of absolutely everything.

It's not for performance but for not having to permanently store terabytes of differently encoded data.

You could possibly also pre-populate cache - all new media files get sent to encoder and cached preemptively, and if they are popular enough they just stay there till they are not.

Yes, we do that. Well, the CDN does the caching -- but we still get a 99.99% hit rate.

Please forgive the case study format, but I'm quite proud of what we did and this is the easiest way to back up my assertion with data: https://aws.amazon.com/solutions/case-studies/skyscanner-clo...

We're currently generating JPG, WebP, and PNG, depending on the source and the target. The problem with doing this on-demand is that formats that are great for delivery but slow to encode aren't useful. I did try to add AVIF, but the latency on the first request was too high for it to be practical.

I guess "preheating" cache with preemptively encoding and putting new content in cache before it is shown to client could work?

But still, anything AV1 based just needs a lot performance to encode that just doesn't feel worth it at the moment. Our system to encode videos was tooled for that but developers eventually decided it's too slow/cpu hungry to bother. It was some time ago tho, encoders did get better...

>they should have two formats anyway

Good thing JXL has the best progressive support of any image format available! [0, 1] Something which you can only find partially with incremental decoding in WebP and doesn't really exist in AVIF (just one of the many limitations of being bolted onto a video codec). You might often reconsider having both versions of a file with this capability. (which wasn't exploited much or at all with "dumber" and heavier progressive JPEGs)

0. https://opensource.googleblog.com/2021/09/using-saliency-in-...

1. https://jpegxl.io/articles/faq/#doesjxlsupportprogressivedec...?

No shit you don't see people using it, all browsers hide support behind a feature flag or straight up removed support. Use your brain for a second.