I recently noted that in Lr 3.4 the metadata field "Date/time digital" does not show the correct date any more. It always shows the date/time of the other two date/time fields. I've tested my catalog again with Lr 3.3 and there it shows correctly. This seems to be bug introduced in Lr 3.4.
I think you're right to be confused. What I suspect is happening is that Gary is setting some fields, and leaving others blank, that make his files look different than LR is prepared to handle. It does its best to map the input to MWG guidance, but because the input is incomplete it's not working as expected.
Gary, I would suggest you read over sections 4.2 and 5.3 of the Metadata Working Group Guidance (http://www.metadataworkinggroup.org/i...) and be sure to set your files appropriately.
Specifically, by my read, you should set EXIF DateTimeDigitized to the time of the scan and EXIF DateTimeOriginal to the time that the photo was originally taken. Leave the corresponding IPTC and XMP fields empty, and let LR populate those upon import.
Alan, I have been using Exiftool to set the tag names DateTimeOriginal and DateTimeDigitized in my scans, prior to importing them into LR. I guess the question is, where has Exiftool been placing that data.
My understanding is that DateTimeDigitized is from the original exif spec (last updated in 2002), and that Adobe's XMP spec was designed to incorporate that exif data. So... my assumption (perhaps wrong) has been that Exiftool has been placing the DateTimeDigitized data into the appropriate XMP block for the old exif data. Hence, the "XMP:DateTimeDigitized" notation when listed by Exiftool.
On the other hand, Exiftool appears to associate the nametag "CreateDate" with the original exif block, and places any "CreateDate" data you define into the exif:DateTimeDigitized. This is noted on Phil Harvey's Exif Tag Name page.
So, that brings us to LR3.5RC. 3.5RC appears to be properly mapping the exif:DateTimeDigitized (called CreateDate by exiftool) to the xmp:CreateDate, and properly associating that with the digitized date of the scan. All is good there, and your collecion would appear to be ok. For me, however, 3.5RC does not appear to be picking the DateTimeDigitized from whatever block that Exiftool placed it. In doing so, 3.5RC then simply maps the CreateDate to the DateTimeOriginal (which is normally correct for a digital camera). The worse part, however, is that if I save the metadata to the file with 3.5RC, then the DateTimeDigitized information entered by Exiftool is completely wiped away from the original scan file.
Mark - I had composed the above prior to your latest reply, and appear to have reached the same conclusion as you have. In fact, I already used exiftool the other day to map the DateTimeDigitized tag to CreateDate in my scan collection. So I'm up and running with 3.5RC, but have disabled autowrite metadata and will be very cautious to not write anything out to my files until we understand more about why the xmp:DateTimeDigitized is being lost completely. After all, it certainly made sense to use that name tag in Exiftool, didn't it? I suspect others may be in the same boat and would hate to see them loose their data before they have a chance to map it to CreateDate. Finally, if exiftool is placing the DateTimeDigitized data in a proper place in the xmp block, I would hope that Adobe can look at picking that up and mapping it to the proper place as defined by the MWG.
The trick with exiftool is to know that its tag names do not necessarily match those of the relevant specifications, and to be explicit when telling it where to put things.
exiftool uses "CreateDate" to represent what the EXIF specification calls DateTimeDigitized. This is horribly confusing, as the XMP specification has something called CreateDate in the xmp schema.
By default, exiftool treats CreateDate as EXIF DateTimeDigitized, so you can use "exiftool -CreateDate=YYYY:MM:DD... -DateTimeOriginal=YYYY:MM:DD... scan.tiff" and it'll write into the correct fields. Use exiftool -a -G -s to confirm that you've written it to the write places.
Thanks Mark, I had forgotten about the extra listing options with exiftool, namely -G:0:1. Using that pretty much confirms my suspicions stated above. I'll work on this a bit more this weekend, and will probably post further observations in the most current thread on this subject (as this one was already marked 'solved'). I believe some of my problems also stem from LR3.3. In any case, it appears Alan is in good shape with his collection.
I am still a novice at all of this. What I do with exiftool is to set the values using -flag=value (which sometimes takes some work to figure out), and then read the values using the -X option, which shows how exiftool maps the value. I am sure that there is an easier way to do this. I have never found a complete list of all the flags that exiftool recognizes (though I have not looked at the code).
FWIW, I note that the "-allDates" flag shows only CreateDate and DateTimeOriginal, and these seem to map directly to the values shown in Lightroom. I suggest that Gary use these for his initial scans.
Mark's comment that "this is horribly confusing" is one of the great understatements of the year. I have a crib sheet mapping exiftool name, my name, internal name, Lightroom Name, and Camera Raw name.
Don't get me started on the difference between "-subject", "-keywords" and "-keyword". That took me a long time too (not that I have more than an operational understanding).
Actually, we don't want to use -alldates for scanned images. We want to set CreateDate (aka DateTimeDigitized) to a value that is different than DateTimeOriginal. The -alldates option might be handy to reset everything for an image from a digital camera, however.
I've tested LR 3.4 and 3.5RC handling of dates, and I've found that LR 3.4 and LR 3.5RC conform with the Metadata Working Group guidance, with a couple of exceptions:
- The Edit Capture Time command overwrites Date Time Digitized in the Metadata panel and in the file metadata with Date Time Original, and it leaves an incorrect value in XMP:DateCreated.
- It writes Date Time Original into EXIF:DateTime and XMP:ModifyDate rather than the current local time.
In particular, here's how LR 3.5RC reads and writes the Date Time Original and Date Time Digitized values shown in the right-hand-side Metadata panel:
- Date Time Original is read from: XMP:DateTimeOriginal, EXIF:DateTimeOriginal. If both fields are present but have different values, priority is given in that order. IPTC:DateCreated/TimeCreated is not used for the Metadata panel's Date Time Original.
- Date Time Original is written to: EXIF:DateTimeOriginal, EXIF:DateTime (called ModifyDate by Exiftool), XMP:DateCreated, XMP:ModifyDate (non-conforming with the standards), IPTC:DateCreated/TimeCreated.
- Date Time Digitized is read from: XMP:CreateDate, XMP:DateTimeDigitized, EXIF:DateTimeDigitized (called CreateDate by Exiftool). If two or more of the fields are present but have different values, priority is given in that order.
- Date Time Digitized is written to: EXIF:DateTimeDigitized (called CreateDate by Exiftool), XMP:CreateDate. On export, it is also written to IPTC:DigitalCreationDate/Time.
I believe LR 3.4 behaves the same, but since I tested it a while ago I can't say 100%.
In step 2 of your original post, you observed that LR 3.3 would set XMP:CreateDate to Date Time Original (as seen in the Metadata panel), rather than Date Time Digitized, resulting in:
getting written back to the file. These two fields are supposed to have the same value, but when they don't, LR 3.4 and 3.5RC give priority to XMP:CreateDate. So if you import those files back into LR, they'll get the wrong Date Time Digitized.
You might consider using Exiftool to find all such files and deleting XMP:CreateDate.
...and the reason I'm so anal about dates/times is that I curate a large catalog of old photos. I've found through bitter experience that almost every tool handles them differently,including Adobe products. The differences are often just simply lack of conformance to any standard but sometimes conformance to a different out-of-date industry standard than the one that previously modified my file.
Regarding the LR3.3 problem, you note "So if you import those files back into LR, they'll get the wrong Date Time Digitized." Actually, all I have to do is open the LR3.3 catalog with 3.5RC, with the images already imported, and incorrect dates are shown in the metadata panel. Then, if we save the metadata back out, with 3.5RC, the [xmp-exif] DateTimeDigitize tag is deleted from the file, and that data appears to be lost. Does your testing confirm that? That may be a real problem for anyone who has autowrite metadata set, and open their earlier catalogs in 3.5RC (same may be true for 3.4).
For myself, I have already run exiftool with DateTimeDigitized>CreateDate, and now 3.5RC appears to be working correctly.
I haven't tested what happens with catalog migration from 3.3 to 3.5. In your 3.3 catalog, do the images show correct dates in Metadata Panel > Date Time Digitized? if they're correct in 3.3 and incorrect in 3.5RC when opening the very same catalog, that's one sort of issue. But if they're incorrect in 3.3's panel as well, then that suggests another set of issues.
John - Yes, in 3.3, the images showed the correct Metadata Panel > Date Time Digitized, but Exiftool showed that CreateDate had been set equal to DateTimeOriginal. So LR3.3 Metadata Panel was correctly showing the DateTimeDigitized that I had set, while internally mapping CreateDate to DateTimeOriginal.
Then, opening the same catalog with 3.5RC (I skipped 3.4), the Metadata Panel > Date Time Digitized value now reflects the incorrect CreateDate that had been created by LR3.3. Further, saving metadata out to the file from 3.5RC will wipe the [XMP-exif]:DateTimeDigitized data from the image, as far as I can tell, for the particular workflow sequence I've described.
This is all listed out above and in the new report I started at your suggestion. If you should feel that my report of the issue is too convoluted, feel free add any comments that may be necessary to help Adobe understand. No hurt feelings here!
This is exactly why it's important to cite exactly which fields you mean!
The XMP-exif copy of the EXIF data has been deprecated as of MWG Guidance 2.0, which was first implemented in LR in version 3.4. So it's no surprise that it gets wiped; in fact it is expected and correct.
Well, wiping XMP-exif may be the technically correct thing to do, but I've lined out a sequence of events where folks can lose data because of it. If LR3.3 didn't map XMP-exif DateTimeDigitized into XMP-xmp CreateDate, for whatever the reason, then a lot can be lost through the upgrade to LR3.4 & MWG 2.0.
43
Replies
AdChoices