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 assume you're referring to Date/Time Digitized in the Metadataq panel? Can you include a sample image that illustrates this, along with what you see in the Metadata panel in 3.3 and 3.4? LR 3.4 has changed its handling of metadata in some ways to conform with a newer standard, and I'm wondering if you're seeing the effects of this. Posting a sample image will help clarify that.
If both XMP (xmp:CreateDate) and Exif DateTimeOriginal are missing, but Exif DateTimeDigitized (36868, 0x9004) exists, Exif DateTimeDigitized SHOULD be used to create an initial XMP (xmp:CreateDate). This is also true in the case that only IPTC DateCreated is available.
That's the only scenario I see where the behavior might have changed. But as John says, seeing the original file (so the metadata can be inspected) would be really helpful.
Yes, I refer to the Date/Time Digitized in the Metadata panel (sorry for the incorrect translation - I'm using Lr in German :-). This happens with my slide scans. What I've done is I changed the capture date/time using Lr's "Edit capture time" (or similar) command in the Metadata menu to change the date to the original capture date and the time to 00:00:00 (because I don't know it).
See below how the dates are shown using the identical catalog in both Lr 3.3 and 3.4.
("Ursp. Dat./Uhrz." means "Original Date/Time"). In Lr 3.4 the digitized data does not appear correctly.
Image is not available
I will post the corresponding TIF image tomorrow as I don't have it at hand just know.
Hope that helps.
I just reviewed my catalog of scanned images. Looking at images that were imported and had their capture date/time changed using LR 3.3, some have the metadata field XMP:CreateDate set to the scan date (correct), and some have it set to the same value as XMP:DateTimeOriginal (the capture time, which is incorrect). LR 3.4 is displaying the value of XMP:CreateDate in the "Date Time Digitized" field of the Metadata panel.
I can tell from the metadata that there was a different workflow involved for the two sets of images, but I'm not sure as to the details. There's pretty clearly a bug somewhere.
As soon as you post a problem image, we might learn more about what's happening in your catalog.
Hi, since the TIF test file is about 25 MB and I did not want to change it in any way in order to keep it as it was imported in Lr, I've uploaded it on a web-drive:
Here is the access (which I keep live for a week):
http://www.mydrive.ch/login
user: test@bonnies
password: testlr3
Hope that helps - and I hope that I will get back my information as it used to be in Lr3.3.
Thanks
Sven
Yes, Mark, what I've done is I changed the capture date/time using Lr's "Edit capture time" (or similar) command in the Metadata menu to change the date to the original capture date and the time to 00:00:00 (because I don't know it).
Maybe I should add that I did not export the changed metadata from Lr to the TIF file - hence the TIF file is still the original one.
I don't think they're necessarily related. I just happened to notice the XMP:MetadataDate time zone issue when I was looking at metadata for this topic, and I remembered that others had noticed the same thing, so I wanted to get it recorded. But I don't see offhand any relationship between the two topics.
Thanks for the explanation. This appears to be a bug to me -- when you change the capture time to a specified date and time, it changes every date it's got. It probably shouldn't change DateTimeDigitized.
MWG guidance allows for separate concepts of "Original Date" and "Digitized Date". It does not suggest that they be mapped together, but that appears to be what LR3.4 is doing. I think this is a bug in the new metadata model.
Changing the date in Lightroom should only affect the "Original Date", not the "Digitized Date", IMHO. I could see people also wanting to change the latter, so perhaps that's worth a feature request, but I feel that the current behavior is a bug.
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.
> 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.
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.
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
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.)
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 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...
Alan, I would assume that "[XMP] Date/Time Digitized" is XMP xmp:ModifyDate. It maps to IPTC DigitalCreationDate and IPTC DigitalCreationTime as well as EXIF DateTimeDigitized.
Well, I still don't understand all the details on merging and making consistent the various metadata fields, so forgive me if I am still confused.... But reading the post by Gary, I think he may be setting EXIF DateTimeDigitized in his scans using exiftool, and then importing the files into Lightroom, and seeing the problems he describes.
I set XMP CreateDate in my files (using exiftool) before importing into Lightroom and I do not see (have not yet seen) the problems that Gary describes. Hence my question. I raise this because (a) my workflow might work for him, and (b) if there are bugs in LR that I don't know about, I want to understand them. Maintaining metadata correctly is very important to me.
AFAICT, there is no XMP DateTimeDigitized field, which was the source of some of my confusion.
43
Replies
AdChoices