Which Metadata Version

[sunset100]

Lightroom Version Number

Lightroom Classic 10.2 release

Operating System

1. macOS 11 Big Sur

Some of my files have a message attached that says "The metadata for this photo has been changed by both Lightroom and another application. Should Lightroom import settings from disk or overwrite disk settings with those from the catalog?". I am given the options of overwriting settings, importing from disc, or cancel. How do I decide which one?

 

[johnrellis]

If you haven't modified the photos or their metadata using an external application (such as Adobe Bridge), then choose Overwrite, which will write the settings from the LR catalog into the photo files. LR has never gotten Metadata Status completely correct, and it not infrequently gives spurious warnings about conflicts.

 

[PhilBurton]

If you haven't modified the photos or their metadata using an external application (such as Adobe Bridge), then choose Overwrite, which will write the settings from the LR catalog into the photo files. LR has never gotten Metadata Status completely correct, and it not infrequently gives spurious warnings about conflicts.

What John said.

I have had the same experience as the OP, multiple times. And each time it was impossible that another application could have modified the metadata, since once I import a photo into LR, I never touch that file again with EXIFTool (actually EXIFToolGUI), as an example.

 

[clee01l]

If you do not touch your image file managed by Lightroom by an external editor, you in theory should never see this message. However if you have a system backup app or any other non photo editor app that will open the image file for reading, then you can still get this message.

In the long run, the message is irrelevant. All of your metadata that you will use is ALWAYS going to come from the metadata stored in the Lightroom Classic catalog file. As long as you keep the catalog metadata up to date, you should never worry about the message.

This message is so unimportant that when Adobe developed Lightroom for the cloud it is never an issue.


Sent from my iPad using Tapatalk

 

[PhilBurton]

If you do not touch your image file managed by Lightroom by an external editor, you in theory should never see this message. However if you have a system backup app or any other non photo editor app that will open the image file for reading, then you can still get this message.

[ ... ]


Sent from my iPad using Tapatalk

Cletus, Interesting point. I'm running Windows 10. If Windows displays a thumbnail of a photo, does that count as "reading" the file? I've never watched for a pattern between viewing photo thumbnails in Windows and this message in LR.

Phil

 

[clee01l]

Cletus, Interesting point. I'm running Windows 10. If Windows displays a thumbnail of a photo, does that count as "reading" the file? I've never watched for a pattern between viewing photo thumbnails in Windows and this message in LR.

Phil

I’ve never considered the thumbnail in Windows. It was my impression that Windows kept a separate Thumbs.db of the image thumbnails inside each folder that contained images. If that is still the case, then Windows explorer is never going to read the metadata in the file beyond the filename.
It is the backup app that set the Modified Data Tag (MDT) when ever there is a backup made. When the MDT changes because another app has changed the image file, then the Backup app knows to make a new MDT and backs up the file anew.


Sent from my iPad using Tapatalk

 

[gegjr]

My question has always been why doesn't Lightroom provide information about which option is the latest thereby giving the user an intelligent option or why doesn't Lightroom just update to the latest information? This has been a painful bug in Lightroom since way back to the days long before Lightroom-desktop (online) and the new Creative Cloud echo-system.

 

[clee01l]

My question has always been why doesn't Lightroom provide information about which option is the latest thereby giving the user an intelligent option or why doesn't Lightroom just update to the latest information? This has been a painful bug in Lightroom since way back to the days long before Lightroom-desktop (online) and the new Creative Cloud echo-system.

It’s not a bug. But a failure on the part of the user to get an understanding of what is happening. IF you never change the metadata of the original outside of Lightroom (and you shouldn’t) Th original image will have the original metadata that was written to the file IN the camera. This original metadata is what is in your catalog. Other process (you backup app for example) may touch the file and make a change that has nothing to do with the camera recorded metadata causing Lightroom to display the message. The obvious answer here is that all of the correct metadata is in the Lightroom catalog and will be supplied to any exported derivative JPEG. IOW, ignore the message.

The message is so trivial and unimportant that in the cloud version of Lightroom, it does not exist and you NEVER access the original file except through Lightroom.

The only time this message might be important is if you work with Bridge on the same file and metadata changes made in Bridge won’t be reflected in the Lightroom Catalog file. Bridge is a redundant app replaced along with ACR with the Lightroom Classic product. Your should not need to use Bridge or ACR on the same file that you import into Lightroom Classic.


Sent from my iPad using Tapatalk

 

[gegjr]

I emphatically disagree with your characterization of the user being at fault for heeding the message or that the user is somehow not understanding the message. Although a bit exaggerated as an example, your response is like blaming the opressed for allowing themselves for being oppressed! IMHO, Adobe should not show this message simply because the photo may have been opened in another program. Rather, the warning should be reserved for critical metadata changes such as altered dates or changes in keywords. In fact I would go so far as to say even changes to image for exposure, contrast, color, etc outside LIGHTROOM should be ignored because LIGHTROOM should assume that any image indexed in it's catalog is being managed exclusively by LIGHTROOM!

 

[johnrellis]

LR was designed to show the metadata status based on the actual contents of the metadata fields stored in the catalog and in the photo's file, ignoring the file's date-modified. When LR notices a file might have changed on disk (using the file's date-modified), it compares the catalog metadata fields with the file's fields, yielding these possible statuses:

Up To Date: The catalog's fields match those in the file.
Has Been Changed: The catalog's fields have been changed but the file's fields have not.
Changed On Disk: The catalog's fields haven't been changed but the file's fields have been.
Conflict Detected: Both the catalog's fields and the file's fields have been changed.

So if some other program changes the file's date-modified without changing the metadata fields, normally the status doesn't change.

You can see how this normally works by using Exiftool to change a file's EXIF:UserComment field. If you use Exiftool to set that field to its current catalog contents (thus changing the file's date-modified but not the field itself), LR continues to show Up To Date. Only if Exiftool sets the field to a different value does the status change. (Be careful if you test this yourself -- once LR changes the status from Up To Date, it never goes back to Up To Date until you save the metadata or read it from disk.)

But LR's metadata status has always been buggy (at least since I started with LR 3). The most common complaint over the years has been about spurious Conflict Detected -- the user has definitely not made any changes to the metadata fields, but LR thinks differently. I get some of these every year, it seems. I do Metadata > Save Metadata To File to get rid of them.

It's been very difficult to spoon-feed Adobe with a tidy, simple recipe for reproducing these bugs, and Adobe hasn't paid much attention to them. But one particular bug introduced in LR 10.1 is easy to reproduce: LR doesn't properly handle reading crop angle from the file's metadata, and it shows incorrect status.

(Old Car Talk fans might remember Click & Clack's recommendation to cover spurious engine warning lights with black electrical tape so that it wouldn't annoy you :->)

 

[gegjr]

LR was designed to show the metadata status based on the actual contents of the metadata fields stored in the catalog and in the photo's file, ignoring the file's date-modified. When LR notices a file might have changed on disk (using the file's date-modified), it compares the catalog metadata fields with the file's fields, yielding these possible statuses:

Up To Date: The catalog's fields match those in the file.
Has Been Changed: The catalog's fields have been changed but the file's fields have not.
Changed On Disk: The catalog's fields haven't been changed but the file's fields have been.
Conflict Detected: Both the catalog's fields and the file's fields have been changed.

So if some other program changes the file's date-modified without changing the metadata fields, normally the status doesn't change.

You can see how this normally works by using Exiftool to change a file's EXIF:UserComment field. If you use Exiftool to set that field to its current catalog contents (thus changing the file's date-modified but not the field itself), LR continues to show Up To Date. Only if Exiftool sets the field to a different value does the status change. (Be careful if you test this yourself -- once LR changes the status from Up To Date, it never goes back to Up To Date until you save the metadata or read it from disk.)

But LR's metadata status has always been buggy (at least since I started with LR 3). The most common complaint over the years has been about spurious Conflict Detected -- the user has definitely not made any changes to the metadata fields, but LR thinks differently. I get some of these every year, it seems. I do Metadata > Save Metadata To File to get rid of them.

It's been very difficult to spoon-feed Adobe with a tidy, simple recipe for reproducing these bugs, and Adobe hasn't paid much attention to them. But one particular bug introduced in LR 10.1 is easy to reproduce: LR doesn't properly handle reading crop angle from the file's metadata, and it shows incorrect status.

(Old Car Talk fans might remember Click & Clack's recommendation to cover spurious engine warning lights with black electrical tape so that it wouldn't annoy you :->)

I do in fact remember the Click & Clack's episode. However, there's only 1 idiot light on a car's instrument panel but there's an idiot light (warning message) on every file LR suspects may have changed not to mention the thumbnail will be in a different place every time rendering the Click & Clack solution unusable . This is of course all tongue in cheek.
More seriously I'd like for LR to provide a clue as to what in the file metadata fields is suspected to have been changed, such as "last opened date" or is that too much to ask?
Does LR report a possible file change if an image is opened outside LR, eg in Windows-10 Photo app, changes such as crop resolution made and saved to a new file name?

 

[johnrellis]

there's only 1 idiot light on a car's instrument panel but there's an idiot light (warning message) on every file LR suspects may have changed

That's why I do Metadata > Save Metadata To File to get rid of the spurious warnings -- it's my equivalent of not-very-sticky black tape, which I have to keep sticking back on every time LR reports a new spurious conflict.

I'd like for LR to provide a clue as to what in the file metadata fields is suspected to have been changed,

There's a 10-year-old feature request for that:
https://feedback.photoshop.com/conv...f-metadata-conflicts/5f5f44ee4b561a3d4229b0e0

Does LR report a possible file change if an image is opened outside LR, eg in Windows-10 Photo app, changes such as crop resolution made and saved to a new file name?

I'm not sure the exact steps you're describing. But when I open a JPEG in the Windows 10 Photos app, crop the photo, and save it as a new copy, the original photo isn't modified (it's file-modified date stays the same), and LR doesn't report any change in metadata status.

 

[gegjr]

Don't know why you don't understand the steps used to open an image, modify resolution or size in Microsoft photo then saving with new name to another location? Especially since you explained that LR doesn't recognize action as a metadata change. But it is my experience that opening a photo on the Windows-10 OS causes a change to last modified date, (even if no change to file), which in turn triggers LR to report a metadata warning when the file is opened in LR.
Furthermore if the bug notification to Adobe is 10 years old I don't get why Adobe hasn't fixed what I consider an annoying bug.

 

[clee01l]

.
Furthermore if the bug notification to Adobe is 10 years old I don't get why Adobe hasn't fixed what I consider an annoying bug.

Adobe does not consider this to be a bug. While it may be an annoying warning message, it is a warning message. Adobe has no way of knowing What you did outside of the Adobe Eco-system and in particular the Lightroom Classic catalog. Hence it detects a change between what is in the catalog metadata and the metadata in the file and notifies you with a warning message. You can decide based upon what you might have done to the file in question whether it is important.
My contention is that the original file should never be accessed by any other app capable of modifying the original metadata as imported by Lightroom If I maintain the original image integrity in that way, it is irrelevant what the metadata in the original file is saying. I learned a long time ago that I would go crazy trying to keep the two sets of metadata in sync. That they get out of sync is trivial and best ignored. As I pointed out in Lightroom (cloudy) this never is raised as an issue.


Sent from my iPad using Tapatalk

 

[johnrellis]

But it is my experience that opening a photo on the Windows-10 OS causes a change to last modified date, (even if no change to file),

I'm suprised by that -- in general, I haven't seen a photo viewer change a photo file's date-modified just by viewing the photo. Here's a video of my Windows 10, showing that opening a JPEG in the Photos app doesn't change its date-modified:
https://www.dropbox.com/s/3x0uw0y7d8otos1/windows-photos-modifed.2021.06.12.mov?dl=0

 

[johnrellis]

I don't get why Adobe hasn't fixed what I consider an annoying bug.

There are many, many bugs that Adobe doesn't fix, unfortunately. In general with some exceptions, Adobe doesn't try to fix a bug unless there is a precise recipe that allows them to reproduce it, and with most of the spurious metadata warnings, no one has posted such a recipe (I tried a couple of times many years ago but failed). In the six-month-old LR 10.1 bug report I linked to above, I was able to post a precise recipe involving Crop Angle, and maybe Adobe will fix that bug this year; but I'm certain that most spurious metadata warnings are caused by something different.

 

[gegjr]

Adobe does not consider this to be a bug. While it may be an annoying warning message, it is a warning message. Adobe has no way of knowing What you did outside of the Adobe Eco-system and in particular the Lightroom Classic catalog. Hence it detects a change between what is in the catalog metadata and the metadata in the file and notifies you with a warning message. You can decide based upon what you might have done to the file in question whether it is important.
My contention is that the original file should never be accessed by any other app capable of modifying the original metadata as imported by Lightroom If I maintain the original image integrity in that way, it is irrelevant what the metadata in the original file is saying. I learned a long time ago that I would go crazy trying to keep the two sets of metadata in sync. That they get out of sync is trivial and best ignored. As I pointed out in Lightroom (cloudy) this never is raised as an issue.


Sent from my iPad using Tapatalk

Of course you have right to your opinion and I have right to mine. So I agree to disagree. I still feel LRC should not flag the image just because it was opened in another app. Also, many times it is more convenient for me to open a photo in another app sometimes.

 

[johnrellis]

LRC should not flag the image just because it was opened in another app.

No, it shouldn't, unless the other app is changing the actual metadata of the photo.

 

[clee01l]

No, it shouldn't, unless the other app is changing the actual metadata of the photo.

Lightroom has no way of knowing what has happened to the file. It only can see that the modified data date is different between what is on the file and what is on the record in the catalog. That is why it is up to you to decide if this is important or needs addressing.


Sent from my iPad using Tapatalk

 

[johnrellis]

Lightroom has no way of knowing what has happened to the file.

As I explained above, when LR sees the file's date-modified has changed, it compares the metadata fields in the catalog with the fields currently in the file to determine if any of them have changed. If the date-modified has changed but the actual metadata fields haven't, then the Metadata Status will still be Up To Date.

Here's an experiment that demonstrates that, using Exiftool to change the EXIF:UserComment field, first to the current value stored in the file and then to a new value. Only when the contents of the field change does LR change the Metadata Status to Changed On Disk.

1. Import a photo "file.jpg" that already has "Hello" stored in its EXIF:UserComment field.

2. Do the command

touch file.jpg

to change its file date-modified to "now". (This is a Mac command, there's probably a Windows equivalent I can't recall right now. But you can skip this step if you're on Windows.)

3. Restart LR (to force it rescan the metadata status immediately) and notice the Metadata Status is still Up To Date, even though the date-modified has changed.

4. Run the command

exiftool -exif:usercomment="Hello" file.jpg

which will store the same value in UserComment that is already stored there.

5. Restart LR and notice the Metadata Status is still Up To Date, even though the date-modified has changed.

6. Run the command

exiftool -exif:usercomment="Hello world" test-modify.jpg

to change UserComment to a new value.

7. Restart LR and observe the Metadata Status is now Changed On Disk.

 

[clee01l]

If the date-modified has changed but the actual metadata fields haven't, then the Metadata Status will still be Up To Date.

This was not my experience several years ago. Perhaps that has changed, but then, when this earlier version Lightroom was the only app to access my images with the exception of the system backup app and the Lightroom metadata HAD to be in Sync, I still got the out of sync warning. Since I encountered this situation several years ago, I stopped paying attention to the metadata warning message.

Now just looking at Images that have only been sync'd from Lightroom (cloudy), the Metadata status on some reads "up to date" and on others it reads "has been changed". Most of the images synced from Lightroom (cloudy) reads "has been changed". None have has any change made since being imported in to Lightroom Classic via the sync process.