Date Taken in Explorer and DO

Help & Support
1

When I change the date taken metadata of an image file (*.jpg) in DO the date taken shown in file properties/details or windows explorer will either be cleared or doesn't change. When changing date taken in file properties the date for both date taken and date digitized are updated in DO. Is this a bug?

I'm currently using DO 12.0.3.0 beta but a user of the german forum reported the same behaviour with version 11.17 and windows 10.

2

Try turning on Preferences / File Operations / Metadata / Update last modified file dates when setting metadata inside files if it is off. Maybe Explorer will refresh the file if the modified date changes.

Also see if Explorer shows the right value if you copy the file. If it does then you know Opus changed the file correctly and the problem is Explorer's caching of the values.

3

Turning on the preferences option and/or copying the file doesn't change the described behaviour here.

4

DO does seem to add this exif information shown below, and does not set additional xmp fields?
There are also some weird characters in front of the date, don't know if that's ok? Looks like a BOM, hu?

---- ExifIFD ---- DateTimeOriginal : 2011:01:01 01:00:00
Explorer on the other hand sets some more data, the added information is this:

---- ExifIFD ---- DateTimeOriginal : 2012:02:02 01:22:14 CreateDate : 2012:02:02 01:22:14 SubSecTimeOriginal : 38 SubSecTimeDigitized : 38 Padding : (Binary data 2060 bytes, use -b option to extract) ---- IFD0 ---- Padding : (Binary data 2060 bytes, use -b option to extract) ---- XMP-rdf ---- About : uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b ---- XMP-xmp ---- CreateDate : 2012:02:02 01:22:14.382
Notice the XMP data and no weird characters in front of DateTimeOriginal.

Setting "DateTimeOriginal" with exiftool.exe yields this (notice: no weird characters in front of the date).
Explorer will show this date even though there is no XMP present (another hint all this is related to the 3 extra chars DO inserts?).

---- ExifIFD ---- ExifVersion : 0230 DateTimeOriginal : 2012:02:02 01:22:14
I never dived into exif and these tags and the many ways of doing the same thing, so in case this is not useful, just ignore it. o)
My weapon of choice to compare the differences was this commandline, it's simply dumping all exif data with exiftool.exe:
exiftool.exe -s -a -u -g1 {f}

5

 is the UTF-8 BOM, so not that weird.

6

Yes looked liked that, didn't know it's ok in exif date fields. o)

7

I don't know either, but it appears to be valid in other EXIF fields at least.

It's just as likely that Explorer is reporting one of the other date fields than the one Opus is not updating. More analysis is needed to work out what's really going on.

Some sample files could be useful here.

8

As mentioned, I only set and rewrote this specific date field using exiftool.exe after it has been set using DO and it did not show in Explorer.
Explorer then started to show the date, so it looks like this specific field does the job if it's without the BOM. Looks! - I don't know for sure.

9

This is the test image from the german forum, shows date in DO but not in Explorer:
haage-partner.de/forum/view ... 945#p22884

10

As tbone surmised, the problem seems to be caused by the BOM header that Opus writes - Explorer seems unable to handle it even though it's technically allowed by the specification.

In the next version we'll change it so that Opus doesn't write the BOM for fields that in reality never need it (e.g. the "date taken" field never needs to be encoded as anything other than ASCII). This should solve the problem.

(As an aside: there are two main EXIF date fields, "date taken" and "date digitized". Explorer only shows one date field in the Properties dialog whereas Opus will show both. It seems like Explorer will use the value of "date digitized" if - as in this case - it can't read the value of "date taken". This explains why the Explorer Properties dialog shows a different date for "Date taken" to Opus for the test picture).

11

Hi,

I'm still seeing the BOM header in the EXIF DateTaken field, but am using DO 11.19 on a Windows 10 x64 system. The unexpected characters are causing a batch file rename to fail.

The original post mentioned DO 11.17, and latest post suggested an upcoming fix. Is this a bug in DO 11.19, or has the change been deferred to a later release?

Thanks!

12

11.19 came out June 10 and the post mentioning future versions was June 29, so the post definitely didn't mean 11.19 would contain the fix.

I believe current Opus 12 betas have the proposed fix, if you want to give them a try.

12.0.8 from July 1 included this change in the release notes:

When setting EXIF tags in pictures, Opus will no longer use UTF-8 for fields that never require it (e.g. "Date Taken"). This is to prevent compatibility problems with software that has trouble with the UTF-8 BOM header in certain fields (e.g. Explorer).

13

Thanks for your super-fast reply!

You're right, I confused the dates for the release date of 11.19 vs. post mentioning the upcoming fix.

Glad to hear this is fixed in v12. I'll wait for the beta to complete and then upgrade.