JPEG XL metadata still written into an XMP, not file directly

[Doppelkammertoaster]

I am posting this here, but I found the issue first in Bridge and then in Lightroom, so I assume it's also an issue here, as it seems by design. And it just continues a trend which I begin to despise in Adobe.

No Adobe product I have tried can write metadata directly into an JPEG XL. They all create a xmp file in the same folder instead. Once that file is deleted, the metadata is gone. But according to the file format specifications, JPEG XL does support it, of course it does.

And that Adobe software does not, is not acceptable. JPEG XL is a modern file format, the successor to JPEG. It is widely superior to it, and should be fully supported. The same also applies to mp4 audio files, that Audition can't write, for whatever reason. All Adobe products seem to support Adobe's own DNG file format, which seems to actually uses some JPEG XL technology in its latest iteration.

So, I am sharing this as a bug. As this should not be the case. It can't be, that we need more and more external software to accomplish simple tasks, like writing metadata directly into a modern image file format, or exporting flacs to mp4s.

Someone already wrote about this in Dec. 2023, and the answer was, that Lightroom can totally write the metadata without errors. But that is not true. It does not write the data into the file, but into an xmp. That is not the same, and it makes the software not fit for this day and age.

Adobe has to get its stuff together, and stop googling around here, and only push their own file format, as Google does with their Webby file format, by dropping JPEG XL, despite it being technically superior and designed for needs of the future.

This behaviour and unwillingness will not make me using more Adobe products, and instead just continue to drop them, as I already have, once an alternative is found. Software should be made for the needs of the customer, not of the shareholders.

I also don't care how popular Bridge or Audition is. That is not an excuse to not support it fully. As long as it is part of your product offer, that we pay for, they have to be improved and kept fit for the needs of the customer. And that includes modern files formats that you don't own, Adobe.

[John R Ellis]

"No Adobe product I have tried can write metadata directly into an JPEG XL"

Hmm, I just tested LR 13.5.1 and LR 12.3 (which introduced JPEG XL support), and both versions wrote changed metadata into my sample .jxl file rather than a .xmp sidecar.  

Do the LR menu command Help > System Info -- which version of LR Classic are you running?

Perhaps there's some difference between the JPEG XL files we're testing with. Upload a problem .jxl to Dropbox, Google Drive, or similar and post the sharing link here. It would be good to get the bottom of this and file a bug report if necessary.

[Doppelkammertoaster]

I must say, I stand corrected. After you wrote this, I installed classic as well, but before it was done installing, I also tried another vector.

Long story short, it turns out the issue is either the implementation or version that the program I used to convert files into jxl is the problem. I used Irfan View, as Bridge can't do it. With it, I also have thumbnails when installing the WIC for windows for xl. Which in turn vanished, once I wrote the xmp-data with Exiftool into the jxl, as Bridge/Lightroom only used xmp files.

But then I used the official encoder for XL. Windows doesn't show me a thumbnail for it, but Bridge can now just write the metadata without using an xmp-file.

So, an apology is in order. Adobe did implement jxl into Bridge and Lightroom, in a way that they can write metadata directly, but this only seems to work with later/or the latest iteration of the jpeg xl.

I wasn't aware, that my encoder program was the issue, as the support had been added recently. But apparently now is, that they didn't use the most recent one, or didn't do it well. And the WIC component isn't using the latest version either, and that is why it can't show thumbnails for jpeg xl files, that are using a later version.

Some of my critique still stands, in the sense, that Bridge (and Photoshop) should be able to also export into jxl, where DNG is possible. But there may be more going on behind the curtains, that I am not aware of, and I should have been more humble in inquiring about the reasons why Bridge can't. And the same maybe applies with Irfan View. Again though, I am not aware Adobe said anything about the implementation of jxl into PS and Bridge (and Lightroom), that would have shed a light on the issue, but maybe I also didn't look enough.

So, whoever is reading this later, I am sorry. But I hope I can still get a response of, why Bridge and PS can't export into jxl to begin with. Is this because of the development of jxl? The latest 'complete' release (not a programmer) was in 2021, so I assumed, Bridge and Lightroom should be able to use it.

So, to answer your question, it could be, that earlier iterations of jpeg xl, did not support metadata written into their data stream itself yet. The program I used to convert files, seemed to use that earlier iteration. Bridge and Lightroom then could read it, but not write it, and created xmp-files instead. And Exiftool could, but was giving a warning as well.

The image I converted now, has no thumbnail in windows anymore, but can be read and written by Bridge and Lightroom as any other image.

[John R Ellis]

"But I hope I can still get a response of, why Bridge and PS can't export into jxl to begin with."

I think it would be better to post that in the Bridge and/or Photoshop forums. While there are people in this forum quite knowledgeable about both apps, there are far more in the appropriate forums.