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

  • 4
  • Problem
  • Updated 8 years ago
  • Solved
  • (Edited)
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.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes

Posted 8 years ago

  • 4
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
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.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
Right, 3.4 follows the latest Metadata Working Group guidance, which says:
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.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
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.


I will post the corresponding TIF image tomorrow as I don't have it at hand just know.
Hope that helps.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
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.
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15434 Posts
  • 2277 Reply Likes
Hi John, is the issue you just posted http://feedback.photoshop.com/photosh... related to this topic?
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
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.
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15434 Posts
  • 2277 Reply Likes
Thanks. I've asked someone from the Lightroom eng team to review both topics.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
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
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
Here are the relevant metadata fields, as reported by exiftool v8.5.6 using "-a -G0:1 -s":

[EXIF:IFD0] ModifyDate : 2009:03:13 15:21:10
[EXIF:ExifIFD] CreateDate : 2009:03:13 15:21:10

These are the exiftool names for EXIF DateTime and DateTimeDigitized.

So where is the 1988 date coming from? Is this something you did in Lightroom after Import? It doesn't show up in the original.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
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.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
The issues discussed here are some symptoms of more extensive problems with LR 3.4's handling of metadata dates. See my problem submission:

http://feedback.photoshop.com/photosh...
Photo of Benjamin Warde

Benjamin Warde, Employee

  • 486 Posts
  • 77 Reply Likes
Thanks Sven, I've reported this bug to the Lightroom engineers.

-Ben
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
Thanks Ben
Photo of David Franzen

David Franzen, Employee

  • 101 Posts
  • 21 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
> 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.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4385 Posts
  • 1162 Reply Likes
The release notes say this is fixed in 3.5RC:

http://blogs.adobe.com/lightroomjournal/
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
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.)
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
I've done so, and rewrote it for a specific request of 3.5RC. Thanks!
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
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
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
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.
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
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.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
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.
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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.
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
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.
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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.

http://feedback.photoshop.com/photosh...
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
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).

Alan
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
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%.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
Gary,

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:

[XMP] Date/Time Digitized : 2011:06:27 20:43:15-05:00
[XMP] Create Date : 1985:04:17 12:00:00-05:00

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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
Alan wrote, " I have never found a complete list of all the flags that exiftool recognizes."

The Exiftool command-line options are documented here:

http://www.sno.phy.queensu.ca/~phil/e...

If you invoke "exiftool" with no options, it will also print this out.

The names and definitions of all the metadata tags (fields) recognized by Exiftool are documented here:

http://www.sno.phy.queensu.ca/~phil/e...

Click on any one type (e.g. "EXIF") to see the tags for that type.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
...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.
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
John, thanks for the detailed testing!

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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4271 Posts
  • 1136 Reply Likes
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.
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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!

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

Thanks! Gary
Photo of Mark Sirota

Mark Sirota

  • 146 Posts
  • 29 Reply Likes
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.
Photo of Gary Peterson

Gary Peterson

  • 18 Posts
  • 1 Reply Like
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.
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
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.
Photo of Alan Harper

Alan Harper

  • 453 Posts
  • 92 Reply Likes
In response to this issue and others, I have posted the following idea: http://feedback.photoshop.com/photosh...
Photo of Sven Beller

Sven Beller

  • 27 Posts
  • 7 Reply Likes
The final release of Lr 3.5 now fixed the issue mentioned above.
Thanks for your work.
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 15434 Posts
  • 2277 Reply Likes
Official Response
The final release of Lightroom 3.5 fixes this issue. Launch Lightroom and choose Help>Check for Updates... to install the update.