P: Content Credentials-signed images will create an XMP file for JPEG images

[lukasb79690852]

I recently come across the following Issue:

I have a bunch of jpg files I have post-processed in Photoshop that I want to add geo locations to using the Lightroom Classic map module. After adding the locations I mark all images and do right click - metadata - save metadata to file. For some jpg files the data is written into the jpg file (desired behavior and how I know it from LR Classic for the past 6 years), while for others LR creates a seperate xml file (same location same name as the jpg) containing all metadata including the location.

Since this is a recent thing for me I suspected LR 14 to be the issue so I downgraded back to 13 but the issue persists.

I already cleared out my complete LR catalog and only importet a hand full of jpg files to test but the issues persists.

The issue can be reproduced, it is always the same jpgs causing the issue.

When I open one of the not functioning jpg files in Photoshop and save it again in a new location the issue persists. When I open it, create a new document of the same dimensions, mark all in the original, copy across to the new document and then save the new document as jpg I can then add gps locations to the new jpg in LR as expected.

I can also copy the gps data from a working jpg to one of the ones LR refuses to add gps data to using exiftools so the jpg file does not seem to be inherently broken in some way.

There is no different between the jpg files LR can write to and the ones where it insists on writing a xml file. They were taken using the same camera and have gone through the same workflow.

Any help would be appreciated since as of right now I am resorting to using a dummy image I assign the desired location to in LR and then use command line + exiftools to copy the gps tag across to the non functioning jpg which is extremely cumbersome.

[lukasb79690852]

After posting I have tested this on a completely different Laptop and again the issue persistes for the same jpg files.

I have attached two sample files:.

working.jpg - LR Classic writes the metadata into the file as expected

not_working.job - LR Classic creates a seperate not_working.xml and writes the metadata into that

[JohanElzenga]

Most likely the image is locked, so Lightroom can't write to it.

[lukasb79690852]

Thanks for your reply, could you elaborate on how to unlock a file? I checked and I found no way to lock or unluck a file anywhere. Under file properties in Windows the files are not marked as read-only.

[JohanElzenga]

I'm a Mac user, so I can't tell you how to check this in Windows. I'm sure Google can tell you. Do check if the problem images are in the same folder, because then it is also possible that the folder is read-only.

[lukasb79690852]

They are all in the same folder. I have googled already and besides permissions which are identical for all images there seems to be nothing. Did you by any chance try to download the two sample images I have attached to my first reply and checked if you can write metadata into both of them? Thank you for your help.

[JohanElzenga]

No, I did not download them, because I'm not sure that a file that is locked on your computer will still be locked when uploaded and downloaded. Anyway, I assume the answer is as given by John Ellis, as his answer is marked as correct.

[johnrellis · Accepted solution]

It appears this behavior is caused by the addition of Content Credentials to the JPEG, which are added to the JUMBF metadata section.

In the past, when LR didn't know how to update an industry-standard file format, LR would write a .xmp sidecar instead. For example, when LR first added support for HEIC, it wrote .xmp sidecars; a later version of LR wrote directly into the HEIC file. Similarly, LR still creates .xmp sidecars for AVIFs, even though that format supports updatable metadata. (Actually, when LR first added support for AVIF, it would corrupt the files if you did Save Metadata To File, so instead of fixing the bug Adobe changed LR to write .xmp sidecars instead.)

So perhaps LR doesn't yet understand how to update files containing JUMBF sections, and the developers decided to expediently create .xmp sidecars instead?

To reproduce this behavior in LR 14.0.1 / Mac OS 14.6.1

1. Import the attached file working.jpg.

2. Observe that Metadata > Save Metadata To File writes to the file directly.

3. Export working.jpg back into the catalog with these Export options:

4. Select the exported/imported working-2.jpg and do Metadata > Save Metadata To File. Observe that a .xmp sidecar has been created for it.

[johnrellis]

@Rikk Flohr: Photography, LR 14.0.1 creates .xmp sidecars for JPEGs with content credentials. Please verify this is as-designed or submit a bug, thanks.

[Rikk Flohr: Photography]

As-designed

In case of already signed JPEGs, metadata and develop settings are written to sidecar XMPS so as not to invalidate the CAI signature.

[johnrellis]

@Rikk Flohr: Photography: "In case of already signed JPEGs, metadata and develop settings are written to sidecar XMPS so as not to invalidate the CAI signature."

Thanks, makes sense. I think this will turn into a relatively frequent question as content credentials start being used more.

[Rikk Flohr: Photography]

I've converted this thread to be the Primary Post for this topic. 

[lukasb79690852]

Thanks, that's it! As to why it only happens to some photos and not to others, it seems like using generative fill for the object remove tool in Photoshop will create the JUMBF section.

[johnrellis]

@lukasb79690852: "As to why it only happens to some photos and not to others, it seems like using generative fill for the object remove tool in Photoshop will create the JUMBF section."

Looking at the metadata of not-working.jpg, it looks like you've enabled content credentials in Photoshop, which is why there is a JUMBF section in that file.  If you disable content credentials in Photoshop, will using generative fill on the file still cause your LR to write .xmp sidecars?

[lukasb79690852]

This is from an Adobe website: Adobe automatically applies Content Credentials to assets generated with Adobe Firefly features, such as Generative Fill in Photoshop. To learn more, check out Content Credentials for assets generated with Adobe Firefly.

To me this reads like I cannot disable content credentials when I used Generative Fill. I have definitely never actively enabled content credentials or selected anything to that effect when saving my images as jpg.

[johnrellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

Thanks, that's interesting. Reading that article, which is a little ambiguous to me, and doing some experimentation shows that PS automatically adds credentials to a saved JPEG when you apply Generative AI Remove, and you can't turn that off (though it's easy to use a third-party tool to remove them later). 

Whereas LR only adds credentials if you explicitly enable them in Export, regardless of whether you've applied Generative AI Remove.

Here are my Photoshop settings used when I did the testing:

[lukasb79690852]

To anybody interested in how to remove them using third-party tools.

download exiftool

open a command line inside the downloaded folder where exiftool.exe is located

run the following command: exiftool.exe -jumbf:all= "<path to photo>"

alternatively to apply to all photos inside a folder: exiftool.exe -r -jumbf:all= "<path to folder containing photos>"

[Robert Ripps]

I have LRC set to create .XMP files when I import raw images, applying develop settings and metadata to them, and have those changes/additions automatically written into the XMP files, but now it seems that LRC has started creating XMP files for some of some JPG images I just added to the catalog. For 26 files I added, it created .XMP files for 7 of them, even though I did not do anything to the files in Lightroom other than Edit Capture Time to Change to file creation date for each image to all 26, which never caused Lightroom to create an .XMP file before.

Previously adding JPG images to LRC’s catalog did not create the .XMP files in the folder they reside in, only adding or applying changes to raw files.

So not sure if something has changed with how Lightroom Classic treats JPG files, or if I have accidentally changed some setting somewhere.

Thanks.

Lightroom Classic 14.1.1, macOS 14.7.2

[JohanElzenga]

Are you adding JPEGs to the catalog that you previously exported? If so, then did you perhaps enable content credentials? I believe that enabling content credentials causes Lightroom to write metadata to XMP files on export, even for images that normally would not have an XMP file.

[johnrellis]

"I believe that enabling content credentials causes Lightroom to write metadata to XMP files on export, even for images that normally would not have an XMP file."

Adobe verified this:

https://community.adobe.com/t5/lightroom-classic-discussions/p-content-credentials-signed-images-wil...

[Lightboxx]

i have an issue with some JPG files in my library. just some JPG files not all!

i import my files, then i edit them and keyword them in lightroom.

i let LR write the keywords etc. directly into the TIFF and JPG files.

and that works 98% of the time for JPG files.

but for SOME JPG files an XMP sidecar file is writen, the keywords are not written directly into the JPG files.

instead LR creates an XMP sicecar file.

i tried CTRL+S, i tried the menu option to write metadata back into the files.

i let the system idle for 48 hours because i thought it might be written when the system is not in use.

nothing helped.

the files are not write protected, not in a specific folder.

i am not asking for advice how to setup lightroom. the settings are correct.
for 49 out of 50 files the metadata is writen into the JPG files correctly.
with TIFF there is no such issue at all.

it is extremly annoying to have XMP files beside JPG files.

also i want the metadata stored directly in the files as security should my library be corrupted.

what could be the issue?

windows 10, latest lightroom version.  

[johnrellis]

Upload one of the JPEGs and its .xmp sidecar to Wetransfer, Dropbox, Google Drive, or similar free service and post the sharing link here. I can put it under the microscope and file a bug report if necessary.

[Lightboxx]

i send a link to your inbox.

[johnrellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

Adobe's Inspect Tool shows that your sample image contains content credentials for content generated by Adobe Firefly via Photoshop:

According to this help page, "Adobe automatically applies Content Credentials to assets generated with Adobe Firefly features, such as Generative Fill in Photoshop", regardless of your Photoshop settings.

Because the JPEG contains content credentials, saving metadata into the file itself would invalidate the digital signatures on those credentials. So LR saves the updated metadata to a .xmp sidecar.  Given Adobe's policy about AI "transparency" and adding credentials automatically, I doubt that LR would ever provide an option to overwrite existing Firefly credentials.

A google reveals this post about how to remove the credentials within  Photoshop:

https://www.reddit.com/r/cryptogeum/comments/122v4yq/comment/lddr3vf/

There might be easier ways within Photoshop, I haven't looked.

It's technically trivial to remove the credentials using a tool like Exiftool. You could use the Capture Time To Exif plugin as an easy way to run Exiftool with a command line that removes the credentials.

[johnrellis]

Moderators, @Rikk Flohr: Photography, please merge with this FAQ thread:

https://community.adobe.com/t5/lightroom-classic-discussions/p-content-credentials-signed-images-wil...