Versions - How to create a Metadata Tag which is not overwritten by Master info

[moviemaker445]

I want to record editing information and technique used to produce a Version in the Version metadata and have that information 'locked' so it is not overwritten when the Master file is updated. Is it possible to exclude a tag in a Version from being updated similar to the 'Don't copy XMP Label' option?

[Mario]

IMatch copies the tags you select for propagation. Maybe be more selective in what you copy?
There are no other options that what you can see in the propagation dialog.

[sinus]

IMatch copies the tags you select for propagation. Maybe be more selective in what you copy?
There are no other options that what you can see in the propagation dialog.

I think, this is the (easy) way to go.

[digedag]

[...] not overwritten when the Master file is updated [...]

Hi moviemaker445,
in such a (rare) case I help with this:

- Temporarily disable the corresponding relation definition (MASTER - VERSION)
- Update MASTER and write back
- Reactivate the relation definition

With this I prevent that metadata of VERSION (e.g. keyword "panorama photo") is overwritten by unwanted metadata of MASTER (e.g. keyword "source for panorama").
Bernhard

[Mario]

I might have a feature in IMatch 2023 which solves this problem - and add a lot more flexibility to metadata propagation.

I've had this implemented in a "branch" but never got around to finish and integrate it into IMatch. Always so much stuff to do...
This post reminded me of that feature and I've had a look today (Sunday, when else get some work done).

The new feature is an 'advanced' extension to the current metadata propagation feature. It allows to:

+ exclude specific tags when propagation groups like "All XMP"
(That's what moviemaker445 needs)

+ propagate individual tags instead of entire groups

+ set tags to a value during propagation

The feature is considered advanced because it requires some thought and a basic understanding of how metadata works.
It will work for typical use-cases, but it also offers users a new way to shot themselves into their own foot.

IMatch performs propagation based on tag groups for a reason (e.g. "All XMP data") - because this avoids potential problems caused by propagating only some tags, but not all that are required to create a valid result.
For general usage, the current "click what you want to propagate" is the way to go. It is easy and ensures metadata consistency.

The new feature works similar to how custom metadata in the Batch Processor works (see: Using Custom Metadata)

In addition to checking some tag groups for propagation, users can now add ExifTool commands to retain specific tags or set tags to a value during propagation. Or, instead of propagating tag groups, only propagate one or more tags.

For example, if the user propagates the "All XMP" group but adds

--XMP-dc:Title

into the new feature, the existing XMP Title in the version is not replaced during propagation.
If a user does not enable any of the metadata propagation groups, he can propagate selected tags by specifying something like

-XMP-dc:Title
-XMP-photoshop:Headline
-XMP-photoshop:Credit=Mario M. Westphal

in the new feature. This propagates Title and Headline from the Master to the versions and sets the Credit tag in the versions to to "Mario M. Westphal".

How's that?

[thrinn]

Sounds like a perfect solution!

[Mario]

I suppose

I always try to make IMatch work better for its users.

[sinus]

I suppose

I always try to make IMatch work better for its users.

Yep, and you do it for sure.
But what is also for sure, is, that for IMatch 2023 I will have to read a lot (the release notes, the update help ...) and think a lot. 

[Mario]

Reading the release notes is always a good idea

While finalizing this new feature, I've decided to add support for variables.
This means, advanced users who need this, can fill metadata tags in versions from variables during propagation.
{File.*} variables reference the master file currently propagating.

Example:

Code Select Expand

-XMP-photoshop:Credit=Copyright {File.DateTime|format:YYYY} Paul P. Photographer
sets the Credit tag in the version to the master's year and the name Paul P. Photographer.

This could be used to update project codes or XMP media management values during propagation.
Nothing most users will ever need, but I see uses for that in typical professional workflows.

[Damit]

This is awesome and addresses the issues I discussed here: Re: Is propagating keywords additive or does it replace the info of the verson?. As I said in that thread, it would be great if this extended to keywords.

[Mario]

This is awesome and addresses the issues I discussed here: Re: Is propagating keywords additive or does it replace the info of the verson?. As I said in that thread, it would be great if this extended to keywords.

Not really. Well, to some extent. Not sure...

The new advanced features allow you to select tags to include or exclude. And you can set tags from variables.
But this does not automatically lead to a solution where you propagate individual parts of a repeatable tag like keywords.
You would have to come up with a filtering variable with produces only the keywords to propagate. Which may be doable or ridiculously complex, depending on your requirements and skill set.

If you actually have to find a way to propagate only some keywords, you should maybe give your workflow a think and figure out if you really need to propagate keywords from the master to versions at all. Maybe it's just simpler to not propagate keywords at all and instead just set them directly for the versions as needed. If you don't propagate them, they are not changed.

You can, though, exclude flat and hierarchical keywords and legacy IPTC keywords from propagation even if you otherwise propagate the entire group.

Or, you just propagate more selectively, using the options IMatch already provides now. Like, propagating only title, description, rating, label etc.

[Damit]

...you should maybe give your workflow a think and figure out if you really need to propagate keywords from the master to versions at all. Maybe it's just simpler to not propagate keywords at all and instead just set them directly for the versions as needed. If you don't propagate them, they are not changed.

You can, though, exclude flat and hierarchical keywords and legacy IPTC keywords from propagation even if you otherwise propagate the entire group.

I am doing just that.  I have been for a while, which is how I ran into this issue, considering what I was goign to propagate and how it would integrate into a file naming system. If I could remove a hierarchical branch or even a part of its tree that is the only thing I cannot work around.  You are right some things don't need to be propagated and also some keywords would not exist in the master that may interfere with the version, unless the keywords are completely replaced, where the edit information of a version would be erased by the copied keywords of the Master. That is mainly where the issue lies, and it all exists in the How Parent tree of my Keywords.  So if I could exclude that Hierarchical branch all the other keywords concerning Who, What Where, When etc that the versions would benefit from receiving could be propagate.

I find that most of the images would benefit from keywords transfer in the aforementioned fields other than cropped images. 

[Mario]

As I said in the related thread, if you want different data in tag X for the master and versions, don't propagate tag X.
Propagation is mind-blowing complex already as it is, and way over the head (or needs) of the vast majority of the user base (according to telemetry).
Adding more and more features to it, e.g. selective propagation of parts of tags or only some values under some conditions, is definitely not helping it. And would make it much more complex, since IMatch rolls this all via ExifTool at the base, and adding selective propagation on that level would be really hard to do.