Metadata mess - how IMatch helped to fix it

[Bolitho]

Just wanted to share some experience :-)

One of the first steps in my workflow is to assign geographic positions to my images using tracklogs. (Being mainly in travel photography, all! of my images contain the respective coordinates.)
In the past Geosetter did the job now IMatch map panel bears the burden of applying the track log data.

Just returning from a longer trip with some thousand images and several track logs I opened the map panel and started to assign the positions.
It mainly worked but a lot of images got wrong positions far away from where they were taken (but still on the tracks).
I dug deeper into this.

Soon I realized all .CR3s were okay but all .jpgs were timewise off by some hours.
All images were taken with the same camera with identical (user) setting.
I shoot mainly raw and just keep strait out of camera HDR .jpgs.
So there are .CR3s (bracketing sequence for HDR) and .jpgs (out of camera HDR) with (almost) the same time stamp.
Why does the assignment work with the .CR3s but not with the .jpgs?
I suspected a timezone problem since the IMatch metadata panel showed the correct timezone for the .CR3s but none for the .jpgs.

I used exiftool to analyze the metadata further.
The images were taken in timezone "0".
All .CR3s contained the correct timezone and offsettimes of "+0". The .jpgs also contained entries but NULL entries for these metadata fields (i.e. garbage).
Thus IMatch (based on exiftool) could not identify a timezone for the .jpgs and assumed they were taken in the system timezone (of currently "+2" in Germany, default IMatch configuration).

IMatch TimeWiz did the trick - I "updated" the timezone of the .jpgs to "0" which wrote clean metadata into the files.

After that the map panel could assign the correct positions without any problem.

Keep in mind all images were produced with a current Canon camera model and most recent firmware (about two months old).
Never trust on cameras writing correct metadata....

[axel.hennig]

Thanks for sharing.

Maybe we should start a discussion which camera vendor follows metadata-standard the best (at least I would be interested)...

[Mario]

Keep in mind all images were produced with a current Canon camera model and most recent firmware (about two months old).
Never trust on cameras writing correct metadata....

I have the impression that camera vendors don't spend much effort or money on implementing the software for their cameras, unless it is system-critical like auto focus and similar.

Hacks like writing a non-compliant "stub" XMP record with a hard-coded "Rating=None".
Adding a full GPS record even if there is no GPS data.
Still relying on the decade old binary EXIF metadata format with it's many shortcomings instead of writing proper XMP.
That they can write XMP is proven by the "stub" XMP record they sometimes include.
Time zone issues like the one described by the OP.
Etc...

The problem is, for me, that these issues often show up the first time in IMatch - since IMatch cares for metadata, uses it everywhere and actually cares for it. And then the user community and I have to provide solutions and guidance.

This is very similar to the metadata mess many of the popular applications out there produce. EXIF and GPS data not migrated to XMP, changes done to EXIF/GPS in XMP not mapped back to the native data. Keywords not written into the standard tags but hidden in proprietary name spaces.

Even very popular cloud-based products (I don't mention names) do this.
I've just had the look at what M*** considers as metadata and I can already see when their users migrate to another service, there will be data loss and tears. Because they have top-notch marketing but don't care for the gritty details of metadata management. You won't notice unless you try to work with your files in other applications.

I'm sure Phil Harvey from ExifTool can tell a lot of horror stories about this