Categories & Stacks

[jeknepley]

When a category is assigned to a stack via the category panel, only the top image is categorized.

• Specific example using auto stack via exif time stamp >> four files resulting from a single capture were placed in a stack - original NEF, 2 jpgs (one on top) & a tif.
• Only the top jpg was categorized.

Does this mean that a stack must be expanded before assigning/changing categories? My guess is operator error.

[sinus]

Does this mean that a stack must be expanded before assigning/changing categories? My guess is operator error.

I guess yes. And I think, this is correct.

[Mario]

Virtually all IMatch commands work on selected files. This is a core principle. Files not selected are not affected.

If you stack files, all files except the stack top are hidden.
They are not even loaded by the file window.
Stacked files may be in a different scope even (e.g., some files in the stack are in a different folder or a different category!).

To perform operations on files currently hidden by a stack, you need to expand the stack, select the files, then run the commands or operations.

Note: If you use version stacks, operations like metadata changes, category assignments etc. are automatically propagated to versions. Whether these versions are currently hidden in the stack or not.

[jeknepley]

Thanks for confirming my experience. I've always understood the part about commands working only on selected files. What I (and I suspect others, as well) did not understand is that when one selects a stack, only the top element is actually selected.

I'll submit a Feature Request for an option to allow the same sort of propagation for regular stacks that's afforded to version stacks in order to avoid, when desired, a seeming unnecessary workflow interruption - unless there's something I'm missing.

[Mario]

We have discussed this several times in the past in this community.

The breaking change you propose would cause one of the fundamental rules to change.
It would also cause a log of extra effort for IMatch, because many commands require some internal "check" so IMatch knows if or not the command is enabled in a particular situation.

If IMatch would now need to process all files in a stack, it would need to load the files in the stack (which are not automatically loaded by the file window) to see if one of the files would prevent the command in question to work. I would also need to spend a lot of time figuring out which commands to disable for stacks, and when. What if you move or rename or copy a stack, but the files in the stack are from different folders? There are quite a huge number of such special cases, and this i why I decided to stick to the "you change what you see and have selected". The only exceptions from this rule, for obvious reasons, are versions.

If this is a regular problem for you, I suggest you switch to version stacks instead. Even if you don't do versions, a manual version stack type would give you exactly what you want. Manual versions allow you to manually make files versions or another file. Without any filename-based rules or anything. And the options you configure for the manual version (e.g., category propagation) are applied when you apply them to the master. And you can work with version stacks as efficiently as with standard stacks  - but have the additional intelligence and metadata propagation as well.

[jeknepley]

Thanks, Mario. I do use version stacks as well as regular. I'll dig further but, in the meantime, I'll just live with it.