How to select attributes for propagating in versioning?

[Dirk Funhoff]

I am currently trying to utilise versioning - and stumbled over this question: my workflow starts with RAW which I develop in LR and convert into jpg. I add attributes to the raw like title, special circumstances etc. overall 5 of them. One record is "digital workup" which is not filled on the RAW stage but later with the jpg (or any other derivative). This information is not stored with the raw, but the jpg-version. Now, if I propagate the attributes starting from the master, the "digital workup" is gone as this record is empty in the raw/master. Is there any way to exclude specific attributes records from propagation?

Many thanks for an answer, Dirk

[Ferdinand]

I'm not aware of one.  Can you use a category instead for this kind of information?

[Dirk Funhoff]

Well, not really. This record contains information about how I made the given image, e.g. describes what steps I did in Photoshop. In IMatch 3.6 I used a script wherein I did specify which category-records need to be transferred to the jpg. I guess, I could transfer it to IMatch5, but maybe a choice (like in propagating categories) could also be used in attributes?

[Mario]

The general idea of versioning is to propagate data from the master to versions.
All attribute data is copied as a block, you cannot pick individual Attribute Sets or even individual Attributes to propagate.
If you need to maintain Attributes in versions which are different from the Attributes in the master, don't version Attributes.

[Dirk Funhoff]

Yes - I understand this limit - although I am a little bit surprised now. Given, that "attributes are an exclusive IMatch concept" and that you even created file and global attribute sets I simply assumed, that there must be a way to select single attribute-records within a set like one can do with categories.
Nevertheless, to maintain version-specific content in selected attribute-records would be nice, especially if you work with versions later for different uses.
Anyhow, topic is clear and I need to find a work-around to it.

Many thanks for clarification, Dirk

[Ferdinand]

In IMatch 3.6, I had a script that performed propagation which allowed to you pick and choose which properties (now attributes) you propagated.  I haven't really missed this functionality in IMatch 5 because what I store in attributes now is mostly file-specific information.  Most other information is now readily accessible in metadata.  However from time to time I still have the need to propagate one or two attribute fields to other versions / the master.  I have a script that does that.  I could share that script if you wish, although you'd need to customise it somewhat.

[Mario]

Yes - I understand this limit - although I am a little bit surprised now. Given, that "attributes are an exclusive IMatch concept" and that you even created file and global attribute sets I simply assumed, that there must be a way to select single attribute-records within a set like one can do with categories.
Nevertheless, to maintain version-specific content in selected attribute-records would be nice, especially if you work with versions later for different uses.
Anyhow, topic is clear and I need to find a work-around to it.

Many thanks for clarification, Dirk

Attribute propagation as a block is how it works since IMatch 5 was shipped in June 2014. I don't recall any discussions about adding features to control which Sets or Attributes to propagate and to my knowledge there is also no related feature request. So, while this may be important for you in your current situation or your workflow, it does not seem to be a problem for other users. This is not unusual. You can add a feature request in the FR board and see if other users comment on it or 'like' it add some momentum.

[Dirk Funhoff]

Many thanks for your comments. Ok, I will add this to the FR board.

@ Ferdinand: many thanks for your offer and please, yes, share your script with me. I used to have a script to do transfer categories / properties from my raw-files to the derivatives, but this does not work any more and it will take a lot of time for me as unexperienced scripter to change it. Having an 5er version as a starting point for adaptation would be much easier for me. How do we proceed?

[Ferdinand]

I realised that I couldn't simply attach the script as it was, for a couple of reasons.  So I've tweaked it.  I've tested it, and it works for me.  Hopefully it works for you too.

You'll need to edit the script.  The first line is where you specify the name of your attribute set:
Const SET_NAME As String = "Image"

You'll see that there are three attribute fields that I'm copying - you'll need to insert / add your own.

You'll see that the attribute values are copied only if those fields in the target files are empty - again you can easily change this to overwrite existing values.

You'll see that there are dimension declarations for a number of unused variables - that simply reflects the fact that this script was hacked from other more complex scripts and I haven't bothered to clean it up to that extent.

There's not much checking done in the script, so for example, if you select a version rather than a master and run it, nothing happens.  It's possible the script with crash if you don't correctly insert the attribute set name and attribute field names, and perhaps also for other reasons that I haven't yet thought of.

Best of luck.

[attachment deleted by admin]

[Dirk Funhoff]

Hi Ferdinand,

many, many thanks - it works, great! After I deleted all the stuff which made it stop (G3 Attributes and similiar) it ran and did as hoped: copied the respective attribute-records into the version(s). Very well.  Being (and feeling) really like a sorcerer's apprentice in this matter, I did not dare to clean the script further - as you said, there is probably a lot going on which is not needed any more. But for me it would be a trial and error approach, so I am glad this version now does what I want.

Many thanks again, Dirk

[Ferdinand]

I'm pleased to hear it.  You were just lucky that I already had a script here that did more or less what you wanted.  I had to remove some code that created copies of the selected files, and in so doing I noticed that because this was a script that I had quickly migrated from IMatch 3.6, it didn't use IMatch 5 file relations.  Instead it went through every file in the DB looking for a file name match.  This was actually a lucky discovery for me, as it explains why the script was a bit slow.  I'll be able to speed up my own copy by simply getting the names and locations of the versions from IMatch, which maintains a list.  For this reason, you want to be sure that your file relations are refreshed and up-to-date before you run the script, or else there's a risk that a version will be overlooked.

[Dirk Funhoff]

Thanks for the advice. Currently I am just using versions starting for my new entries, so that should be fine. I am still contemplating about whether I should "versionise" the whole database... but thats another topic.