I try not to download binaries from unknown sources. Version 0.7 is not yet released on github or gitlab.
Yes, I was already aware cjxl has a custom workaround for this for JPEGs only, and I am very much aware of the features listed in the specification, as I mentioned above.
All this time I’m talking about general support in the libjxllibrary that SW developers need to pick up and start using in 3rd party applications so this format gets wider adoption.
Since you like link sharing so much, here’s a couple more comments from the same person:
As of this moment, we’re not there yet, but will be soon.
The JPEG XL standard has now been formally approved: the Final Draft International Standard (FDIS) of ISO/IEC 18181-1 (the JPEG XL codestream spec) was approved unanimously; the International Standard will be published in January 2022. It’s done!
The new JPEG XL format offers several advantages over JPEG, including higher bit depth support and smaller file sizes, making it a great choice for HDR photos.
When the HDR Output feature is enabled, Camera Raw 15 supports opening and saving photos using JPEG XL. You can use JPEG XL for other types of photos as well.
A few tidbits I found while trying to investigate using .jxl files
Although it seems to be supported in several versions of Firefox, as of the current FF 106, it really is not. There is a flag to enable jxl support in Firefox, but it does nothing. You have to use Firefox Nightly to actually be able to display jxls, using the flag.
jxl is also supposedly supported in ffmpeg as of version 5.1. I have that installed in Arch Linux, but it doesn’t actually work there, either. I asked for support, and the answer was that jxl is not made into the ffmpeg that is in the Arch repositories. (Well, why not?) I would have to make and compile it myself, or there is a git version in the AUR that I could install, which requires many other dependencies. Ugh!
Finally, Image Magick does support jxl. I can use Image Magick to convert other format files to jxl, and I can use it to display a jxl in a desktop window. That doesn’t help much for everyday use cases, but at least it works.
And, just as more and more apps were beginning to support it, Google suddenly decided to kill it, citing some dubious reasons such as “not enough interest from the entire ecosystem” (I guess small companies like Facebook/Instagram, Adobe, Intel, Shopify, etc… don’t really count? Right?) https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84
JXL seems like a good codec to standardize (compared to HEIC and even AVIF). Let’s hope with the pressure from people this can be circumvented somehow.
EDIT: also, there might be a push to adopt AVIF for convenience of AOM members, despite jxl being a bit better in certain scenarios (speed, quality, features).
I use windows binaries for the cjxl / djxl tools, and use them quite often.
On a few production websites where the content people upload insanely huge images, we store those images as JpegXL now.
The thing is, that those images never get served directly to web browsers. Depending on device and viewport, there is a smaller, cached version generated in the popular formats as webp/png/jpg, and that is what the browser receives.
But Jpeg XL for me is an archiving format (near-lossless / lossless 16bit). I never bothered to look at browser support to be honest. It looks that indeed, for both chrome and firefox, it’s required to enable a flag in the config (and yes, nightly).
edit:
The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
Oh my g… really? It beats other formats in basically everything except lossless mode. It has higher bit depth modes from the start and supported as default (and only up to 16bit and more, not just 10/12 bit). It’s HDR ready from the start. It doesn’t degrade in quality by over smoothing the image when the bits get starved. And it compressed and decompresses in a fraction of the processing time compared to things like webp/heic/avif. And it’s standardised and bitstream locked.
This seems short sighted from the devs. I hope the ‘alternative chromium’ browsers keep it in.
Apparently they are working on WebP2 and use it as an image compression playground…
It looks like WepP2 also got the axe one month ago (“WebP 2 will not be released as an image format but is used as a playground for image compression experiments”):
The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
Yep, this is crazy… I am starting to wonder whether any of these next generation image formats will ever get widespread support in browsers.
I hope too, but unless some major industry player steps in and decides to maintain it, those forks probably won’t want to deal with an extra dependency (and the increased attack surface that comes with it).
I hope they have a plan. But it is quite possible that they don’t care much about photo content. A good part of the discussion surrounding JXL seems to be around potential bandwidth savings, not high bit-depth/wide gamut/HDR (which in my opinion are its “killer features”). Maybe the cost/benefit ratio is not worth it to Google, who may not particularly care about high-quality photographic content.
On the other hand, maybe JXL can still have a more “niche” future outside the web, as some sort of TIFF replacement. If industry players like Adobe, open-source projects (and hopefully camera manufacturers at some point) keep pushing it, it might very well be the direction it’s headed. We’ll still need to convert to lower-bit-depth AVIF when publishing to the web but, then again, we already do that sort of lossy conversion when resizing to 1080px.
Opera is based on Chromium (like most browsers that are not Firefox or Safari), so unless the Opera developers decide to proactively maintain JXL support, it will likely get dropped.
Could this be a hardware decoder thing? With AV1 decode maybe AVIF decode just comes “computationally free” (big air quotes! as in just en/decode on dedicated hardware) whereas jxl is not as straightforward to en/decode on specialized hardware?
This might be the only logical reason I have heard so far! (although it sucks for the web) If the cost of the encode/decode exceeds that of the bandwidth, then JXL may not be interesting for Google. But this is a bit surprising considering that Facebook and some cloud companies are backing it. How can their cost/benefit calculation be so different from Google’s?
Just look at history - for decades at this point, multiple attempts to unseat JPEG as the dominant format for image delivery have been made. ALL have failed.
The ONLY time we’ve seen ANY progress whatsoever in that fight has been by formats that leveraged commonality with widely supported video codecs. HEIC/HEIF/AVIF are literally just a single intra frame of one of the “big boy” video formats, in most cases even just recycling the container format of the video. HEIC is the first time in DECADES we’ve seen camera manufacturers support anything beyond JPEG and raw for stills, and no surprise, it’s because the market demands that they support H.265 video too, so once you’ve got that, why not just recycle the IP blocks for your stills output?
Some of the stated advantages of JXL (for example 16 bits vs. 10) don’t actually exist for JXL (HEVC also supports 16-bit 4:4:4 but it’s not commonly supported, AVIF can go up to 12-bit 4:4:4), and even if you just assume HEIC/AVIF limited to only 10-bit log encoding (such as PQ), the advantages of 16 bits are extremely questionably for last-mile end-user content delivery, any advantages as an archival/intermediary format aren’t really relevant to browser support. Browsers don’t natively support DNG or EXR either.
Even for software-only implementations, it’s “one library for video and stills” vs “library that only supports stills and is useless for video”.
Whether Facebook is using it for internal storage is irrelevant - companies like Facebook have enough volume in datacenter hardware that they can develop/require vendors to develop custom hardware solutions that aren’t seen in enduser systems. Application-specific hardware accelerators - Engineering at Meta - Facebook datacenters had Mount Shasta in 2019 and probably Shasta v2 supports JXL, end user hardware does not.
