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.

[Mario]

IMatch now records the date and time of the last write-back.
The information can be accessed using variables. See release note #2056 for more information.

[sdb]

That's excellent Mario.  Many thanks.

[sdb]

Mario - can I assume that, because this new feature relies on data that isn't currently stored, it will only work properly with new databases created after iMatch is updated to include the feature?

In other words, if I create a filter or category to list images that haven't yet got a "last write-back" date, it will include also all images that were written-back before the database upgrade?

I don't see a way of avoiding this but I thought I'd ask.

[Mario]

Mario - can I assume that, because this new feature relies on data that isn't currently stored, it will only work properly with new databases created after iMatch is updated to include the feature?

Yes. IMatch cannot remember the past
This timestamp will be empty for all files until they are written back once.

[thrinn]

Mario - can I assume that, because this new feature relies on data that isn't currently stored, it will only work properly with new databases created after iMatch is updated to include the feature?

Yes. IMatch cannot remember the past
This timestamp will be empty for all files until they are written back once.

... but this does not mean we have to create a new database. Just trigger a write back. Personally I will just wait until write back is required anyway.

[Mario]

You don't have to create a new database or write-back or anything.
The time stamp (and the corresponding variables) will just be empty until you first write-back.

It's an enhancement that works from the day you install the next release.
When you write back a file afterwards, IMatch records the timestamp.

This is not a solution for the OP's particular problem and it cannot be.
Files written back before the next IMatch release will have an empty time stamp until they are written back.

There is no way to tell if a file has been written back in the past, or when.
The "last modified on disk" time stamp cannot be used to initialize this new time stamp and neither is there a reliable metadata time stamp in the file that could be used.

I thought about looking at the XMP creator tag and when it mentions IMatch, using the metadata time stamp.
But that would produce barely a half truth since this tag should contain the first software creating/changing the file, and IMatch does not touch it when it is filled.

Metadata date in XMP is also no choice, since it is set by whatever software updates the metadata (hopefully).