As has been mentioned, JXL has several advantages over HEIC (the following is mostly a summary of It’s High Time to Replace JPEG With a Next-Generation Image Codec):
- Royalty free. Pretty much only Apple supports HEIC, because anyone else would have to pay royalties (mostly to Apple) to use it. By contrast, pretty much every web browser that isn’t Safari already supports jxl (though the support is still turned off by default, for now).
- Larger maximum image sizes - up to 1 billion pixels in each dimension, compared to 8,192 x 4,320 for HEIC. There are plenty of cameras on the market today capable of recording images at resolutions higher than what HEIC supports.
- Higher and color depths - up to 32 bits per channel, compared to 8 bits for JPEG or 16 for HEIC. Honestly 16 bits is probably enough, since few image sensors really have enough usable dynamic range to exceed that, but it’s nice to have the headroom just in case.
- Support for more color channels than you’ll ever need. Even if you’re not building a microscope that might need 9+ color channels, if you ever want to print your photos then you might find support for CMYK attractive.
- More efficient lossless and near-lossless encoding.
- Support for progressive decoding (that is, being able to e.g. render a half-resolution version of the image from the first ~20% of the bytes in a file - super useful for rendering thumbnails for example without needing to decode the entire image file).
- Much, MUCH faster to encoding/decoding, especially on constrained hardware, at least at high bitrates - close to 10x as fast as HEIC, in fact, and even slightly faster than JPEG. That means it’s fast enough to be realistic for future cameras to support it natively, which is probably not the case for HEIC.
- It also includes modes that make it appropriate for the kinds of synthetic images you’d otherwise use PNG or GIF for.
But, the really killer feature for JPEG XL, which makes it markedly different from previous attempts to replace JPEG, is that it supports a mode where it can be transcoded to/from old-fashioned JPEG without further loss of fidelity. Obviously JPEG doesn’t support lossless, so you’re not going to get a lossless JXL out of a jpeg, but you can take your existing library of jpeg images and transcode them to jxl, saving about 20% of the space, and then if you need the jpegs back you can get them back, bit for bit identical to what you started with (this is larger than the size you’d get if you encoded directly to JXL at the same perceptual quality, but it’s a very useful feature for archival).
All of that said, it’s absolutely true that adding a feature like file format support is very expensive in terms of maintenance, because you can’t ever drop it in the future. What I’d propose is that DxO should add an input/output plugin API. The existing jpeg encoder/decoder could be slotted in through that API, and then 3rd-party or open-source developers could add additional plugins to support JXL, HEIC, and so on. The maintenance burden of doing it that way is much smaller, because third-party developers kind of expect to have their plugins broken every time there’s a major version update anyway, so it’s their problem to deal with any API changes DxO wants to make there. This would also enable other kinds of plugins, for example I’ve been curious to try out GitHub - google/guetzli: Perceptual JPEG encoder old-fashioned but slightly more efficiently encoded JPEG output.
(I’m an experienced developer. If such an API existed, I’d totally write some open source plugins to support some of these use cases. I’ve even gone as far as some preliminary investigation into seeing how hard it would be to “hack in” such a plugin. Turns out, there’s almost an API like that in there already, but not quite to the point where I’d want to spend a lot of effort trying to interface with something that’s so completely unsupported upstream)
In the mean time you can always just save as tiff (lossless) and then convert. It’s just a PITA.