Propagation of categories

[tvi55]

During the propagation of the selected categories the following is happening with the current implementation of IM5:

     If the target file already includes categories which are not available in the master file,
     then they still exist after propagation.

I want to request a feature which enables the complete replacement of the categories, which have been selected for propagation, at the target file.

In order to preserve the current functionality, I suggest to implement this optional, so the user could select to 

• either fully replace the categories at the target file ("replace" or "clean") - my request
  
• or keep  the categories which already exist at the target file ("merge") - as implemented today
  

[Ferdinand]

If implemented this would definitely need to be an option, as I do not want this under any circumstances.

[DigPeter]

During the propagation of the selected categories the following is happening with the current implementation of IM5:

     If the target file already includes categories which are not available in the master file,
     then they still exist after propagation.

I want to request a feature which enables the complete replacement of the categories, which have been selected for propagation, at the target file.

In order to preserve the current functionality, I suggest to implement this optional, so the user could select to 

• either fully replace the categories at the target file ("replace" or "clean") - my request
  
• or keep  the categories which already exist at the target file ("merge") - as implemented today
  

I think you would need to describe precisely what you want with this.  Why not unassign existing categories in the target version, then propagate from the master. 

I agree with Ferdinand.

[Ferdinand]

I think you would need to describe precisely what you want with this.  Why not unassign existing categories in the target version, then propagate from the master. 

I understand why he wants it.  My synchronisation script had this option.  And he wants it to be fairly automatic.  So would I.

[tvi55]

I think you would need to describe precisely what you want with this.  Why not unassign existing categories in the target version, then propagate from the master. 

I should have explained the reason for my request in more detail, although it might be an exotic one to many users - here it is:

I want to make sure that the categories which I select for propagation are completely in sync between the master and the target files. In my case these are the descriptive elements of the photo like event, location, people, and others. The propagation should work not only for the initial copy, but should also automatically reflect subsequent additions, changes, and deletions within the selected categories of the master file. With the current implementation in IM5 this would (probably) by only possible if you first manually (or by using a script) empty the target categories, which would make the workflow more cumbersome.

I understand that there may be categories which shall be unique to the master or target files (eg. information about the version, etc.), but these for sure should then not be included in propagation.

Honestly I was very surprised, that the requested functionality had not been implemented as the base functionality, as the possibility to select the desired categories for propagation has given the immediate impression to me that this would work as requested here.

Users obviously have different requirements and expectations with respect to the propagation functionality, therefore I suggested to steer the desired propagation functionality by using an option. 

[Mario]

I'm not sure that this will be so easy.

If you have an option "strip all categories from versions", how will that work?

You assign a new category to the master, e.g. in the Category Panel or via a Favorite.

This category is from a section of the category tree which is included in the propagation. Currently, IMatch just adds the category which was added to the master also to all versions with category propagation enabled. Easy.

But if we have this new option, adding one category to the master would first remove all categories from all versions (with category propagation) and then IMatch would not just have to add one category but copy all categories from the master to the versions to implement the new option. This is quite a bit more complicated and slow than what we have now. Not to speak about the additional resources required for the undo operation etc.

Furthermore, I can foresee that users will immediately come up with additional requests, like "I want to remove all categories from the version, except these".Or even more fine-level control.

And how often does it happen that the categories of the versions and the master get out of synch? All files enter the database without any categories assigned. They may end up in data-driven categories or @Keywords, but that's different.

If you are in the habit of assigning categories to versions and you want the versioning to fix that for you, this would be a reason for having the additional option. You could also just select the versions, remove them from all categories (easy via the current tab in the Category Panel) and then for a F4,P on the master to propagate again.

And that's just the things I've came up with right now. There is surely more involved when I take the time to think this trough.

Honestly I was very surprised, that the requested functionality had not been implemented as the base functionality, as the possibility to select the desired categories for propagation has given the immediate impression to me that this would work as requested here.

The reason that this is not implemented, and to my knowledge has not been requested over the entire Beta test (about a year) may be an indicator that not many users need such a option or feature.

Naturally, if you ask users "Would you like to have such an option", they usually say "Sure, why not?".

But will they ever use it? More than once? Is the price all users have to pay for this (slower performance, more complexity, potential unwanted side effects...) worth it? How many users would really benefit from this? All these are questions that need to be answered before features are implemented.

[tvi55]

Hi Mario, I appreciate your detailed feedback and thoughts about my request. For sure I can't comment on the complexity of the technical implementation, and I understand the potential "threat" about additional requests in that area which could make propagation very complex to implement or even to understand.

And how often does it happen that the categories of the versions and the master get out of synch? All files enter the database without any categories assigned. They may end up in data-driven categories or @Keywords, but that's different.

Getting out of sync is very easy in my situation - it is the consequence on my approach on maintaining my archive.  As supposed earlier I might have some "exotic" (unique) habits here:

My category structure is never completed/frozen but being steadily more and more refined. So also the assignment of categories to my photos is not a onestop activity where the current logic of propagation would be fully sufficient, but a process with changes to photos archived earlier. 

For the example of "Location" I usually start to assign the photos to a city. The more and more photos I collect from that city I consider adding a next level to the category tree with eg. the names of tourist attractions. When I then review my earlier photos from that city again I apply the more refined categories to them and remove the earlier assigned categories on higher (city) level.   

Furthermore, as I am a human being, I from time to time have also to change (correct) some category assignments because they are wrong.

And finally, my personal requirement has been that I can see all my categories, which describe the content of the photos,  also in the versions (in my case these are the jpg files developed from raw).

If you are in the habit of assigning categories to versions and you want the versioning to fix that for you, this would be a reason for having the additional option. You could also just select the versions, remove them from all categories (easy via the current tab in the Category Panel) and then for a F4,P on the master to propagate again.

I probably have to rethink my approach to archiving. In any case I am eager in getting IM5 to replace IM3, but also to get rid of most of the manual / scripting efforts which I have had in place to suit my requirements.

[jch2103]

Getting out of sync is very easy in my situation - it is the consequence on my approach on maintaining my archive.  As supposed earlier I might have some "exotic" (unique) habits here:

My category structure is never completed/frozen but being steadily more and more refined. So also the assignment of categories to my photos is not a onestop activity where the current logic of propagation would be fully sufficient, but a process with changes to photos archived earlier. 

If all your masters and targets are in sync, you should be able to make changes in categories through the Categories tab that will apply to both masters and targets, unless I don't properly understand your situation. One of the (many) things I like about IM5 is the ability to change my category structure at any time.

[tvi55]

If all your masters and targets are in sync, you should be able to make changes in categories through the Categories tab that will apply to both masters and targets, unless I don't properly understand your situation. One of the (many) things I like about IM5 is the ability to change my category structure at any time.

I understand how changes within the category structure can be done, and I appreciate this functionality with its automatic reflection in all related photos.

The changes I am talking about (I am obviously lacking clarity in my description) are

(a) changes from an earlier category assignment of individual photos to a more granular one like

from
--- / City / London
to
--- / City / London / Buckingham-Palace
--- / City / London / Trafalgar-Square

(b) simple corrections like

from
--- / animal / elephant
to
--- / animal / mouse

for the case that I had confused these before :-).

Please help me: Am I so completely off the usual track of working with IM3/IM5? From the very limited feedback here on my request I tend to conclude that (almost) nobody is doing changes like these, which I honestly can't imagine, or – probably more likely - nobody propagates such categories to versions. I am willing to learn and adapt, if there is a better way of dealing with masters and versions. 

[Mario]

For example:

(b) simple corrections like

from
--- / animal / elephant
to
--- / animal / mouse

If you propagate the animal category hierarchy, removing the master from "elephant" will also remove all versions from that category. And adding the master to "mouse" will also add all versions to "mouse". So it will work automatically using the current implementation. No need for changes.

What category propagation cannot solve is when you have the version already assigned to "mouse" and then you assign the parent to "elephant". The version will end up being as both mouse and an elephant. This is why, if you intent to use category propagation, the categories of the master and versions should be in synch once. Since files added to a database usually have no category assignments, this is usually the case. Master and version start without categories, and you manipulate only the master. This will keep the version automatically in synch.

[tvi55]

I am completely puzzled! Something was obviously wrong with my test setup. Although having worked on a fresh database I had only seen the situation that during category changes new ones were propagated but removals from the master not being reflected in the versions. And from the discussion I had concluded that this is "working as designed".

Having tested the scenario again it is obvious to me now, that the requested functionality is already available and that it even works without the need to manually trigger the propagation.

That's really great – I am fully satisfied with the implemented functionality! Consequently I hereby "formally" withdraw my feature request.

[Mario]

It's working for you now, that's good news 

I'll keep this in the list anyway. As a reminder for some ideas I had while following this thread.

[ubacher]

A question came up in my mind:
In file relations - versioning - categories to propagate:
What is the difference between neutral and exclude i.e. nothing in the check square vs. a minus in the check square.

My interpretation would be:
The minus means that this category is removed from the version(s) if it exists?

[Mario]

- = exclude from propagation. You cannot remove categories during propagation. See the help for details.

[ubacher]

So minus has the same functionality as nothing (neutral)?

[Mario]

No. If you include the parent recursively, it includes all child categories, checked or not. - is to explicitly exclude.
If you do some tests by yourself you'll find out how this works.