@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.
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.
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.
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.
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.
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.
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.
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.
The final spec was published earlier this year (in April), after being submitted in 2021.
Adobe added support in Camera Raw (for exports only?).
Serif added support in Affinity Photo 2 (just released).
Open source photo / imaging software is picking it up too.
Image hosting services such as Cloudinary are very positive: The Case for JPEG XL.
On the Web browser side, Firefox has an experimental implementation, and Chrome had one but just announced that they were not pushing it forward, preferring to focus on AVIF.
Hopefully more photo software will pick it up, maybe some cameras too in the future (that may take a few years).
The main competitor of JPEG XL is AVIF. The WebP2 format was abandonned this year. JPEG XL is better than AVIF for medium to high quality encoding (which is what you want for photos), and worse for low quality/low bandwidth encoding (which is what you want for video). Browsers would prefer to only have to support AVIF, because they’re already shipping support for the AV1 video codec and AVIF is a subset of that, so they basically get AVIF support for free. But if the image creation ecosystem (photo, graphics) has no interest in AVIF, and if it adopts JPEG XL then browsers will probably follow suit.
Safari 17 will ship with JPEG XL and AVIF support.
The Chrome team decided against adding JPEG XL support to Chrome, citing low interest, but there’s been a lot of pushback from web developers (including some big companies).
iOS 17 and macOS 14 will ship with JPEG XL support in built-in apps (on macOS that would include Finder, Preview, probably Mail.app since that uses Safari’s engine, probably Photos too).
Support landed in Linux desktop environments KDE and Gnome.
No news on the Windows side.
No news on the Android side.
In graphics/photo software
Tools like ImageMagick and ffmpeg support JPEG XL. You may not be familiar with these tools, because they’re command-line utilities, but they’re used on many servers that process images and are often embedded in other software.
Affinity Photo supports JPEG XL, as mentioned above.
Adobe: support in Camera Raw, Lightroom Classic and Lightroom (source)
Several open-source graphics software support JPEG XL: Gimp, Krita, Darktable (source: just downloaded it to check).
Looks like Paint.NET also supports it.
Pixelmator Pro and Photomator will support JPEG XL on iOS 17 and macOS 14 (source).
Photoshop: no direct support yet (besides going through Camera Raw to import a JPEG XL image to a bitmap layer in a PSD).
Capture One: no support currently, no signal from devs.
ON1 Photo Raw: no support currently, no signal from devs.
Overall it looks like the graphics/photo ecosystem is half-there, and hopefully support in operating systems (for file browsers, file pickers, but also often the image rendering system libraries used in a lot of apps) will generalize and not stay at Apple + Linux.
Surely that is irrelevant? Unless phone manufacturers drop JPEG and adopt JXL as the default file format for photos taken with their devices JPEG will continue to rule the world.
…even this won’t move the needle, I don’t think. iPhones already record HEIC but by default any export is converted to JPEG “for compatibility”.
What will be needed is for web developers/publishers to recognise browser support and start using these formats. Until Chrome and Firefox support it, that simply won’t happen.
Irrelevant to the goal of “kill JPEG and replace it with JPEG XL”, sure. But I never stated that as a goal.
Personally, my goals would be:
To be able to export RAW photos as JPEG XL for archival purposes. This one is achievable as soon as the software I’m using is offering JPEG XL in its export feature, and will be practical for me as long as the underlying operating system also supports JPEG XL (given that I’m either on macOS or Linux, I should be good here).
To be able to shared those exported JPEG XL photos instead of JPEG, to achieve a smaller file size or higher quality at the same file size. This one relies on the recipient having software that supports JPEG XL, so for this one I’ll probably wait for Windows to support JPEG XL.
None of those goals rely on smartphone camera software creating JPEG XL images instead of JPEG or HEIF.
Again that’s a different goal (which I understand as “making websites use JPEG XL instead of JPEG, WebP or AVIF”). Not sure I even care about this goal. I’m a web developer, and being able to use JPEG XL on the Web would be nice, but I don’t care about it as much as photo and graphics workflows.
I don’t understand the focus on “JPEG XL has to be everywhere or it’ll be useless”. There are a bunch of useful image formats that are commonly supported in photo software but not in browsers (JPEG 2000, HEIF, DNG even…), and some browser-specific formats that are not supported outside of browsers (WebP). If anything, browser-specific formats are more trouble than formats that only work outside of browsers, due to how 99.9% of users interact with browsers (download images directly from the site; but upload images to a web server that will reprocess the image).
In any case, I expect that if JPEG XL gets a foothold in graphics and photo software (it’s half there) and gets support in desktop operating systems (here the big question will be Windows support), then Firefox and Chrome will add it. It’s already a compelling format for the Web, with significant demand from big site publishers, and the Chrome team is only stalling because they champion the competing AVIF format (and Firefox is stalling because they are understaffed). With the extra pressure of adoption of JPEG XL in desktop workflows, my guess is that it will tip the balance towards adding it to Chrome (and Firefox will follow for compatibility with Chrome+Safari).
But even if Chrome never adds it, I’ll be happy enough with good support in photo software and in operating systems (especially file explorers/viewers/pickers).
Fair points, all. I was indeed thinking on a “replace JPEG” footing. Though if browsers did all support it, I think it would only help your goals, too, as software vendors would be more inclined to include it as an export format.
) the place to watch there proccessed files.
Safari 17 will ship with JPEG XL and AVIF support.
The Chrome team decided against adding JPEG XL support to Chrome, citing low interest, but there’s been a lot of pushback from web developers (including some big companies).
Firefox is in “wait and see” mode (