P: Time Zone changed after Pano Merge

[thomasnash]

After a Pano merge of several raw images, the time zone is shifted on the merged dng image so it is different from the original raw (Nikon D850 nef) images in the stack. This results in the stack being moved to a different place in the grid sorted by capture date and it seems at first like the images are lost.

I shoot with UTC time zone in camera (so I don't have to keep changing time zones on travel). I keep that UTC for my catalogues. In the several cases that this problem occurred images were shot in Central Asia (UTC +5) and LR CC pano merge shifted the time by -5 hrs for the merged image as if it were trying to force it to UTC, when it was already set that way, apparently based on the GPS location stored in the image.

Always happens, I believe. This does not happen with a merge done in LR Classic, only in LR CC, apparently.  Version 2.3.

Urgently needs fixing.

[Rikk Flohr: Photography]

We have a bug logged to investigate this.  Thanks for your report. 

[Rikk Flohr: Photography]

Thomas,

We've been unable to reproduce this in-house. Do you have any sample images you could share with us that exhibit the problem?

[thomasnash]

Yes,

I believe it happened with all the panos I made from photos taken with either a Nikon D850 (with an attached di-GPS unit) and with a Z7 connected to an iPhone XsMax via bluetooth and Nikon's SnapBridge app. They are in stacks in the Adobe Cloud. I can share a folder with you. Maybe you can contact me by the email associated with this account and I can give you the link. There are 9 D850 stacks and 13 from the Z7.

They were taken in 2 different time zones and uploaded to the cloud (via an iPad) in probably 2 Central Asian time zones and some in San Francisco and maybe Dubai. My memory is foggy but the incorrect offset  wasn't only -5 hours as stated in the original post but sometimes was other maybe even a +7 (not sure) and might be dependent on the timezone of uploading...

[Rikk Flohr: Photography]

Contacted you direct via Email. 

[Rikk Flohr: Photography]

Thomas, 

The root cause has been discovered in that the photoshop:DateCreated is missing time zone info in your xmp sidecar files. Correct this issue and the merges happen as expected and with the expected time zone.

How are these sidecar files created? 

[thomasnash]

The Nikon cameras do not create side car xmp files. The only place they are created is in LR, presumably on import which as you know was done for some of the files on LR Mobile and some on a Mac desktop. The prefix "photoshop" would suggest that "photoshop:DateCreated" was added to the xmp by the merge routine, since the merges were done in LR not photoshop and the files never opened in Photoshop. I believe "photoshop"is an exif label used by the LR programs.

=========
The following information comes from Rawdigger using exiftool on the merged dng file:
Date/Time Original                                       : 2019:04:09 16:02:04

Create Date                                              : 2019:04:09 16:02:04

Offset Time                                              : -07:00

Offset Time Original                                     : +00:00

Offset Time Digitized                                    : +00:00

Note that the Offset Time is incorrectly set to -07:00.

==========
The following information from Rawdigger using exiftool on one of the image files that went into the merge

Create Date                                   2019:04:09 16:01:57

Offset Time                                   +00:00

Offset Time Original                      +00:00

Offset Time Digitized                     +00:00

Note that here the Offset Time is correctly set to 00:00

===========

The only thing that happened between these two different Offset Time entries was the Lightroom CC merge operation, where it appears the incorrect entry was made.

[Rikk Flohr: Photography]

There were sidecar files alongside the files you shared with us. We need to know which application or client created those side cars. 

[thomasnash]

No other applications or clients were used besides LR CC and a sync to LR Classic which may have been involved in exposure editing after the merge.

[thomasnash]

Is it possible that when photoshop:DateCreated has no following time zone info that is supposed to signify GMT, time zone 00:00.  In other words, is the reason I am seeing this problem special to my using GMT as the time zone in my cameras?

[Rikk Flohr: Photography]

Thomas, 

We are not able to reproduce in house - except with your raw files where a sidecar (XMP) file exists already.  That sidecar file was supplied by you and to troubleshoot further we really need to know which application did the actual creation of the sidecar file. 

Lightroom Classic creates sidecar files easily and on demand. 
Lightroom Desktop only creates them as part of a Save To: operation. 
Other programs can also create them. 

Without knowing exactly how the sidecar was created and by which software (including version) we don't have a way to proceed forward.

[thomasnash]

Thanks for all the effort. It is an interesting bug and may require a specific work flow to reproduce (e.g. camera set to GMT and a LR Classic sync before the merge in Lightroom Desktop).

I use only Adobe software, Lightroom Desktop and Mobile, Lightroom Classic, and occasionally Photoshop, all updated to latest versions by Creative Cloud.

Many of the image sets that exhibit this problem (including the one you have been testing) were ingested in the field by Lightroom Mobile on an iPad. Others were imported in Lightroom Desktop, None directly in LR Classic. I routinely sync images to Lightroom Classic in a catalog for which "Automatically write changes in XMP" is turned ON. It is probable that all of the stacks I shared with you had been through LR Classic synching before I merged them. LR Classic is presently at 8.3.1 and most likely was at that version when the affected stacks were synched.

Since I did not use the Save To: operation in Lightroom Desktop, it would appear that the XMP files were created during or after the sync operation in LR Classic and before the merge in LR Desktop. 

I will try to reimport some of the examples from the original camera XQD cards and try to reproduce the problem before letting LR Classic touch them. I will let you know and put the images in the shared folder.

[thomasnash]

Rikk

I spent several hours trying to track down where the XMP entry photoshop:DateCreated="2019-04-23T14:07:54" with no time zone offset was made.

I used Lightroom Desktop Save To: and copied one stack to another area of my disk, then deleted these files from both LRCC and LRClassic.  I then imported the original raw files directly into LRCC from the XQD card, first via the iMac desktop with a card reader, then via an iPadPro and a card reader and Apple Photos, then via the iMac desktop directly from the Z7 camera. I did not touch the files with LrClassic. I merged in LRCC. In all cases the merged time zone was correct. 

In the first case, I then also opened LRClassic, made an exposure curve change, and let Classic synch and closed it.  Then re-opened LRCC and merged again. The time zone was correct. 

In other words I was unable to reproduce the earlier result with the workflow I believe I used. When I deleted the stack (after saving them outside of LR for reference) and reimported the original saved files, a merge did result in an incorrect time zone for the dng as before.

In the XMP for one of the nef files, as you have noted, the entries are different for the case with an incorrect merged time zone and a correct one, respectively:

  photoshop:DateCreated="2019-04-23T14:07:54"

  photoshop:DateCreated="2019-04-23T07:07:54.500-07:00"

I am sorry I cannot tell you which app or sequence results in the entry with no time zone offset, but the fact that the tag is “photoshop” and that I am only using Adobe software suggest strongly that it is an Adobe product that (in some circumstances) does not provide a +00:00 or Z indication for the UT (GMT) time zone the camera was using.

The following is from the Wikipedia entry on the ISO 8601 standard which defines how Date/Time information is to be formatted:

  “If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. Even within a single geographic time zone, some local times will be ambiguous if the region observes daylight saving time. It is usually preferable to indicate a time zone (zone designator) using the standard's notation.”

and

  “An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00”.”

The Lightroom Desktop merge operation appears to strictly follow the standard where no offset information means local time. As I noted it would seem likely that some other Adobe operation is incorrectly dropping the offset information for the UT(GMT) time zone. Given the ambiguity that the Wikipedia article notes and that one is dealing with multiple time zones in Lightroom, you might consider having the Lightroom Desktop merge operation recognize the lack of an offset as meaning Z or +00:00 (UT/GMT).

[Rikk Flohr: Photography]

Lightroom Desktop 2.4 was released today and contained a fix for this issue. Please update to 2.4 and verify that you are no longer seeing the issue. Thank you!

[thomasnash]

Upgraded and confirmed new version. I was hopeful, but...  Sorry, I did a pano merge on 2 of the image stacks in the folder shared with you and the problem still occurs. The ones I tested were: Z71_6164.NEF....  and 850_6494.nef...

Thanks for still paying attention to this rather obscure problem.

[Rikk Flohr: Photography]

I just pulled down the 850 test files from the bug we've closed. They are merging correctly here for me and end up with the correct time stamp. I will speak to the developer who worked on the bugs to see what his thoughts are.