This looks promising and I’m wondering if DXO has it on the radar.
Interesting. Most of the touted benefits are also present in HEIC, but the interchangeability with the existing JPEG standard is a significant difference. The question is whether that is enough of a difference. Because Apple have introduced HEIC into something like a billion devices and it doesn’t seem to be gaining traction outside of that sphere, so I’m not sure anything can shift JPEG. Especially given it still solves the problem for a huge majority of use cases.
1 Like
I think that’s because HEIC is not completely royalty-free and not backwards-compatible. JXL is both and it supports both lossy and lossless compression. Google and Facebook and other heavy hitters have expressed support for JXL.
2 Likes
Interesting,
would this be the answer to the 4k 8k age? (yes that’s resolution mostly but with this technology is also AdobeRGB viewing capability and maybe 12bits colordepth or higher to support in future as standard. Because more pixeldetail ask for more color nuance too.)
By the way think of the network pressure as in Mbps. al those big files due bigger resolutionstreams and bigger image files to bennefit this technology. Hate to life in a area where you get 10Mpbs up/down max… 
All screens which Jpeg is “build” for in the first place are 8bits colordepth. 12bit colordepth viewers are rare for most people today right?
So using a JpegXL as storage now wil always cause a conversion to 8bits conventional Jpeg when called for viewing on a screen.
But a quick read on the site shows a highly compressed “16bit tiff” like data container with even unconventional ratio’s as 360 degrees.
If this could be a new standard for digital viewing it should be embraced by all big photo processor applications to succeed.
Apparently JPEG XL is royalty free so there is no reason for DxO not to jump onboard once JPEG XL acquires sufficient traction. Sufficient traction could be just around the corner or in three years. For those who would shout why not?, I suggest opening GraphicConverter and reading about the two hundred and seventy nine image formats Graphic Converter supports. Even without royalties, it costs engineering hours and creates visual clutter to support another image format.
Once a program does add support for a file format, it’s more or less condemned to support that format forever, or risk a wave of negative PR from even a small group of angry users when the publisher drops support.
1 Like
If I have this figured out right that might be less of an issue in this case since JXL is backwards-compatible. To lose support for it in DXO will just mean you can no longer export to it from the RAW.
It seems like compatibility is a big attraction here. As things stand, web services such as Facebook and its subsidiaries convert other formats such as HEIC to jpeg in order to serve them. This will no longer be necessary in the case of JXL since the file format can contain such a big range and size of data and it may serve up only what it needs. So if you upload a 16bit JXL to Facebook it will only serve up 8bits of the file … if I understand it correctly! I don’t know how it works but I have read that Google and Facebook are saying this format will save in storage and bandwidth.
Google have cancelled and refactored and uncancelled and migrated and deprecated so many services and formats that following Google’s lead would be suicidal for smaller development houses. Alphabet gets away with it as the online advertising space is so enormously profitable to them, Google can afford to make many, many false steps and waste hundreds of millions on failed directions.
@uncoy @Beachscriber
I think the biggest problem these days is commercial bennefit does make the choice (and not technological bennefit) for the big whales.
Google, Facebook.
i bought a good 2K screen (2560x1440) instead of a 4K one for my work on images and general use.
my 16Mp camera produces 4608x3464 4:3 ratio which is close to native 4096 × 2160 ([DCI] 4K) (16:9 ratio) (4K means bigger screen and closer watch distance to bennefit the extra pixels so much higher cost for a good screen)
And reading this:
Which would be for the general consumers of “real” camera’s (yes the ILC’s m43 aps-C FF not smartphone’s 
) the place to watch there proccessed files.
Smartphone users just upload to there facebook or instagram or God knows what we have now as standard, and be done with it.
So the tech is out there, HDR 12b4K REC 2020 color (new colorspace profile to replace the good old sRGB standard.) As long as there isn’t a flood of content to use for viewing those extra’s, only the one’s who want to be the first adapters will buy this. and commercial bennefit is bount to the mass.
So i don’t think DxOPL should be one of the first adapters and risk to be taken the wrong turn in this choice. Still i hope my new smart TV is one of those 12bHDR4K screens 
If I understand JXL correctly, the commercial benefit for the likes of Facebook and Google will be felt by less storage and lower bandwidth needs. It has that potential for greater bit depth and bigger files but for ordinary use it’s quicker and smaller.
HEIC is basically an image format hacked from a video format. It is not optimized for still frames. In fact the largest resolution supported in the frame coding is 8k. While hidden from the user frames larger than 8k are coded as multiple frames in the same image and there can be artifacts at the frame boundaries.
As I understand kt JPG-XL is an image format through and through with support for high bit depth (higher than HEIC) and terapixel images.
The other thing is the reference encoder/decoder is royalty free, open source, and freely available. Presumably it would just need to be integrated into DXO…. Not saying it’s super easy… but much of the hard parts are done already.
2 Likes
For a software developer, no feature if free. Some, like this one, are relatively low-cost (unlike adding the patent and royalty nightmare of HEIC, at least for commercial software). On the other hand, there are occasionally feature requests which are free and important to to which DxO just can’t get around: Add ‘Deselect All’ Filtering option in Image Browser. The inability to deselect all filters in the image browser has been plaguing DxO Photolab users since at least Photolab 2.
Adding a simple ‘Deselect All’ option would be:
- extremely easy
- beneficial to all Photolab users
Instead of DxO are holding us hostage to a new and “reimagined” image browser to add basic functionality. Support for additional experimental file formats does have a real coding support cost and questionable benefits. I’d prefer DxO took the easy wins first.
If JXL flourishes, by all means though. Sounds like a good idea.
5 Likes
Let’s get HEIC working first so that we can process years-old iPhone captures.
Haha, I can totally relate to you using this thread as an excuse to mention that totally brain-frying frustration! I agree with that one. It is so thoughtless. My main one is how frustrating it is to make subtle adjustments to warmth and hue on a control point! I’d trade having that fixed for having JXL support any day.
1 Like
HEIC is a bigger problem than JXL as there are enormous royalty payments, slanted in favour of multinationals like Apple (i.e. high per unit fees, but with a large but flat maximum payment). I’ve personally tested processing HEIC photos vs processing JPG conversions from HEIC. There was no difference in quality. HEIC has technical potential but current iPhones are not using that potential. Resurrecting support for the conversion of iPhone DNG on the other hand would make a huge difference.
3 Likes
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.
1 Like
Unfortunately this isn’t practical without separate scripts to transfer metadata. I looked at something similar before. There are improved JPG compressors that produce better quality for a given file size but you have to export tiff and standard JPG from PL, then convert the TIFFs, and then copy the metadata from the PL JPGs to the converted JPGs and then delete the TIFFs and the PL JPGs.
Cumbersome.
What is the basis of this statement? According to information on Wikipedia, they do not hold any of the patents involved, so will be paying handsomely for all their devices to use it.
That’s a great idea! One reason I like this is because I have my doubts about JPEG XL. Aside from technical capability, it has all the same promises that HEIC had… and JPEG2000 before that… and where has that got us? Nowhere fast. Meanwhile, the next version of Safari on all Apple platforms is adding support for AVIF coded images in HEIF containers. In fact, iPhones already do — I tested some out last night.
In other words, we have image formats coming out our ears and no-one can say which one will actually make a go of supplanting JPEG/PNG/GIF.
This is pretty much what I do to get my Lightroom keyword hierarchy attached to my PL-exported JPEGs. I have it pretty much automated. I export from PL, then use a preset to export from Lightroom. The LR preset is just a tiny JPEG but it has all the keywords and a special filename suffix. My automation tool (Hazel) then spots the suffix and uses exiftool to copy the keywords over.
Yep, I even mentioned one of them (guetzli) in my post. And I use jpegoptim all the time.
TIFF files support exif, and DXO writes most of the metadata from the raw file into the tiff exif fields (though some of it ends up in tiff-specific fields which aren’t exif). It’s kind of weird that imagemagik doesn’t seem to propagate exif data from tiff to jpeg; it’s certainly capable of reading it from the tiff, and it does propagate it for jpeg-to-jpeg conversions. That should probably be treated as a bug in ImageMagik. I haven’t actually tried out whether the reference encoder for jxl propagates metadata or not.
Hm, that appears to be correct. I’m not sure why I thought otherwise. However, I still think that HEIC’s limitation to a maximum resolution of 8192 x 4320 makes it a non-starter for many serious photography tasks. I think AV1/AVIF is a more likely bet, especially now that google is requiring all android devices to include hardware-accelerated support for it.
Yes, we’ve seen so many would-be jpeg challengers come and go. As I mentioned, however, JPEG XL is unique amongst those in offering a mode where it can losslessly transcode to/from JPEG, which makes it much less risky to adopt for several use cases.
Also, none of the other challengers paid a lot of attention to being compute-efficient for devices to encode (unless you count JPEG XR, which was otherwise basically J2K but with some bonus Microsoft-owned patents to pay royalties for); an iPhone may have plenty of compute power to burn encoding images, but for a device with a smaller battery pack, like an SLR or mirrorless camera, taking 10x less compute power to encode is a pretty big deal. On the decode side, too, of the more modern formats only WebP achieves similar performance to JPEG XL.
That said, while JPEG XL has a lot going for it, the spec is technically not yet fully ratified (although the bitstream definition has been, so files encoded in the format today are guaranteed to forward compatible with whatever changes may happen during the remainder of the standardization process). So in that regard it’s premature to ask developers to support it. Thus the suggestion of a plugin API.
1 Like