I recognized that on my PL5 exports the timezone is set wrong (always set to 00:00 while it should be 02:00). PL4 handles this correctly.
When I check with exiftool the same raw file exported to jpg:
I just tried to create a small test case, but here it is working OK. So I need to check under which conditions this happens. I recognized this today when I had edited the same image with PL4 and PL5 and the capture time was 2h apart.
E.g. this also happened to the files where I compared the PL4 vs. PL5 DeepPrime export times:
now I was at least able to reproduce it a little bit. It looks a little different here, but at least for PL5 the OffsetTimeOriginal = +00:00. I have uploaded a ZIP file with the affected files.
When you:
right click P4040807.ORF ā open with PL4 ā export to jpg ā looks ok (OffsetTimeOriginal not written at all)
right click P4040807.ORF ā open with PL5 ā export to jpg ā OffsetTimeOriginal: +00:00
In contrast to my other attempts, no OffsetTimeOriginal is written this time with PL4 at all.
When checking the files with exiftool:
RAW File (I also checked and the camera has timezone +02:00 set)
@abgestumpft is not the only one seeing this problem; I am also, and itās annoying.
For example, with a NEF image with Original Date/Time (XMP::photoshop\DateCreated\DateCreated\0) value of ā2021:10:13 12:23:04.04-06:00ā, the PL processed JPG image has a value of ā2021:10:13 12:23:04.04-00:00ā. The Digitized Date/Time tag (XMP::xmp\CreateDate\CreateDate\0) does not have this problem. PL 5 should not change the time zone for any of the date/time tags in output files. I donāt recall PL 4 doing this, so I assume itās an inadvertent coding error.
An additional observation: the loss of time zone doesnāt appear to happen when I processed some smartphone jpg images (used PL 5 to some necessary perspective correction). So the bug may be limited to (some?) raw files.
@Marie: It appears that 5.1.1 may have āsortaā fixed this, but in an odd way.
Reprocessing images in folders where āoriginal date/timeā had no time zone in the output file doesnāt seem to have changed (i.e., still '-00:00). Running a āRefreshā on the folder makes no difference.
However, when I create a new folder in PL5 where no processing has occurred, the output JPG images now have a āoriginal date/timeā time zone matching the original raw file.
It appears that PL5 has somehow cached the null time zone in previously created foldersā¦
Can you confirm? Is there some way to over-ride the prior behavior?
To clarify my prior note, Iām still seeing the problem with PL 5.1.2. Not sure what happened in the āsortaā situation, but I again had the problem in a newly created folder.
I have a workaround using my DAM (IMatch) which can change the TZ information to the correct value, but having to do this for each image processed in PL is annoying.
Sebastian, Iāve looked at your image. I did the following: exiftool.exe -*Date* P4040807.ORF
and I got:
File Modification Date/Time : 2021:10:27 21:51:49+03:00
File Access Date/Time : 2022:01:14 13:33:17+02:00
File Creation Date/Time : 2022:01:14 13:31:43+02:00
Modify Date : 2021:10:27 20:51:49
Date/Time Original : 2017:04:04 12:05:26
Create Date : 2017:04:04 12:05:26
Date Time UTC : 2017:04:04 10:05:26
GPS Date Stamp : 2021:10:27
Modify Date : 2021:10:27 20:51:49+02:00
GPS Date/Time : 2021:10:27 12:02:16Z
We never look at the file date/time, so the first three values are just ignored. But we look at Metadata tags and there, the only timezone we have in the source image is for Modify Date .
Maybe, we missed anything in the XMP?
This is what we have in the .XMP sidecar:
HistoryWhen: which is also present with a timezone, is not read by our code.
So, again, the timezone is present only for ModifyDate. Unfortunately, we cannot invent the timezone and cannot guess what it is, based on the GPS or other references to the location.
Letās think what we can do here.
Hi John, have you submitted any images to look at? Iāve answered to Sebastian already. The idea is that there is a fixed list of metadata tags we read and the tags in exported images are based on the source image data. So, if the timezone is missing in the source image, it cannot appear in the exported one. In the image provided by Sebastian, some tags had the timezone and some didnāt. And they got to the exported image exactly as they were in the source image.
Here you see that the .ORF does NOT contain the tag āOffset Time Originalā
It is also not present in the export I did with PL 4.
With PL 5 there is now āOffset Time Originalā, and in my case this one is always on ā+00:00ā.
Exiftool also uses this tag to create the composite tag āDate/Time Originalā (=[Composite:Main:ID-Exif-SubSecDateTimeOriginal] SubSecDateTimeOriginal)
0x9003 DateTimeOriginal string ExifIFD (date/time when original image was taken)
0x9010 OffsetTime string ExifIFD (time zone for ModifyDate)
0x9011 OffsetTimeOriginal string ExifIFD (time zone for DateTimeOriginal)
0x9291 SubSecTimeOriginal string ExifIFD (fractional seconds for DateTimeOriginal)
I think the cause is that Olympus does NOT store the exif-tag āOffsetTimeOriginalā in the .ORF file.
With PL4 the tag was not exported at all in this case. With PL5 it seems that (in case āOffsetTimeOriginalā tag is missing) this tag is then set with +00:00 on export.
I have now crossed checked with a Nikon Z6 II RAW file: here in the .NEF file the āOffsetTimeOriginalā tag is already set and also exported correctly both by PL4 and PL5.
Maybe the best is to behave like PL4 on export in the case āOffsetTimeOriginalā tag is missing: do not set this tag at all.
Sebastian,
in our code, whether the timezone tag is missing or we have it equal to 0, it is the same. So, when we read the tags and the timezone one is missing, we fill it in, with zeros. And upon saving, we cannot distinguish if it was missing or had zeros. So, it is important for timezone to be still missing after an export? Why? I need to understand this. Maybe, I missed something.
Hi Arthur,
in my opinion it is a mistake to fill unknown tags with zeros. As you say you cannot say afterwards anymore if the tag was missing or was really on zero before. On āOffset Time Originalā this means PL5 will change the information from āOffset Time Originalā missing = Timezone unknown to āOffset Time Originalā = +00:00 ā this Photo was taken in timezone +00:00
As said, with PL4 the āOffset Time Originalā was not written in case it was missing. Now with PL5 it will be set to +00:00
One more thing: I also recognized that now the XMP-EXIF Tag DateTimeOriginal is set with that timezone āOffset Time Originalā after export:
When checking first an Nikon Z6II NEF and then the Olympus ORF:
I think itās also a mistake by Olympus not to set āOffset Time Originalā (but seems like all the older cameras also didnāt set this). But in my opinion itās also a mistake by PL5 to set the āOffset Time Originalā = +00:00 in case it is missing.
PL5 should certainly populate intact all tags in the original file to the output file(s). If itās only exporting an incomplete subset, that is a significant problem.
Let me know if you have questions or need more information.
There are a bunch of tags for times and time zone, with confusing and odd names. I believe (but would have to check to be sure) that in recent version EXIF gained the ability to include time zone information, although thatās something it didnāt used to have.
There are also XMP tags for date/times, which do include TZ information. I believe the most useful/important ones are
XMP::\photoshop\DateCreated\DateCreated\0 (for original date/time - i.e., the original image was taken) and
XMP::\xmp\CreateDate\CreateDate\0 (date/time when the image was digitized).
For most digital photo images, these have the same values, but they will be different for scanned images, etc.