P: 3.5RC DateTimeDigitized Loss

[PhotoGAP]

Considering scanned images, with existing, but different, values for DateTimeOriginal and DateTimeDigitized...

A. In LR version 3.3 (& possible prior versions): XMP:CreateDate appears to have been mapped to an existing value for DateTimeOriginal. I believe it should have been mapped to the existing DateTimeDigitized, as noted by the MWG. This issue may be one cause for the incorrect digitized dates noted by users of 3.4 & 3.5RC.

B. In LR version 3.5RC: Recommend retaining the XMP:DateTimeDigitized tag. Currently, this tag is deleted by 3.5RC (and perhaps 3.4), which prevents corrective action due to the problem noted above for LR3.3 (i.e. autosave metadata or ctrl-s deletes the date digitized information from original file). Per the MWG, 3.5RC is using the CreateDate as the digitized date, but that value is no longer correct as created by LR3.3.

Due to the possible loss of the DateTimeDigitized data by 3.5RC, I'll need to revert back to LR3.3. Though the CreateDate appears to be incorrect with LR3.3, at least the original digitized data is retained, and I can evaluate my options from there.

Below is an example flow of data from one of my scanned images...

1. Original scans are tagged as follows (with Exiftool):
[EXIF] Date/Time Original : 1985:04:17 12:00:00
[XMP] Date/Time Digitized : 2011:06:27 20:43:15-05:00

2. Scans were imported into LR3.3. Saved metadata now shows the first hints of a problem, as CreateDate has been mapped to DateTimeOriginal (DTO) by LR3.3.
[EXIF] Date/Time Original : 1985:04:17 12:00:00
[XMP] Date/Time Digitized : 2011:06:27 20:43:15-05:00
[XMP] Modify Date : 1985:04:17 12:00:00-05:00
[XMP] Create Date : 1985:04:17 12:00:00-05:00

3. Scans were then imported into 3.5RC, and the digitized date now incorrectly reflects the DTO date in the metadata panel (symptoms reported in other threads). Saving the metadata to the file yields the following (ctrl-s). **The initial digitized date has been completely lost.**
[EXIF] Modify Date : 1985:04:17 12:00:00
[EXIF] Date/Time Original : 1985:04:17 12:00:00
[XMP] Create Date : 1985:04:17 12:00:00-05:00
[XMP] Metadata Date : 2011:08:30 11:10:26-05:00
[IPTC] Date Created : 1985:04:17
[IPTC] Time Created : 12:00:00-05:00

4. Finally, if we export the image from 3.5RC, we have the following in the new image. We note the creation of the new IPTC digitized tag, which, of course, no longer reflects the original digitized tag.
[EXIF] Modify Date : 2011:08:30 11:28:20
[EXIF] Date/Time Original : 1985:04:17 12:00:00
[EXIF] Create Date : 1985:04:17 12:00:00
[XMP] Metadata Date : 2011:08:30 11:28:20-05:00
[IPTC] Date Created : 1985:04:17
[IPTC] Time Created : 12:00:00-05:00
[IPTC] Digital Creation Date : 1985:04:17
[IPTC] Digital Creation Time : 12:00:00-05:00

(Win 7, x64)

[PhotoGAP]

Also, I'll note that fresh scans imported directly into 3.5RC appear to work correctly, as the new CreateDate tag is mapped from the existing DateTimeDigitized tag. The problem arises from legacy CreateDate tags generated from LR3.3 (and maybe prior).

[S_Beller]

I've got the same problem and as the original post has been marked as *solved* even though it isn't I post it here again:
I import a TIF file into Lr where the EXIF information containes only the date/time digitized. If I change the date/time with the menu command within Lr,
all three dates in Lr metadata (preset "EXIF") are set to the same (entered) date/time even though before the change a different date/time (namely the date/time digitized) was shown. So the date/time digitized is lost after the change which is an unwanted side effect.
When I write the metadata to the TIF file, and view it externally with Exifer, the data/time digitized and the capture time are set to the new date/time entered in Lr.
What I would expect is that the date/time digitized stays the same, and only the capture date changes (as the menu command label in Lr says).
Please, do change this behavior to what it was in Lr 3.3 as it was working correctly then.

[johnrellis]

The release notes say, "After editing the capture time in Lightroom, “Date Time Digitized” was incorrectly changed. (Only “Date Time Original” should be modified)".

This doesn't appear to have been fixed. Metadata > Edit Capture Time always sets Date Time Digitized to the value set by Edit Capture Time.

Also, a subsequent Save Metadata To File writes an incorrect value for XMP:DateCreated.

Steps to reproduce.

1. Import this JPEG, which has the following metadata date fields:







2. Do Edit Capture Time to change to 1/1/1990 12:00:00, and observe that Date Time Digitized has changed:



3. Do Save Metadata to File and observe that XMP:DateCreated is not the same as EXIF:DateTimeOriginal:

[Benjamin Warde]

Whoops. Yeah, this fix was supposed to be in 3.5 release candidate, but it looks like it didn't actually make it. We do hope to have the fix in the final release version of 3.5.

Thanks,
Ben

[PhotoGAP]

Benjamin, thanks for acknowledging this. It appears that the engineers have two different example workflows in this thread to examine, and hopefully find a fix for. Let us know if any of our descriptions need clarification. Thanks!

[Benjamin Warde]

The final release of Lightroom 3.5 is now available for download (go to Help>Check for Updates within Lightroom, if it doesn't prompt you automatically). In 3.5, this issue is fixed-ish. Editing the capture date/time will no longer change the date/time digitized in the Lightroom UI. When actually writing the info out to the metadata in the file, we're still not quite writing to all the correct (according to the MWG spec) metadata fields. That fix is still pending.

Thanks,
Ben

[S_Beller]

Thanks Ben, it works fine now.
In my case,
(1) changing the capture date/time from within Lr affects the correct metadata field.
(2) writing metadata from Lr results in the correct values both for date/time digitized and capture date/time in the file
(3) re-importing the metadata into Lr also works fine.

[PhotoGAP]

Ben - can you elaborate on exactly what metadata fields that LR isn't correctly writing to yet? The release notes don't mention it as a "known issue" and I'd like to know if it will impact my workflow and if I need a work-around.

Many thanks for your help!

[alanterra]

Yes, please do post a complete description of the issue. I have worked hard to get my metadata correct, and I live in fear that some program will corrupt them. Recognizing and correcting for such problems is a real PITA.

[Benjamin Warde]

Here's my best understanding of how the fields are supposed to be written, and what is and isn't working. When editing the capture date/time in Lightroom, and then saving to the metadata, here are the results:

exif tag #306 DateTime. This field should not be modified by the edit capture time operation. Sometimes it is, sometimes it isn't.
exif tag #36867 is updated to the new time - this is correct.
exif tag #36868 is not updated, it still has the old time - this is correct

IPTC tags 2:55 (Date Created) and 2:60 (Time Created) have been added. They have the old, unmodified date/time. This is not correct. They should match the new values in exif tag #36867.

The following XMP tags have also been added:
xmp:ModifyDate has the new time/date. This is not correct. According to the MWG spec, "The date/time modified value will be changed by software and operating systems on subsequent edits of the file." That doesn't make it sound like it should be updated to the edited time. It makes sound like, if anything, it should reflect the time and date at which you most recently edited the file (i.e., now).
xmp:CreateDate has the old time. This is correct.
xmp:MetadataDate is set to now (i.e., the behavior that I would have expected for xmp:ModifyDate). I believe this is correct, but the MWG spec doesn't seem to say.
photoshop:DateCreated has the old time. This is not correct. It should match the new values in exif tag #36867.

Thanks,
Ben

[alanterra]

Benjamin

The last issue you mentioned ("photoshop:DateCreated has the old time. This is not correct.") has caused problems for me.

I use PhotoLinker 2 to georeference my photos, and what I have found is that when xmp:DateTimeDigitized and photoshop:DateCreated are not consistent, it uses the latter in favor of the former.

If I use LR or exiftool to time shift images (due to, for instance, setting the clock wrong on my camera), then (I believe still with LR 3.5), xmp:DateTimeDigitized is shifted, but photoshop:DateCreated is not.

What I have been doing is after time shifting, I delete photoshop:DateCreated using exiftool, and then when the file is next seen by Lightroom, the field is recreated, taking its value from some other field (I don't know which), and making all the fields consistent.

Do you see any problems with this work flow?

Thanks

A

PS--I have corresponded with the author of PhotoLinker 2, and they have agreed to have it favor xmp:DateTimeDigitized over photoshop:DateCreated when the two differ, but that fix hasn't been rolled out yet.

[J453]

According to the internal bug system, this was fixed in Lightroom 3.6 and later.