Metadata Messes & First Write-Back

[sdb]

Judging by the posts I have read, many people have problems resulting from inconsistencies and errors in their metadata, giving rise to unexpected changes (or failures to make expected changes) during write-back.

I wouldn't be surprised to find all my images contain ... sub-optimal metadata.  Many I'm sure contain what Mario would call 'metadata messes'.  When it comes to dates, here's how I fix them:
1.  I make sure I have valid and correct dates (including timezone offsets) in the Create Date and Date Subject Created fields.
2.  I leave everything else to iMatch.

This (I think) has been working well nearly all the time.  But some metadata issues can not be fixed in this way.  We can't expect iMatch to fix all possible messes - it isn't magic, even though it may sometimes appear to be.

I have had situations in which write-back after an innocuous change (e.g. a title change), or even a forced write-back with no changes, resulted in unexpected date changes (and in some cases overwriting of useful data).

I suppose I could use the Metadata Analyst App to check each file before write-back, and figure out what fixes are needed and how to make them without triggering a write-back causing more problems, but this is an impractical workflow, especially given that most metadata inconsistencies will get automatically fixed by iMatch.

I don't think there is a real fix for this, but I have a suggestion:
Most of these problematic metadata issues (and all the ones I have encountered) arise during the first write-back, which is when iMatch/Exiftool first attempts to synchronise the possibly-inconsistent metadata.  How about a new iMatch Workflow Category for "Never-Written-Back" files?

I would use this in the following ways:
1.  By using color-coding for the category I would be able to see immediately which files I need to be wary of updating, and which I can be confident about changing.
2.  I could easily find all the files I have yet to 'process', to make my worklow more efficient.
3.  If I want to export the files to use elsewhere I could check first that thay have been written back so the metadata should be sync'ed.
4.  Most of my basic updates are done programmatically, and I would have the ability to have the program take different steps dependent on the category.

[Mario]

Easy.

Create a data-driven category based on this tag: XMP::xmp\CreatorTool\CreatorTool
If the tag is empty or does not contain "photools.com IMatch" the file was never written back.

[sdb]

Fantastic!  Thanks.

[Mario]

Ps.: the XMP::xmp\MetadataDate\MetadataDate contains the date and time the metadata was last written.

[sdb]

Mario - this doesn't seem to work.

I have a few files with "photools.com IMatch"  in XMP::xmp\CreatorTool\CreatorTool, but very many which I know I have written-back but which contain text such as "Picasa", "Adobe Photoshop Elements 2.0", etc.

This shows up using VarToy.  Using exiftool I can't find this tag, but the same contents show in [IFD0] Software

[Mario]

You're correct. My bad. I wrote that from memory.
This tag contains the first application that has written metadata. If it exists, IMatch does not update it, as per XMP specification.
This will not work for your specific needs.

Let's see if your request gets a number of Likes.

IMatch does currently not report a time stamp for write-back operations in the database. I would have to add that and update it during write-back, then make it available as a variable and/or custom IMatch tag.

[sdb]

...
IMatch does currently not report a time stamp for write-back operations in the database. I would have to add that and update it during write-back, then make it available as a variable and/or custom IMatch tag.
...

I'd really like to know whether a write-back has taken place; I'm not sure of the added value of knowing when. But maybe the work involved is about the same.

[sdb]

Can you move this back to the unsolved feature requests section - might get more likes that way

[Mario]

Yup.