All I'll say is that I would not hold my breath.
The next beta (Opus 13.20.1 and later) will also support JXL images via the WIC plugin, provided JPEG XL Image Extension - Free download and install on Windows | Microsoft Store is installed.
2 Likes
The WIC plugin has the advantage of using Windows colour handling for converting HDR to SDR for DOpus as well. It's never going to look great, but it should be better than with my plugin, which uses a fixed conversion from libjxl.
I've been using the WIC plugin for viewing HDR JXL images and it's pretty good on an HDR OLED monitor. Colour actually matches photo editing software like ART.
It looks like Chrome is reintroducing JXL support as well, probably due to JXL being added to the PDF spec and so being necessary to display them. Unfortunately Firefox on Windows still doesn't have full HDR support, but JXL works.
"JPEG 2000" has also been added to the PDF spec (version 1.5), so that means nothing.
Let me know when it enters the usage diagram:
(Historical yearly trends in the usage statistics of image file formats for websites)
AVIF just made it, and my alternative SeaMonkey web browser still doesn't support it...
At least it doesn't pretend to be JPEG, so that's OK with me.
"JPEG XL" is the same kind of fake as everything else that came from that side.
Regards
Guido
JPEG developer
"JPEG XL" is the same kind of fake as everything else that came from that side.
But you say that you are a "JPEG developer" 
JPEG 2000 failed because it didn't offer enough over JPEG, but JPEG XL does have many new and useful features.
- Proper HDR support.
- Lossless transcoding of JPEG for smaller file sizes.
- Lossless encoding with decent compression.
- Better decoding performance on modern CPUs.
It is also already adopted by some major players, including Apple who let you save photos from your iPhone in it directly. Once Chrome supports it, it should quickly gain some traction. Any JPEG can be losslessly transcoded for an average 20% space/bandwidth saving, and it outperforms WebP for similar file sizes. It also outperforms PNG for lossless.
Yes, but I am not part of the fake factory, also called ISO WG1 (Working Group 1). 
I am Independent JPEG Group (IJG).
Regards
Guido
JPEG developer
1 Like
There is a very simple fact which is overlooked:
- JPEG: has substance
- "JPEG 2000", "JPEG XL", etc. (everything coming from ISO WG1): have no substance
The substance of JPEG is in four fundamental properties for image representation.
Upcoming JPEG 10 will enable backward compatible HDR support, as announced in the infancy article.
Lossless transcoding of JPEG for smaller file sizes can already be done with jpegtran or Jpegcrop.
It is called arithmetic coding.
See also my recent post here.
You could add any other entropy coding method with lossless transcoding to JPEG if you are really interested in the feature.
The fact that they do not add it to JPEG but to an otherwise unusable format shows that they are not really interested in making such feature usable.
Arithmetic encoded or transcoded JPEG is at least usable.
I use it since many years for almost all my local JPEG images.
That's why it is the default setting in Jpegcrop.
Regards
Guido
JPEG developer
1 Like
I won't pretend to know the full history of it, but my understanding was that JPEG wasn't moving fast enough and even JPEG 10 lacks some stuff that people wanted, so JPEG XL was born.
The lossless transcoding of JPEG to JXL takes advantage of better compression (JPEG is RLE if I recall), similar to what some file compression apps have been doing for decades now. I think Stuffit Expander on the Mac was the first to do it, in the early 2000s.
Lossless image coding also means that JXL can become the one format for everything, rather than the split between JPEG and PNG we have now. That has its pros and cons though - at least with PNG you knew it was always lossless, bit depth aside.
I don't know, and to be honest I don't really care. JXL is here, adoption is moving along, and it solves the problems I need solving.
Now we just need DOpus to support HDR as well 
The details of JPEG 10 are totally unknown to date, aside from the abstract given in the article, especially for the folks in ISO WG1, who have not the slightest clue about the substance of JPEG.
The common entropy coding method of JPEG was Huffman, as shown in the Preferences dialog of Jpegcrop (running on Windows XP SP3) above.
This is considerably more advanced than RLE.
My opinion is that any universal image format should provide a lossless coding option.
JPEG has it integrated since JPEG 8 in the SmartScale framework.
JPEG 9 added about 3 lines of source code to make it better than PNG, but only for photographic images (see JPEG 9 Lossless Coding).
The goal was not to compete with PNG, but to provide the basic function and framework for further development if necessary.
(The ISO WG1 stole that idea of lossless integration for "JPEG XL", but still lacking the JPEG substance. So one could say that this theft is the origin of "JPEG XL".)
My opinion is that any attempt to replace the ubiquitous JPEG and PNG duo with a unified alternative will ultimately fail, and will only increase the format mess, contrary to the (illusionary) intention.
My suggestion is:
Consider the JPEG and PNG duo as the actual universal solution, and further develop both together!
That is my vision, and I do the JPEG part of it.
Everything else will not be beneficial and only increase confusion.
Regards
Guido
JPEG developer
It's all very interesting and I'm sure there are good ideological reasons for preferring JPEG 10 when it arrives, but you see the problem - there were a bunch of half arsed solutions like Google's JPEG extension for HDR, and JPEG XL addresses them. It's here now with a reference library and support on hundreds of millions of devices already.