Metadata writeback - behaving oddly

[rolandgifford]

I am changing to IMatch from another DAM which has written labels and GPS data to my photos. I have imported these into IMatch and the data is as I expect.

However, after import all of my files are tagged as requiring metadata writeback, without me changing anything in IMatch. There is an option to set the flag to Yes after import based on dates so maybe it is that.

I have started working through writing data back to the image files and the IMatch behaviour is odd, probably because I have set some option incorrectly (or at least I hope that is the problem)

As and example I have a folder with 4001 files. I have selected all of these and run writeback which appeared to clear the flag (based on filtering by the hide files with pending write-back option). Immediately after the writeback IMatch reads metadata and sets the flag again for all of these files.

For each file the metadata flagged as changed is IPTC::Applicationrecord\Keywords and XMP::dc\Subject

Looking at properties for the files in Windows Explorer the Subject appears blank and I can't find the Subject field within the IMatch metadata to compare.

Comparing Tags in Windows properties and IMatch Keywords they are different.
For one example Windows is showing:
Ecuador; 2016_0923 Ecuador; AnnEcuador; 2016; Landscape; Places|America|Ecuador; Styles|Landscape; Waiting Sorting|2016_0923 Ecuador; Waiting Sorting|AnnEcuador; Year|2016;

and IMatch is showing:
Places|America|Ecuador; Styles|Landscape; Waiting Sorting|2016_0923 Ecuador; Waiting Sorting|AnnEcuador; Year|2016;

I suspect that changing the default "Keep existing XMP" option to No on the Metadata 2 option may fix this but thought it better to ask first before breaking something.

[Mario]

This is perfectly normal.

When ingesting as file, IMatch produces a standard-compliant and rich XMP record. Keep in mind that many other applications out there do a sub-standard/miserable/half-assed job when it comes to creating metadata. Required but complex things like mapping native EXIF, GPS, legacy IPTC data into XMP (and vice-versa) are often skipped or implemented only halfway. Check sums and digests are not created etc.

IMatch does the right thing and produces a rich XMP record during ingest and stores that record in the database. When you write-back, this complete XMP record is written to the image or sidecar file. From then on, the XMP for the file on disk and in the database is in-sync.

Immediately after the writeback IMatch reads metadata and sets the flag again for all of these files.

Please see Metadata Problems and Pitfalls in the IMatch help, and especially Files Pending Again After Write-Back
Usually, writing back a file twice allows IMatch and ExifTool to sort out the mess produced by other software. In many cases, out-of-sync flat and hierarchical keywords are the culprit.

The IMatch Metadata Analyst is a great tool to quickly check files for metadata problems.
It informs you about out-of-sync keywords, missing metadata, invalid metadata, bad check sums etc.

If a second write-back does not solve the problem, the keywords may be so badly out-of-sync that IMatch cannot sort it out by itself. In that case, let us know. Provide a sample image which exhibits the problem as an attachment to your post (5 MB max) or upload a sample to your cloud space.

Comparing Tags in Windows properties and IMatch Keywords they are different.

I would not use Windows Explorer as a reference for anything metadata
Microsoft has a long track-record of badly implemented metadata management, they do only the absolute minimum (no money in that) and they did a lot of damage over the past two decades to metadata (from XMP to corrupted maker notes).

I suspect that changing the default "Keep existing XMP" option to No on the Metadata 2 option may fix this but thought it better to ask first before breaking something.

DO NOT change any of the standard metadata settings unless you need exactly what you are doing and what the consequences are. These options exist for a selected expert audience to allow them to sort out metadata mess produced by other software - usually during the initial ingest of a badly maintained collection of files.
For you, me and 99.99% of all IMatch users, the metadata defaults in IMatch work just great.

[rolandgifford]

Please see Metadata Problems and Pitfalls in the IMatch help, and especially Files Pending Again After Write-Back
Usually, writing back a file twice allows IMatch and ExifTool to sort out the mess produced by other software. In many cases, out-of-sync flat and hierarchical keywords are the culprit.

Thank you for this and the other interesting/useful info.
A second write back does remove the flag.