Add category to all files in a stack

[meyersoft]

Actually, only the top of stack-file gets a category.
I would like to have an option so all files in a stack are affected by category changes if the stack category changes.
Instead of an option, this could also be default behaviour.

[Ferdinand]

I support this.

[Mario]

For now, I suggest you do a

<Shift><E> to expand the stack followed by a
<Shift>+<Strg>+<A> to select all files in the stack.

When you now assign categories or perform other commands, all files in the stack will be affected.

Almost all commands work only on selected (and visible files - aka the stack top). Or on files not filtered out by the current filter. This is how IMatch operates. If a stack is collapsed, the hidden images are not even loaded from the database. Same for files filtered out.

If we now make a special case for categories and stacks, I would have to change quite a lot of code. And surely other users will request additional exceptions for bookmarks, or pins, or rating, label or all collections...

The simple principle that commands work only on selected and visible files is maybe easier to learn, remember and understand, in the long run.

[bonsai]

The simple principle that commands work only on selected and visible files is maybe easier to learn, remember and understand, in the long run.

You are absolutely right and I think you should leave it as it is.

[BenAW]

The simple principle that commands work only on selected and visible files is maybe easier to learn, remember and understand, in the long run.

You are absolutely right and I think you should leave it as it is.

Totally agree

[Erik]

I support this.

I do, too.

The purpose of a stack is to group similar files together, whatever you deem similar as

As it is, I work very little with stacks, so I can work with the way it is implemented, but I find it counter-intuitive to have to expand a stack to assign ALL images in a stack to one category or keyword.  This is the exact opposite of what other software I've seen does. 

Never-the-less, there's no point in arguing again.  Perhaps an event-driven script could be used to add such a feature for those that want it.  I haven't really looked at scripting, yet, to see if that would be possible. 

[Richard]

I may choose to stack all images taken at the same location. That does not mean that I want all those images assigned to ALL of the same categories.

It has long been Standard Operating Procedure in IMatch that changes are applied only to selected images. I would not want IMatch to change what has been SOP by making exceptions. Especially not exceptions that will not suit my needs, like applying the same categories to all images in a stack. Making an exception to the rule would require yet another option for uses to set. I think that expanding a stack and selecting images so they have the focus and then assigning categories is the best way to go.

[Erik]

I may choose to stack all images taken at the same location. That does not mean that I want all those images assigned to ALL of the same categories.

I don't disagree with that.  But as it is, you'd have to expand the stack to assign each image to the category you want.  But, when you have a stack, there are some categories you intend on being the same throughout the stack.   In your own example, if you had a location category, you'd probably want ALL the images to be in that same location category. 

How often are you going to be assigning a category with the intention of only assigning a category to the top image in a stack and not bothering with any other images in the stack (i.e. without expanding the stack)?  My guess is it wouldn't be very often. 

This is probably the only case where I think Lightroom's DAM features make sense. 

In my opinion a Stack is not a filter and should be thought of independently of a filter, but right now that's basically all it is.  A stack should be a convenient way of collapsing files and representing a group of files without filtering them off.  If I wanted to filter the non-visible images, I would.  But a stack shouldn't have that function.  I feel that if I have no active filters, that should be absolute, but stacks don't make it so.

But, I don't want to rehash this argument any further.  I was obviously in the minority.  And, as I mentioned before, this could probably be scripted (assuming we have access to whether images are in a stack or whether a stack is collpased). 

Aside, I'm not a huge fan of the argument that having an additional option is a reason not to implement the feature in and of itself.  IM has a ton of options.  I highly doubt that one more is going to be a reason someone would not choose IM.  The reason IM works so well is its flexibility, and flexibility does require options. 

[Ferdinand]

Considering the vast number of IMatch users out there, only a handful have expressed their opinions, so we don't really have a reliable guide to what the majority view really is. 

For those that have, whether they support it or not seems to depend on whether this suggestion fits their workflow or not - for some it does and others it definitely doesn't.  Given that it doesn't fit Mario's mental model then change won't happen unless it can be demonstrated that there is a clear majority who want it. 

I've got no great desire to rehash the heated debate of last year, but I would like to get a wider range of views.

F.

[NeilR]

One more opinion...

I intend to use stacking mainly to organize versioned images.  I think that the ability to quickly and efficiently keep the ratings, color codes and/or category assignments consistent among images in a version is critical to the utility of versioning and stacking.  It is the main reason I want to version and stack.

I understand that different people will use stacking in different ways but the app should support the "standard" way already implemented in other  DAM apps, and that is to automate the consistent assignment of these things among versions.  So obviously it has to be tailor-able, or maybe dual options (assign to specific image, and assign to all images within this version).  Or something along those lines.

[Mario]

When you use versioning, categories and other attributes are automatically propagated from the master to its version. This is unrelated to normal stacking.

There is no common behavior among all the standard apps out there, even if they implore a more or less functional form of stacking. I have decided to use the same pattern for all operations in IMatch. When you assign a category, it will be assigned to all visible and selected files in the file window. When you work with regular stacks and these stacks are collapsed, only the top file in the stack can be selected and is visible in the file window. So only this file will get the category assigned. Easy. Once remembered, it works the same everywhere.

You can do a quick <Shift>+<E> to expand the stack, <Ctrl>+<Shift>+<S> to select all files in the stack and then add/remove categories or whatever.

[Schmidtze]

When you assign a category, it will be assigned to all visible and selected files in the file window.

I think that's the point! Honestly I expect all files of the stack to be selected when selecting the stack  But of course it's a matter of taste...

[Mario]

We discussed this for a long time among the Pre-Beta testers and my two "live" groups here in Germany. You can find arguments for both usage patterns when you consider all operations you can perform on files, including working with categories, collections, rating, label etc. A typical example is that you usually put the best shot on top. If you now rate this top image (stack collapsed) with 5 stars, you probably don't expect that all files in the stack get 5 stars as well. The for label, or collections.

Instead of using different workflows for stacked files for categories, rating or metadata assignment, I settled to the schema currently implemented. You can always use version stacks as a replacement or supplement. Version stacks can be collapsed as well, but propagation rules are still applied when you modify the master (including category propagation).

[aloney]

Mario,
I agree that features should apply only to selected files and IM5 should not assume that when I click on an image at the top of a stack that I want to select the entire stack.

Would you consider changing the way Select all files in stack operates to not require that the stack be first expanded? The background color of the stack counter could be changed to indicate all images in the stack are selected. This would help workflows that need to apply a feature to all files in a stack.

If selecting all images in a stack without also expanding the stack is not acceptable, would it at least be possible to allow Select all files in stack to automatically expand and then select instead of forcing two manual steps?

Thank you, AL

[Mario]

As I said, IMatch currently does not load files which are hidden because they are in a collapsed stack. This improves performance considerably and simplifies internal processing. To implement your idea I would have to rip out major parts of the code that controls the file window. Plus changes to the user interface and all that. A lot of effort and nothing I will ponder for several versions at least.

[DigPeter]

Actually, only the top of stack-file gets a category.
I would like to have an option so all files in a stack are affected by category changes if the stack category changes.
Instead of an option, this could also be default behaviour.

I support this, despite all the contrary views.

[Mammut]

I also vote for more stack options.

Maybe there could be more options in the Stacks panel, so we could do more work with the elements of the stack there. This would cause much trouble with the core code?

But I think it would be nice if we could go in the stack, too, so the whole view changes, like a filtered view (with a go back button).

By the way, I found a bug, too: sometimes the stacks are not collapsing, especially when there are more thousands images in the view. The files are not hidden, but IMatch thinks the stack is collapsed, I can't select all images from the stack, it says I need to expand it. I guess it's some performance thing.

[sinus]

For now, I suggest you do a

<Shift><E> to expand the stack followed by a
<Shift>+<Strg>+<A> to select all files in the stack.

When you now assign categories or perform other commands, all files in the stack will be affected.

Maybe, I do not know, does here help also a script, to reduce even this two (in fact three, to close the stack again) key-strokes?!

I would not change this behaviour of IM5, if it is related to a lot of work for you (and could affect other stuff).

[Richard]

By the way, I found a bug, too: sometimes the stacks are not collapsing, especially when there are more thousands images in the view. The files are not hidden, but IMatch thinks the stack is collapsed, I can't select all images from the stack, it says I need to expand it. I guess it's some performance thing.

Bugs should be reported as bugs. Not included in Feature Requests.

[Mario]

All bugs please into the bug report board: https://www.photools.com/community/index.php?board=9.0
I never search feature requests for possible bug reports mentioned in passing.

Besides, the stacks not always collapsing has already been reported:

https://www.photools.com/community/index.php?topic=218.0

Maybe you can add a bit more info there, e.g. under which conditions you see this bug. Every bit of info is welcome.

[Mammut]

I saw that bug report topic after I mentioned it here, that's why I didn't repeat it unnecessary. I skipped a few mentioned bugs already.
But I add my experience then.

[marco88]

I like the option of being able to apply commands (categories for instance) to an entire stack but I do understand the other side of the coin.

What about having a special way of selecting the stack (read key combination) to tell Imatch you want to select all the images in it too?

Would that make the trick and satisfy both sides?

Single click select top image only.

Single click + "a" all selected.

Just a thought.

Cheers
Marc

[Mario]

The file window does not load files hidden in a stack. So it cannot select them, by keyboard or other means.
I would have to revamp the entire file window logig to handle this, introducing special cases all over.

I think the rule "if you cannot see it in the file window, it cannot be selected or modified" is better. Just expand the stack (<Shift>+<E>) if you want to manipulate files within the stack. You can expand all stacks in a file window by <Ctrl>+<A> (select all) and then <Shift>+<E>. To collapse again: <Shift>+<C>. Quite comfy, actually.