Lightroom: 3.4 confuses XMP DateCreated, CreateDate, and ModifyDate

  • 4
  • Problem
  • Updated 7 years ago
  • (Edited)
LR 3.4’s handling of metadata dates has several problems implementing section 5.3 of "Guidelines for Handling Image Metadata":

1. It doesn't read Capture Time from XMP:DateCreated.

2. The Metadata > Edit Capture Time command incorrectly changes Metadata Panel > EXIF > Date Time Digitized to the new capture time. It fails to change Metadata Panel > IPTC > Date Created.

3. The Metadata > Save Metadata To File command incorrectly stores the capture time into XMP:CreateDate, instead of XMP:DateCreated and IPTC:DateCreated.

4. The Metadata > Save Metadata To File command does not update the XMP:ModifyDate to the current date and time, as described in section 5.3 and appendix B.

See also these topics:

http://feedback.photoshop.com/photosh...
http://feedback.photoshop.com/photosh...

To reproduce:

1. Make a new catalog.

2. Import the file p.jpg (attached below). It has the following metadata dates:

[XMP] XMPToolkit : Image::ExifTool 8.25
[XMP] DateCreated : 1960:01:01 01:01:01
[XMP] CreateDate : 1970:01:01 01:01:01
[XMP] MetadataDate : 2011:05:14 08:39:04.81+07:00
[XMP] ModifyDate : 1980:01:01 01:01:01
[XMP] RawFileName : p.jpg

There are no EXIF or IPTC sections in the metadata.

3. LR shows the following in the Metadata panel:

Default > Capture Time: (nothing, incorrect)
EXIF > Date Time Digitized: 1/1/1970 1:01:01 AM
EXIF > Date Time: 1/1/1970 1:01:01 AM
IPTC > Date Created: 1960-01-01

4. Use Metadata > Edit Capture Time to change capture time to 1/1/1950.

5. The Metadata pane now shows

Default > Capture Time: 1/1/1950 1:01:01 AM
EXIF > Date Time Original: 1/1/1950 1:01:01 AM (incorrect)
EXIF > Date Time Digitized: 1/1/1950 1:01:01 AM (incorrect)

6. Do Metadata > Save Metadata To File. Exiftool shows these values in the file's metadata:

[XMP] DateCreated : 1960:01:01 01:01:01 (incorrect, should be 1950)
[XMP] CreateDate : 1950:01:01 01:01:01 (incorrect, should be 1970)
[XMP] ModifyDate : 1950:01:01 01:01:01 (incorrect, should be current time)
[EXIF] ModifyDate : 1950:01:01 01:01:01 (incorrect, should be current time)
[IPTC] DateCreated : 1960:01:01 (incorrect, should be 1950)

Configuration: LR 3.4, Windows 7 Professional 64-bit

Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes

Posted 7 years ago

  • 4
Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes
Note that this problem could permanently corrupt Date Time Digitized in both the catalog and the image metadata, if the user does Save Metadata To File for all of her images.
Photo of TK

TK

  • 531 Posts
  • 109 Reply Likes
Scary! Under which circumstances do you think can LR permanently delete date related data? Would I have to change date information or is it sufficient to simply import DNG files and write metadata back to them?

Great detective work!
Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes
I'm pretty sure that if you do Edit Capture Time in LR followed by Save Metadata To File, you'll lose Date Time Digitized both in the catalog and in the file. I don't know if there are other circumstances.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes
Step 5 from above should read:

5. The Metadata pane now shows

Default > Capture Time: 1/1/1950 1:01:01 AM
EXIF > Date Time Original: 1/1/1950 1:01:01 AM
EXIF > Date Time Digitized: 1/1/1950 1:01:01 AM (incorrect)
Photo of David Franzen

David Franzen, Employee

  • 96 Posts
  • 17 Reply Likes
When I tried to download the picture of the cat cat in the tree, I got a file with no XMP in it at all. Can you provide a URL to download the p.jpg file you said had dates in the XMP only?
Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes
Hmm, when I right-click Save Target As in IE 9, I get a file p.orig.jpg with the following metadata:

C:\Users\Ellis\Desktop>exiftool -a -G -s p.orig.jpg
[ExifTool] ExifToolVersion : 8.25
[File] FileName : p.orig.jpg
[File] Directory : .
[File] FileSize : 988 kB
[File] FileModifyDate : 2011:05:15 08:18:27-07:00
[File] FilePermissions : rw-rw-rw-
[File] FileType : JPEG
[File] MIMEType : image/jpeg
[File] ImageWidth : 2560
[File] ImageHeight : 1920
[File] EncodingProcess : Baseline DCT, Huffman coding
[File] BitsPerSample : 8
[File] ColorComponents : 3
[File] YCbCrSubSampling : YCbCr4:2:2 (2 1)
[XMP] XMPToolkit : Image::ExifTool 8.25
[XMP] DateCreated : 1960:01:01 01:01:01
[XMP] CreateDate : 1970:01:01 01:01:01
[XMP] MetadataDate : 2011:05:14 08:39:04.81+07:00
[XMP] ModifyDate : 1980:01:01 01:01:01
[XMP] RawFileName : p.jpg
[Photoshop] IPTCDigest : 7b3df7ff0f0f851e1203088015f4c0
ae
[Composite] ImageSize : 2560x1920

But if that still doesn't work, try downloading from this URL:

http://dl.dropbox.com/u/21811200/p.or...
Photo of David Franzen

David Franzen

  • 1 Post
  • 0 Reply Likes
Thanks. I accidentally used "Save Image As..." in OS X's Safari and not the "Download Linked File As..." command. That was either my mistake, a bug in Safari, or both.
Photo of David Franzen

David Franzen, Employee

  • 96 Posts
  • 17 Reply Likes
There are several issues here, and I will try to address them one-by-one in separate replies.

> 1. It doesn't read Capture Time from XMP:DateCreated.

This is actually as-designed to prevent data-loss when the XMP photoshop:DateCreated property and the Exif DateTimeOrignal property both exist in a file and have different values.

Historically Photoshop Family products have treated these two properties--for brevity I'll call them the IPTC and Exif creation dates--as separate properties, not mapped together. Also, for a long time the IPTC property was supported as a date-only property and not a date-time. It's possible--and I think likely--that customers with files produced or edited by older version of the Photoshop Family products have files where the IPTC and Exif dates are different. At the very least, our software made it really, really easy to create files where the IPTC and Exif times did not match. There was even a bug in Photoshop CS4 (fixed in CS5) where the File Info dialog would allow you to enter a date and a time for the IPTC Date Created, but only the date portion was written into the file's XMP photoshop:DateCreated tag and the mapped legacy IPTC IIM tags.

Following the strict MWG guidance requires software favor the value found in the IPTC property over what's in the Exif in some cases. If the IPTC date created was your source of the canonical "capture time" for the image, then when updating the original file or creating a new, derived file, you must overwite whatever date-time was in the Exif DateTimeOrignal with the value you read from the IPTC. To avoid data-loss in that case, we do not favor what's in the IPTC date created over Exif when reading files, so, as you observe, we don't pick up "Capture Time" from that XMP tag.

One can argue that this approach is too blunt, and that a more nuanced (complicated) mapping would be better. Your sample file is a great example of this. Since there is no IPTC or Exif in the file at all, only XMP, there is no chance of data-loss when following the MWG mapping guidance for that file.

But I think JPEGs with XMP only, like your sample, are rare. Almost all JPEG files form almost all digital cameras will actually have Exif only and no XMP or IPTC IIM metadata at all. Is this a kind of file you actually use in real-world workflows? If you are creating some custom workflow around ExifTool and need to set the "Capture Time," set it in the canonical Exif DateTimeOriginal and not just in the XMP before importing the JPEG into Lightroom.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3450 Posts
  • 876 Reply Likes
> It doesn't read Capture Time from XMP:DateCreated:

Thanks very much for the explanation of what LR is doing, quite helpful. To test my understanding, LR doesn't strictly conform with the MWG guidance in this case for two practical reasons: The mapping implementation would be more complicated, and legacy metadata may be lost.

Your recommendation to have external tools set both EXIF:DateTimeOriginal and XMP:DateCreated would work just fine for me.

For background: Much of my workflow involves scanning and curating large numbers of scans of old slides from a Nikon scanner. It produces TIFFs, many of which I edit directly in LR and some of which I edit in Photoshop Elements. I usually know the approximate date but not the time of the slides from a given roll. Using a script or a plugin based on Exiftool, I then set the capture time of the roll to be a given date, with times increasing by 1 second; this allows me to quickly sort the slides and merge with other sets of slides while maintaining the relative order in which the slides were taken, both within LR and within other tools like Windows Explorer. (LR doesn't provide a built-in command to batch-set capture time, either to a single time or to a sequence of times.)

I've got a lot of older scans that use both XMP and EXIF fields for dates/times, and bugs in Photoshop Elements Organizer (which I used previously) created inconsistencies between XMP and EXIF. I've mostly eliminated these inconsistencies, but I'm still sensitive as to the mapping and I'm glad the MWG is working to improve the situation.
Photo of David Franzen

David Franzen, Employee

  • 96 Posts
  • 17 Reply Likes
"LR doesn't strictly conform with the MWG guidance in this case for two practical reasons: The mapping implementation would be more complicated, and legacy metadata may be lost."

I would not put it that way exactly. Preventing the legacy data loss case is the driving reason why. The MWG guidance on reconcilling conflicts between different forms of metadata in a file is pretty straight forward, and the goal is not to simplify logic relative to the MWG guidance. What is uncomplicated about the current implementation is that--and I'm kind of reaching for a metaphor here--is that it simply "breaks" one of the rules instead of trying to "bend" the rules; we don't import photoshop:DateCreated into Exif DateTimeOrignal, as opposed to trying to do it sometimes and not others.

Thanks for explaining more about your scanning workflow.