Edit original in photoshop changes capture time, other oddities

[Linwood Ferguson]

Lightroom Version Number

9.2.1

Operating System

1. Windows 10

I thought I understood these things, but I clearly do not. I just walked very carefully through a set of time changes.

I started with a scanned TIFF image which contained the following after it was ADD'd to Lightroom from an Epson scanner.

c:\Junk>exiftool -a -u -g1 Baby_Book_921.tif | find /I "Time"
File Modification Date/Time : 2020:05:11 21:29:17-04:00
File Access Date/Time : 2020:05:11 21:29:17-04:00
File Creation Date/Time : 2020:05:11 21:29:15-04:00
Profile Date Time : 2006:02:02 02:20:00

At that time in LR the displayed capture time was 9:29:17. I think that's wrong to begin with, but only two seconds, however I I think I could force this to be wildly different by, before importing into LR, I change the access date on a file on disk (e.g. by, well, accessing it, like maybe I edit it in photoshop before import).

So I did an edit in photoshop, saved, and exited. LR updated the time to 9:19:15. That's more correct.

So I did an edit capture time. Note in Catalog settings I have the box checked for "Write date or time changes into proprietary raw files". I don't think TIFF is considered proprietary, but just in case. I changed it to 12/25/1955 9:00:00pm

Afterwards LR's display updated correctly, but the file itself was unchanged per EXIFTOOL.

I did a save-metadata -- file was updated.

c:\Junk>exiftool -a -u -g1 Baby_Book_921.tif | find /I "Time"
File Modification Date/Time : 2020:05:12 09:36:05-04:00
File Access Date/Time : 2020:05:12 09:36:05-04:00
File Creation Date/Time : 2020:05:11 21:29:15-04:00
Time Created : 21:00:00
Date/Time Original : 1955:12:25 21:00:00
Profile Date Time : 1999:06:03 00:00:00
Date/Time Created : 1955:12:25 21:00:00

That all looks correct.

So (at least) two questions: Doesn't it seem wrong that LR is using access date, not file creation (or modification even) date on import if there's no original/created in the metadata?

But secondly: It seems wrong that the edit capture time requires you to write metadata. That seems inconsistent with the "cannot be undone" warning.

Or is that normal/documented?

 

[Jim Wilde]

1) I thought LR uses the modification date/time when no capture date/time is present, e.g. with a scan. In your example both the modification date/time and the access date/time are the same, so why do you think LR has used the access date/time. Not saying it doesn't, but either could have been used in your example.

2) That's entirely expected that you have to save metadata in order to commit a capture date/time change to the file. How else could it be done?

 

[LouieSherwin]

Hi @Ferguson ,

The rules that Lightroom uses to populate the date used to be documented back in V3.x, However, that snippet of information was removed and does not seem to be something that Adobe wants to tell us. As I recall it was quite involved. I have found that the only way to avoid inconsistent behavior with the capture date is make sure the Original Date Time in the file is set to what I want it to be. Note that the Lightroom Edit Date Time does not set all relevant dates even when you tell it to update the original file. This can be a further source of confusion.

In the meantime you might want to try out Jeffery Friedl's MetaData Viewer. It will show you simultaneously what is in the file and what is in the catalog.

-louie

 

[Linwood Ferguson]

1) I thought LR uses the modification date/time when no capture date/time is present, e.g. with a scan. In your example both the modification date/time and the access date/time are the same, so why do you think LR has used the access date/time. Not saying it doesn't, but either could have been used in your example.

My apologies. I mis-read it. I suspect you are correct. But I'll still question it -- why would the modification, rather than creation date, be used for capture default if not otherwise present?

But that's not really the issue here. The issue is that LR changes it. Photoshop modified it, but then LR changed to Create Date on accepting it back from Photoshop. It should not have changed.

2) That's entirely expected that you have to save metadata in order to commit a capture date/time change to the file. How else could it be done?

Well, it could update it immediately.

Perhaps your question is which is right? That's a fair question; I had the impression of immediate update due to the "cannot be undone" notes. But that may not be a fair implication.

Let me experiment a bit more.

 

[Linwood Ferguson]

OK, let me try again with some more examples. The most interesting one is at the end.

I took an image not in the catalog. Here is the starting point.

c:\Junk>exiftool -a -u -g1 Baby_Book_916.tif | find /I "Time"
File Modification Date/Time : 2020:05:11 21:23:56-04:00
File Access Date/Time : 2020:05:11 21:23:56-04:00
File Creation Date/Time : 2020:05:11 21:23:53-04:00
Profile Date Time : 2006:02:02 02:20:00

I edited it in Photoshop (no LR involvement) to rotate and crop it, and saved it.

c:\Junk>exiftool -a -u -g1 Baby_Book_916.tif | find /I "Time"
File Modification Date/Time : 2020:05:12 11:05:06-04:00
File Access Date/Time : 2020:05:12 11:05:06-04:00
File Creation Date/Time : 2020:05:11 21:23:53-04:00
Profile Date Time : 1998:12:01 18:58:21

I dragged it into LR and did an ADD type import:

Lightroom shows 5/11/2020 9:23:53

That's clearly the creation date.

OK, let's do a different file. Here's my starting point:

c:\Junk>exiftool -a -u -g1 Baby_Book_917.tif | find /I "Time"
File Modification Date/Time : 2020:05:11 21:24:59-04:00
File Access Date/Time : 2020:05:11 21:24:59-04:00
File Creation Date/Time : 2020:05:11 21:24:57-04:00
Profile Date Time : 2006:02:02 02:20:00

No further change, no photoshop -- just drag and drop into LR. LR shows May 11, 2020 9:24:59. That's the modification date.

So exactly how does it decide?

Let's do one more. Here's my starting point:

c:\Junk>exiftool -a -u -g1 Baby_Book_918.tif | find /I "Time"
File Modification Date/Time : 2020:05:11 21:25:22-04:00
File Access Date/Time : 2020:05:11 21:25:22-04:00
File Creation Date/Time : 2020:05:11 21:25:19-04:00
Profile Date Time : 2006:02:02 02:20:00

Except I'll use EXIFTOOL to change it a bit:

c:\Junk>exiftool -FileModifyDate-=2 Baby_Book_918.tif
1 image files updated

c:\Junk>exiftool -FileAccessDate-=1 Baby_Book_918.tif
Warning: Sorry, FileAccessDate is not writable
Nothing to do.

c:\Junk>exiftool -FileModifyDate-=2 Baby_Book_918.tif
1 image files updated

c:\Junk>exiftool -a -u -g1 Baby_Book_918.tif | find /I "Time"
File Modification Date/Time : 2020:05:11 17:25:22-04:00
File Access Date/Time : 2020:05:11 17:25:22-04:00
File Creation Date/Time : 2020:05:11 18:25:19-04:00
Profile Date Time : 2006:02:02 02:20:00

Now I've got an hour apart, drag and drop to LR. I was hoping to have a different access time also but no luck.

So now LR shows May 11, 2020, 5:25:22 PM. Modification or access.

Edit in Photoshop. It comes back as:

c:\Junk>exiftool -a -u -g1 Baby_Book_918.tif | find /I "Time"
File Modification Date/Time : 2020:05:12 11:23:17-04:00
File Access Date/Time : 2020:05:12 11:23:17-04:00
File Creation Date/Time : 2020:05:11 18:25:19-04:00
Profile Date Time : 1999:06:03 00:00:00

But now LR now shows May 11, 6:25:19pm. It looks to me like it's making some kind of algorithmic decision based on how modification (or access) and creation date relate to each other, if they are "close" it is using modification (or access), if they are "enough" different it uses Creation.

What I was having happen is, probably because I did some editing outside of LR before import, I was having images appear to vanish from the grid after editing within LR in photoshop, because it was resorting them to a different place. It was resorting because it used modification (or access) on import, and creation after editing in photoshop.

To me that's just wrong.

Now to be fair once "fixed" by changing the actual time it appears to stick, but it seems needlessly confusing to change which it is using on the same photo.

 

[Jim Wilde]

Well, it could update it immediately.

Perhaps your question is which is right? That's a fair question; I had the impression of immediate update due to the "cannot be undone" notes. But that may not be a fair implication.

Wouldn't that be a form of destructive editing, i.e. changing the original file automatically in response to a metadata edit? Follow that line of reasoning and they can do away with the option to save XMP, and making it automatic by default. Yes, that's an exaggeration, but you should get my point....I can't think of any circumstance where Lightroom would change anything in an original file without the express permission of the user. The user currently has the option to make such changes happen (either manually or automatically), and personally I think that should be sufficient.

 

[Linwood Ferguson]

Wouldn't that be a form of destructive editing, i.e. changing the original file automatically in response to a metadata edit? Follow that line of reasoning and they can do away with the option to save XMP, and making it automatic by default. Yes, that's an exaggeration, but you should get my point....I can't think of any circumstance where Lightroom would change anything in an original file without the express permission of the user. The user currently has the option to make such changes happen (either manually or automatically), and personally I think that should be sufficient.

Honestly I agree with you, I really do. I just didn't have that impression.

I went back and found a couple of the early postings on this subject from Adobe. Here's a still current one:

Metadata basics and actions in Lightroom Classic

It is simply silent on the save metadata aspect, though it is explicit on the section on saving to raw. I concluded (wrongly it appears) That this implies it writes immediately.

I'm not sure this is the original posting but it dates to 2011. The posting by Adobe (Julieanne Kost). This is the entire posting.

There are certain times when you might want to change the capture time for an image. For example you change time zones when traveling and forget to reset the time on the camera, or maybe multiple cameras are used to photographed an event, only one camera was incorrectly set (making the Sort by Capture Time difficult as the images appear out of order due to the incorrect time stamp on that camera’s images). In order to correct the time, select the images from that camera (don’t forget you can easily filter on the metadata/serial number of the camera to quickly find all of the images), and choose Metadata > Edit Capture Time. Choose to adjust to a specific time (for example, if the time needs to be set 8 minutes forward) enter the correct time and all of the images will be shifted appropriately. If you changed time zones, then choose to Shift by a Set Number of Hours.

In addition, there is a preference that goes along with it that many photographers aren’t aware of. If you choose Catalog Settings > Metadata you can choose to Write date or time changes into proprietary raw files. This is the only occasion when Lightroom will actually write changes to the proprietary file (.nef or .crw for example).

Now to be fair, beginning about 8 months later there's a comment about saving metadata and more clarification in the comments to the blog post.

But i just think the whole context of this could have been much clearer if they explicitly said "to change the file you must save-metadata".

 

[Jim Wilde]

But i just think the whole context of this could have been much clearer if they explicitly said "to change the file you must save-metadata".

I agree completely. I got tripped up by that in the early days, as it took me a little while to figure out that, as well as setting that option to write date changes into proprietary raw files, we still then needed to write to XMP.

 

[johnrellis]

Doesn't it seem wrong that LR is using access date, not file creation (or modification even) date on import if there's no original/created in the metadata?

I just checked, and absent any metadata fields, LR uses the file date modified, not file date created or file date accessed. I recall that back in LR 3 (perhaps), it used file date created, but I and others argued in a feature request that it should use file date modified, because on Windows, various copy and backup utilities preserve file date modified when copying a file but set file date created to "now" (including File Explorer and the Copy command). On Mac too, apps often don't preserve the file date created, to the chagrin of old-time Mac users, who relied on Mac OS 9 apps preserving file date created.

I think you were getting confusing results from your experiments because you weren't examining all the relevant metadata fields. When using Exiftool, use "-a -G" (rather than -a -g1), and find/grep for "date" rather than "time". For example:

$ exiftool -a -G a.jpg | grep -i date
[File] File Modification Date/Time : 2020:05:12 15:44:25-07:00
[File] File Access Date/Time : 2020:05:12 15:44:27-07:00
[File] File Inode Change Date/Time : 2020:05:12 15:44:26-07:00
[EXIF] Modify Date : 2020:05:12 15:26:50
[EXIF] Date/Time Original : 2019:05:12 15:16:51
[XMP] Create Date : 2019:05:12 15:16:51-07:00
[XMP] Modify Date : 2020:05:12 15:26:50-07:00
[XMP] Metadata Date : 2020:05:12 15:43:02-07:00
[XMP] Date Created : 2019:05:12 15:16:51
[IPTC] Date Created : 2017:05:12
[ICC_Profile] Profile Date Time : 1999:06:03 00:00:00
[Composite] Date/Time Created : 2017:05:12 15:16:51

In particular, if EXIF/XMPateTimeOriginal is missing, I believe LR will use one of EXIF:CreateDate (what the standard calls DateTimeDigitized), EXIF:ModifyDate (what the standard calls DateTime!), and XMP:MetadataDate (I don't recall the preference order). Both LR and PS will add some of these fields when they save metadata back to a file (but they behave slightly differently).

Also, note that LR still can behave inconsistently when an imported file is missing EXIFateTimeOriginal. Adobe has never succeeded in squashing all the bugs with that (it appears that LR is a complete mess internally when it comes to dates).

Given LR's bugs and that apps, operating systems, and web services like Dropbox and Google drive don't do a good job of preserving file dates, trying to rely on file dates leads to madness. When I first import scans or other files missing capture dates into LR, I select all of them and do Edit > Capture Time / Change All, which sets LR's notion of capture date to the file date modified. That will avoid LR bugs. I also have Catalog Settings > Metadata > Automatically Write Changes Into XMP set, so the metadata stored in files automatically gets updated whenever LR changes it.

 

[Linwood Ferguson]

@johnrellis thanks, I need to redo all this again and check my exiftool; I went by the online help for the g1 which I thought said showed everything.

But fundamentally here is the issue -- the date shown for capture, when I import the image should not change after a pass through photoshop. Both Adobe products. Sometimes it does, sometimes it doesn't. That's just broken. It's not an earth-ending bug, the lights do not dim when I hit it, and so far no sparks from the CPU, but it is annoying.

 

[johnrellis]

the date shown for capture, when I import the image should not change after a pass through photoshop. Both Adobe products. Sometimes it does, sometimes it doesn't.

I understand why the behavior is surprising and undesired for you, but it's the result of a chain of polices, each of which is reasonable:

- When LR imports a photo that's missing EXIFateTimeOriginal, it defaults the catalog capture date to one of a list of other metadata fields and file date fields.

- LR tries to preserve the metadata fields (or their absence) that it finds in an imported photo, unless you change them within LR. So when you do Edit In Photoshop, it passes the photo with no metadata fields to Photoshop.

- When Photoshop saves the photo to return it to LR, it adds several date fields to the modified photo, in conformance with the standards:

o EXIF/XMP:ModifyDate (what the standard calls DateTime), which represents when an application last changed the contents of the file.

o XMP:MetadataDate , when an application last changed the photo's metadata.

o XMP:CreateDate, when the image was rendered into digital form. It think it should also write EXIF:CreateDate (which the standard calls EXIFateTimeDigitized), not sure why it doesn't, but that's no material here.

- When LR gets the new version of the photo, it reads in its metadata to get any changes that were added by the external editing application. In this case, LR will now use one of the metadata date fields added by Photoshop for the catalog capture date, which could be different from the file date modified it used for the original import.

I think the undesired behavior arises from a conflict of policies: the policy for every photo in the catalog to have an assigned capture date that has some relationship to the dates associated with the photo, and the policy for LR not modify the metadata of a photo unless the user gives an explicit command to do so. If it were up to me, I'd design LR to explicitly add EXIFateTimeOriginal when you first import a photo that's missing it, which would fix a decade of buggy behavior with such files. But I could imaging archivists using LR complaining that they don't want that field added unless they explicitly give the Edit Capture Time command. Traditionally, when there is a conflict of different use cases, an application adds an option that lets the user decide.

Regardless, it's pretty clear Adobe doesn't care about this. Their philosophy has always been that LR is targeted to media produced by digital cameras (stills and video), and they've given little care and feeding to that minority of us who use LR as a digital asset manager for scans of analog images. You could file a feature request/bug report at the official Adobe feedback forum, which I almost always encourage people to do, but in this case, I think it'd be a waste of your time:
https://feedback.photoshop.com/photoshop_family/categories/photoshop_family_photoshop_lightroom

 

[Linwood Ferguson]

o EXIF/XMP:ModifyDate (what the standard calls DateTime), which represents when an application last changed the contents of the file.

o XMP:MetadataDate , when an application last changed the photo's metadata.

o XMP:CreateDate, when the image was rendered into digital form. It think it should also write EXIF:CreateDate (which the standard calls EXIFateTimeDigitized), not sure why it doesn't, but that's no material here.

You are correct (ok, you know that, but in case anyone else wondered), I tried again with the better exiftool command.

Before (fresh from scanner)

c:\Junk>exiftool -a -G early_ben_011.tif | find /I "date"
[File] File Modification Date/Time : 2020:05:13 21:43:07-04:00
[File] File Access Date/Time : 2020:05:13 21:43:07-04:00
[File] File Creation Date/Time : 2020:05:13 21:28:44-04:00
[XMP] Metadata Date : 2020:05:13 21:43:07-04:00
[ICC_Profile] Profile Date Time : 2006:02:02 02:20:00

Lightroom shows: 5/13/2020 9:43:07pm

After Photoshop saves it:

c:\Junk>exiftool -a -G early_ben_011.tif | find /I "date"
[File] File Modification Date/Time : 2020:05:13 21:45:28-04:00
[File] File Access Date/Time : 2020:05:13 21:45:28-04:00
[File] File Creation Date/Time : 2020:05:13 21:28:44-04:00
[EXIF] Modify Date : 2020:05:13 21:45:28
[XMP] Metadata Date : 2020:05:13 21:45:28-04:00
[XMP] Create Date : 2020:05:13 21:28:44-04:00
[XMP] Modify Date : 2020:05:13 21:45:28-04:00
[ICC_Profile] Profile Date Time : 1998:12:01 18:58:21

Lightroom shows: 5/13/2020 9:28:44pm

It's coming clearly from the XMP segment for Create Date.

Where I disagree with your conclusion that it is policies "each of which is reasonable" is that I do not see what Photoshop is not making the same conclusion as Lightroom. They both should operate on the same policy (since both are reading the same unchanged file at that point). It is not reasonable that they are different. But I certainly agree with this:

Regardless, it's pretty clear Adobe doesn't care about this.

There's SO many things about LR Classic they don't care about, this must be so far down the list as to long ago fallen on the floor and rolled down the steps into the basement.