Skip to main content
P
PhotoGAP
Participating Frequently
August 31, 2011

P: 3.5RC DateTimeDigitized Loss

  • August 31, 2011
  • 12 replies
  • 562 views

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)

    This topic has been closed for replies.

    12 replies

    Show previous replies
    S
    S_Beller
    Known Participant
    September 7, 2011
    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.
    P
    PhotoGAPAuthor
    Participating Frequently
    August 31, 2011
    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).
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices