P: "Data/Time digital" not shown correctly in Lr 3.4

Gary

I have been having similar confusion, and reading your post makes me even more confused.

Before I comment further, can you tell me what you mean by the "[XMP] Date/Time Digitized" value? I can find no reference to this field in the IPTC documentation. I see that this is a flag in exiftool, but I don't find documentation for it in the IPTC values.

My understanding is that there is a metadata value called "Create Date" (xmp:CreateDate) that is used for the Date/Time Digitized in IPTC Core 1.0

In my workflow, I have been setting "Date/Time Original" (exif:DateTimeOriginal) to store the time of the image creation, and "Create Date" (xmp:CreateDate -- which is displayed as "Date Time Digitized" in Lightroom!) as the time of scanning.

So far, unless I time-shift the values in Lightroom, I have had these values retained using LR 3.4.1 and LR 3.5RC.

Note that "Create Date" (xmp:CreateDate) and "Date Created" (photoshop:DateCreated) are completely different fields with completely different meanings. Issues of redundancy and contradiction between Date/Time Original and Date Created are discussed at http://feedback.photoshop.com/photosh...

A

Thanks for the feedback.
However, the problem which I originally described is still there in Lr 3.5. Unfortunetely it is *not* solved:
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.
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.

I've done so, and rewrote it for a specific request of 3.5RC. Thanks!

You might consider reposting this as a new topic, including the word "3.5RC" in the title, since this topic is already marked as "solved". (An Adobe employee asked that each problem gets its own topic.)

John - Perhaps some aspect of this problem was fixed by 3.5RC (as related to editing capture time with LR), but there seems to be a bigger issue with my catalog, and perhaps others as well.

Like many, I set the Exif:DateTimeOriginal and XMP:DateTimeDigitized with my scans prior to import in LR (via Exiftool). I've done this for a number of years, and have cataloged thousands of images with LR versions 1.0 through 3.3. These are the only two dates in the files at the time of import into LR.

Unfortunately, in reviewing some of my scans from LR3.3, I see that XMP:CreateDate has already been mapped to Exif:DateTimeOriginal by LR3.3 (at least some older versions of LR appear to have done the same thing). The mapping completely ignored the correct XMP:DateTimeDigitized value. Right or wrong, this mapping is in conflict with the current guidance from the MWG. Hence, my testing with 3.5RC, the digitized dates for my scans now reflect DateTimeOriginal.

Finally, as already noted by others, if metadata is saved (auto write or ctrl-s) by 3.5RC, the original XMP:DateTimeDigitized data is completely lost from the original image file. Further, if the image is exported, the new export contains a new tag IPTC:DigitalCreationDate, that has been mapped to CreateDate (which by now incorrectly reflects DateTimeOriginal).

So, somehow, the "system" of software+standards has broken down such that an original digitized date has now been changed to a new digitized date, as reflected by the 3.5RC export.

I know this is a very long post, but hopefully it will be of some help to others. Now, I will need to revert back to LR3.3, and figure out how to proceed in correcting the CreateDate for my thousands of scans.

Here is an example of the tags from my scans workflow:

1. Original scans are tagged as follows:
[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 Create Date has been mapped to 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 (symptom originally reported in this thread). Saving the metadata to the file yields the following (ctrl-s). As we see, 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

The release notes say this is fixed in 3.5RC:

http://blogs.adobe.com/lightroomjournal/

I agree with John.
It scared me when I realized that all of a sudden (when updating from Lr 3.3 to 3.4) all of my scans don't show the correct "date/time digitized" any more but only the same date/time in all the 3 date/time metadata fields.
I've reinstalled Lr 3.3 in order to work with access to the correct date/time and without loosing data, and I surely hope this to be fixed in the next update of Lr.

> Changing both the DateTimeDigitized and DateTimeCreated is the right thing to do for a digital still capture. With a digital camera, the image is of course digitized at exactly the same time it's created.

Agreed, that makes sense for digital camera stills (LR's main focus).

But this was an undocumented change from LR 3.3 and earlier, so for those of us with scans, it can cause Date Time Digitized to be overwritten and lost.

I'd prefer the old behavior for Edit Capture Time: For digital camera stills, Date Time Original is what people care about, and they don't pay attention to Date Time Digitized or care that when they need to change Date Time Original because their camera clock was set wrong, Date Time Digitized isn't getting changed also. But for scan-based workflows, Date Time Digitized can be very important, and changing it when you change capture time loses data.

Changing both the DateTimeDigitized and DateTimeCreated is the right thing to do for a digital still capture. With a digital camera, the image is of course digitized at exactly the same time it's created. Adding better support to Lightroom for files that are scans from film, or digital photos of other original artwork, seems like a reasonable feature request.

Thanks Ben