Version Propagation Refinements

[Erik]

I post this request knowing it is probably beyond a realm of possibility, but here it goes:

In my workflow, it isn't unusual for have a Master with up to 3 or 4 versions (different crops, black and white, processing software, etc).

In that workflow, I generally want all the information from the Master to propagate to versions... e.g. Title, Headline, Keywords, Categories, Locations, and so on. 

As part of my workflow, I also end up with my Versions having potentially different labels, ratings, as well as additional hierarchical keywords (indicating processing like black and white, or cropping out a person in an image, etc).


The current propagation options are such that if anything is changed to the master, all versions are given the same information via the propagation rules.  Thus a unique rating or an additional keyword as described before can be lost.   

I propose that some feature be implemented so that if a rating, label, keyword, etc, not match the original master file, that it doesn't get changed due to propagation.  I don't want to lose version specific information due to propagation from a master.  I would expect that if I add a keyword to a master that it would be added through the set, but not necessarily at the expensive of removing version specific keywords.

I realize this is a complicated feature request and perhaps what I'm looking for could be obtained in "simpler" ways.  For instance, perhaps something as simple as an option to not propagate data if the version differed from the master before changes were made to the master.

Perhaps easier would be to somehow provide a way for a version to be locked from propagation from its master.

[Ferdinand]

I support the ratings and labels parts of this request. That is, I'd like to be able to propagation XMP without one or the other or perhaps both rating and label.

[Mario]

I have now linked the propagation or rating/label in XMP to the separate Rating/Label check boxes in File Relations. If you don't propagate Rating/Label from master to versions, but you copy XMP data at write-back, IMatch now retains the rating/label of versions as well. It skips them when copying XMP data from the master to versions at write back time. That was actually a glitch.

As for keywords, that's a different thing, entirely.
So much depends on keywords, from data-driven categories to mapping between the different XMP/IPTC/LR keywords. There is a lot of internal functionality which utilizes relation links when modifying keywords and it will take quite some time to consider which and how to change that. I will put that one back into the queue for some later version. This has got only one vote from another user, so there does not seem to be much demand.

[Ferdinand]

I didn't comment on the keywords idea.  I have reservations about it as well.  It seems to me that if you don't want certain keywords propagated then they probably should be categories rather than keywords, where you can have selective propagation. 

If someone really wanted to have selective propagation for keywords, or not propagate them at all when XMP is copied, then they could adapt my recent (and now mostly redundant) propagation script.  So there is an option that you could use now to implement this workflow.

[Erik]

I want to clarify that the request wasn't to exclude propagation of keywords from the master but rather to prevent deletion of keywords already present in the version.

The propagation behavior right now overwrites ALL keywords in the version.  I'd essentially like to see the master keywords incorporated added to the version's keywords. 

[Ferdinand]

Yes, sorry, I forgot that you had said that.  Doing this is a little harder than you think.  Perhaps once 114 is out I can keep my little propagation script alive by having it deal with cases like this that are hard to deal with natively.  Remind me when 114 is out.

[Ferdinand]

Erik - the latest (and hopefully last) version of my propagation script will do what you want:
https://www.photools.com/community/index.php?topic=3086.0

I should let you know that the option to retain existing keywords in the versions being propagated to took a lot of work.  I did this because I thought it was easy, but oh my goodness gracious me,  was I wrong.  Took several iterations of advice from Phil Harvey to get this to work.  At least I learnt something in the process.

If you decide to use this script then please TEST it first.  I have, but it's now so complex that it's hard to test every option.

[Erik]

I guess I wouldn't have imagined.  I'll have to give it a test soon.  I haven't been home much.  Job has be dealing with a construction project almost daily, so my computer time has suddenly been limited.

I actually wouldn't have thought it too difficult, but I guess it's those types of things that can be difficult.  I think I had started something using the basic scripting environment (i.e. not invoking EXIFTool) because I had some code in place from an earlier project to remove duplicate keywords from files.

I had essentially been reading in the keywords for the master and then each version file.  In a loop I would iterate through each keyword in the master and check whether the version had it or not.  If it did, then I moved on to the next one and if it didn't I would essentially cache.  At the end I would add all the keywords.  Of course, I hadn't dealt with the case of keyword removal, and I was using the metadata features built into the scripting environment.  I actually hadn't gotten too far as I was focused on the logic.

I will definitely TEST your script out.  I always do because at the very least I need to see for myself what the script does even when it is working.

Thanks for doing all that.