Relations, Versions and stacking: propagation automatically?

[sinus]

Folks, sorry,
I have two questions/problems, what are discussed here, I am quite sure. But I cannot find it anymore.

Hence they are silly questions, but I cannot find a solution quite now.

1) In the version-preferences I have enabled to propagate Attributes, dots and more. When I create a version (LR), then IM does detect it, but does not propagate dots, attributes.
But if I manually propagate them, everythink works as expected.
Is this normal, that IM does not propagte a new version automatically, though propagation is enabled?

2) If I collapse a version stack and a normal stack, say with 10 images, I have only one image on top (BTW: works fine).
When I now do change categories, dots, pins and so on this top-image, then this has only an effect on the top-image, not on all of the 10 images.
Is it possible to enable, that collapsed images (version stack, normal stacks) does also have the same changings like the top - image?

Again sorry, I know, we have discussed this once (specially the question 2), but my brain is helpless at the moment. 

[Ferdinand]

1) In the version-preferences I have enabled to propagate Attributes, dots and more. When I create a version (LR), then IM does detect it, but does not propagate dots, attributes.
But if I manually propagate them, everythink works as expected.
Is this normal, that IM does not propagte a new version automatically, though propagation is enabled?

Propagation only occurs automatically when you change something for the master (and if writeback is enabled), or if you issue a manual propagation command, e.g.. F4,P (which will execute any pending writebacks if writeback is not enabled).   So propagation will not occur automatically if you add a new version. 

Moreover, if you perform a manual propagation, it will propagate to all versions, not just the new one.  I have a feature request to be able to select some versions and only propagate to them, not to all versions.

2) If I collapse a version stack and a normal stack, say with 10 images, I have only one image on top (BTW: works fine).
When I now do change categories, dots, pins and so on this top-image, then this has only an effect on the top-image, not on all of the 10 images.
Is it possible to enable, that collapsed images (version stack, normal stacks) does also have the same changings like the top - image?

This has been hotly debated.  Some really want it, some really don't.  Mario is very much against it, because it's not how he has designed V5 and it would be a lot of work.  I hope you are wearing a flame proof suit.  See this thread for example.

[Richard]

Mario is very much against it, because it's not how he has designed V5 and it would be a lot of work.

My feeling is that Mario is against it because it would not comply with the rule that changes are made to selected files only.

[sinus]

1) In the version-preferences I have enabled to propagate Attributes, dots and more. When I create a version (LR), then IM does detect it, but does not propagate dots, attributes.
But if I manually propagate them, everythink works as expected.
Is this normal, that IM does not propagte a new version automatically, though propagation is enabled?

Propagation only occurs automatically when you change something for the master (and if writeback is enabled), or if you issue a manual propagation command, e.g.. F4,P (which will execute any pending writebacks if writeback is not enabled).   So propagation will not occur automatically if you add a new version. 

Moreover, if you perform a manual propagation, it will propagate to all versions, not just the new one.  I have a feature request to be able to select some versions and only propagate to them, not to all versions.

2) If I collapse a version stack and a normal stack, say with 10 images, I have only one image on top (BTW: works fine).
When I now do change categories, dots, pins and so on this top-image, then this has only an effect on the top-image, not on all of the 10 images.
Is it possible to enable, that collapsed images (version stack, normal stacks) does also have the same changings like the top - image?

This has been hotly debated.  Some really want it, some really don't.  Mario is very much against it, because it's not how he has designed V5 and it would be a lot of work.  I hope you are wearing a flame proof suit.  See this thread for example.

Ferdinand,
thanks a lot, you helped me a lot with your answers, in both cases.
Well, in this case, I do not more argue, because with simply some clicks, I can do, what I want.
And finally we have scripting, not now, but I guess later, I will be able to create some scripts (or change some from users) to get, what I want.
Thanks really!

[sinus]

Mario is very much against it, because it's not how he has designed V5 and it would be a lot of work.

My feeling is that Mario is against it because it would not comply with the rule that changes are made to selected files only.

Richard, thanks also.
One argument from Mario, that the hidden images are not even loaded, makes sense to me, since I have in mind, to work with a lot of stacks (every stack with about 50-300 images), the performance is important to me.

So, the line of Mario is ok for me.

[sinus]

I hope you are wearing a flame proof suit.  See this thread for example.

This is for my swiss ears quite funny to read and hear. 

[Ferdinand]

Mario is very much against it, because it's not how he has designed V5 and it would be a lot of work.

My feeling is that Mario is against it because it would not comply with the rule that changes are made to selected files only.

A slightly more detailed version of what I meant is that this is a design principle that he has used, and he has implemented this design principle in such a way that it would be a lot of work to change it. 

The point of contention is whether or not in selecting a collapsed stack you have selected all the images in the stack or just the top one.  Some people, including me, naturally think that you've selected all of them.  Others, especially Mario, think not.  So it's partly a philosophical issue, and partly an implementation issue.

@Sinus, the point about propagation to a new version is similar.  Mario designed propagation to be triggered automatically when changes are made to the master.  To trigger propagation automatically when changes are made to other files would generate a lot of activity.  I don't have a problem with this, but I think the same principle is true in the case where you add a new version.  If you manually trigger propagation because you added a new version, then there is a lot of unnecessary activity, because all versions are propagated to, when only the new one needs it.  Hence my feature request.

[Richard]

The point of contention is whether or not in selecting a collapsed stack you have selected all the images in the stack or just the top one.

Let's say that I have a file, 12345.tif, that shows Tom. Dick, and Harry. From this image I crop separate files for each person and label them: 12345T.tif, 12345D.tif, 12345H.tif. I use 12345.tif as the top of the stack and put the other 3 files under it. I have new information about Dick and want to add it to 12345.tif and to 12345D.tif. Under the current method I expand the stack and select 12345.tif and 12345D.tif and add my information to both.

Under the system you would like, how would I select only 12345.tif and 12345D.tif if clicking on 12345.tif selects all four files?

[Ferdinand]

The point of contention is whether or not in selecting a collapsed stack you have selected all the images in the stack or just the top one.

Let's say that I have a file, 12345.tif, that shows Tom. Dick, and Harry. From this image I crop separate files for each person and label them: 12345T.tif, 12345D.tif, 12345H.tif. I use 12345.tif as the top of the stack and put the other 3 files under it. I have new information about Dick and want to add it to 12345.tif and to 12345D.tif. Under the current method I expand the stack and select 12345.tif and 12345D.tif and add my information to both.

Under the system you would like, how would I select only 12345.tif and 12345D.tif if clicking on 12345.tif selects all four files?

I can't see that making all the files in the stack selected if the stack was selected would change anything in your example.  At present, if you want to edit metadata for two files in the stack then you have to expand the stack and select those files, because if you select the stack and make the change it only applies to the top file.  If instead all the files in the stack were selected, then you'd still need to expand the stack and select those two files, because you don't want to apply the change to all the images in the stack.  So I can't see that there's any change in this example.

The current system suits people who only want to change metadata for the top file.  I think that this approach suits Ben's workflow.  It doesn't suit people who want to apply metadata changes to all files in the stack - they have to expand and select and change and collapse.  If the behaviour of stacks was changed then those who only want to edit the top file would be the ones who need to expand - select - edit - collapse.  So the question is, what is the majority preference?  We don't know - only a few people with strong opinions have commented. 

And Mario says that it's a major change, so whatever the majority view is, any change is a long way off, if ever.

[sinus]

The current system suits people who only want to change metadata for the top file.  I think that this approach suits Ben's workflow.  It doesn't suit people who want to apply metadata changes to all files in the stack - they have to expand and select and change and collapse.  If the behaviour of stacks was changed then those who only want to edit the top file would be the ones who need to expand - select - edit - collapse.  So the question is, what is the majority preference?  We don't know - only a few people with strong opinions have commented. 

And Mario says that it's a major change, so whatever the majority view is, any change is a long way off, if ever.

Here I agree with Ferdinand completely.
If I could choose, I would choose, that a click on the top-image and a change there would affect all hidden stack-files.
Because mostly i want the same changings to all member of the stack.

It is simply, I think, also a matter of personal point of view.
For example, I have a raw-image (master) and a version. And say, I do set a green dot, if I have delivered this image to a client.

So, now I deliver the image to a client, but (mostly) of course not the raw-image, but the version.

Now, the version gets now a green dot. The question is now, should the master have also a green dot?
To be precise, of course not, because I have delivered only the version.
On the other side, for example, if I have the version-stack collapsed and the master is the top of view, I would not see, that the version is delivered, because the master has no green dot.

In the collapsed system, it would be better (for me), that the master has also a green dot. Then I can see, a this image has been delivered and (usually) I know of course, that I do not deliver raws, but versions.

I think, in such a scenario (delivered could also mean edited, used in a slideshow, or what ever) one person does like it so and the other likes it the other side. (ahhh, sorry, my english  )

But if a changing is such a big thing for Mario, then I can of course live with it is now. I thought only, I make something wrong, but now, I know, how it works and what I can do.

Thanks to all.

[Mario]

The general idea in IMatch is: "You operate on the selected files".

Files hidden in a stack cannot be selected and thus are, by definition, not affected by any change you make or command you perform.
To manipulate files not visible in the file window, you need to make them visible. If you filter out files, disable the filter so you can select the files. If you hide files in a stack, expand the stack so you can see the files and select them.

The current working mode gives uses good control over which operations they perform on which files. File not visible? Cannot be modified. A 'learnable' rule.

Adding a mode where operations performed or commands run on the top of a stack can be added of course. This would be good for users who always want to manipulate all files in a stack as "one". Naturally, for many commands this may cause problems. And IMatch would have to load the files usually not loaded when a stack is collapsed. Which can cause problems by itself, for example if a filter is active. Should IMatch load all files in the stack regardless of the filter? Or just load the files in the stack not currently hidden by the filter? Will users be able to tell or will this cause extra confusion?

A stack can of contain files from multiple folders, categories or collections. Depending on the command a user executes and where in IMatch he executes that command, additional complexity may result from this fact. And a potential danger to manipulate, move or delete 'unexpected' files. Since you cannot see the files, you may not be able to understand what you are doing. Or you may notice that you modified the wrong files when it's too late...Tricky.

As said, I have though about this, and quite a number of other potential problems and pitfalls, and then decided to stick to the simple rule: "You operate on the selected files". Files hidden under a stack are not loaded, not visible, not selectable and thus non-mutable.

I'm not adverse to change this entirely in the future, or add a couple of options like "Always open all files in a stack in the Viewer". But generally, I prefer a understandable, learnable modus operandi in this context.

[Richard]

If instead all the files in the stack were selected, then you'd still need to expand the stack and select those two files, because you don't want to apply the change to all the images in the stack.

In my example you would not be able to select only the image that is the top of the stack because click on that image selects all images in the stack.

The point of contention is whether or not in selecting a collapsed stack you have selected all the images in the stack or just the top one.

Would you have clicking on the top image do one thing when the stack is collapsed but do something else if the stack is expanded?

[Erik]

If instead all the files in the stack were selected, then you'd still need to expand the stack and select those two files, because you don't want to apply the change to all the images in the stack.

In my example you would not be able to select only the image that is the top of the stack because click on that image selects all images in the stack.

The point of contention is whether or not in selecting a collapsed stack you have selected all the images in the stack or just the top one.

Would you have clicking on the top image do one thing when the stack is collapsed but do something else if the stack is expanded?

I think when it comes to stacking when people only want to work with an individual file or two in say a large stack, it won't matter what the top behavior is, you'll have to expand the stack and select those individual files.

I think the what happens when the top file is selected on a collapsed stack is probably a 50-50 thing and I haven't seen much to suggest people feel that strongly about it outside the older discussions.  I know I'm in favor of the selecting the top essentially selects the whole stack or operating on the top operates on the whole stack approach (when it's collapsed) that Ferdinand (or someone else) had described and perhaps requested. I think in that type of environment (which Lightroom uses), selecting the top image selects the whole stack while it's collapsed. But, when the stack is expanded, then only the top photo is selected if you select that particular photo, which I think all software with stacking does in that case.

I understand Mario's reasoning for the method use, and I can see where the method implemented can be important.  I think it ends up a function of how people use stacks and the scope they use them for.  As it is, I don't really use stacks much other than for panoramas and HDR components.  I suppose in many of those cases, once I'm done with most of the metadata aspects of the image, most anything else I do would want to be on the top image anyway, so the current implementation would probably work better for me at a finished level of my DB than at the initial DAM implementation stage.

Not being one to script much, I haven't really looked at scripting in IM5 as it's not something I am terribly comfortable with for any software or environment.  However, I would suspect that scripting could perhaps be used to get the type of effect I'd like for automatic propagation assuming that no matter how convoluted it may be, that one can somehow find the photos that are in a stack if the stack is collapsed.  Perhaps at the worst one has to iterate through the whole database or perhaps the methods are there to identify the photos in a stack more quickly (similar to Ferdinand's versioning script back in 3.6).  If it isn't there, perhaps a way to quickly find how many and all the photos in a collapsed stack via a scripting object would be an easy or achievable request. 

I'll have to look into scripting more closely here.  I've never been a fan of it, but from the examples, I like how it works with IM5 in general. 

[aloney]

The general idea in IMatch is: "You operate on the selected files".

Files hidden in a stack cannot be selected and thus are, by definition, not affected by any change you make or command you perform.
To manipulate files not visible in the file window, you need to make them visible. If you filter out files, disable the filter so you can select the files. If you hide files in a stack, expand the stack so you can see the files and select them.

The current working mode gives uses good control over which operations they perform on which files. File not visible? Cannot be modified. A 'learnable' rule.

Adding a mode where operations performed or commands run on the top of a stack can be added of course. This would be good for users who always want to manipulate all files in a stack as "one". Naturally, for many commands this may cause problems. And IMatch would have to load the files usually not loaded when a stack is collapsed. Which can cause problems by itself, for example if a filter is active. Should IMatch load all files in the stack regardless of the filter? Or just load the files in the stack not currently hidden by the filter? Will users be able to tell or will this cause extra confusion?

A stack can of contain files from multiple folders, categories or collections. Depending on the command a user executes and where in IMatch he executes that command, additional complexity may result from this fact. And a potential danger to manipulate, move or delete 'unexpected' files. Since you cannot see the files, you may not be able to understand what you are doing. Or you may notice that you modified the wrong files when it's too late...Tricky.

As said, I have though about this, and quite a number of other potential problems and pitfalls, and then decided to stick to the simple rule: "You operate on the selected files". Files hidden under a stack are not loaded, not visible, not selectable and thus non-mutable.

I'm not adverse to change this entirely in the future, or add a couple of options like "Always open all files in a stack in the Viewer". But generally, I prefer a understandable, learnable modus operandi in this context.

When I think of a stack, I think of it as a single object and all actions should occur to that single object. If I want to treat the items in that stack individually, I would break the stack apart for that purpose and then restack. Since that is not the design in IM, I won't be using stacks; they have no value to me. Simply hiding them can already be done with filters.

[sinus]

However, I would suspect that scripting could perhaps be used to get the type of effect I'd like for automatic propagation assuming that no matter how convoluted it may be, that one can somehow find the photos that are in a stack if the stack is collapsed.  Perhaps at the worst one has to iterate through the whole database or perhaps the methods are there to identify the photos in a stack more quickly (similar to Ferdinand's versioning script back in 3.6).  If it isn't there, perhaps a way to quickly find how many and all the photos in a collapsed stack via a scripting object would be an easy or achievable request. 

I'll have to look into scripting more closely here.  I've never been a fan of it, but from the examples, I like how it works with IM5 in general.

Erik, yes, I think, scripting can do a lot.

[sinus]

When I think of a stack, I think of it as a single object and all actions should occur to that single object. If I want to treat the items in that stack individually, I would break the stack apart for that purpose and then restack. Since that is not the design in IM, I won't be using stacks; they have no value to me. Simply hiding them can already be done with filters.

I think, filtering things is fine.
But the possibilities, what stacks does offer, is quite great for me. It saves simply space. If I made 10 different locations-shootings, I can have on the window say, 1000 images (10 x100) or, each location stacked, simply 10 thumbs on screen, and because I can choose the top-screen, I can truly remember, what is behind the stack.

Stacking FOR ME will be a great thing of IM5.

[Ferdinand]

First, can I say that I'm not asking for a change at the moment.  The most important thing that can happen is for Mario to squash enough of the remaining bugs that he is able to get V5 into public release that we can all buy a copy (two copies in some cases).  I'm only responding to questions and comments.

In my example you would not be able to select only the image that is the top of the stack because click on that image selects all images in the stack.

That's right, but I can't see how that relates to your example.   In your example, you've got a stack of four files and you want to change information for two of them.  No matter whether selecting a stack selects just the top file or all files in the stack, in your case you're going to have to expand the stack and select those two files in order to change information for those two files and not the other two.

Would you have clicking on the top image do one thing when the stack is collapsed but do something else if the stack is expanded?

If the stack is expanded, then you can't select the stack, can you?  You can only select individual files.  I can't see an easy way to select all the files in the stack when it's expanded.  If the stack is expanded you select individual files. If the stack is collapsed then you select the stack.

Which is my point.  My view is that selecting a collapsed stack should be different to selecting one individual file.  I think that this behaviour - selecting a stack selects all images - is the most intuitive for most users.  Which is why this issue keeps coming up time and time again, and it will only increase once Imatch 5 is in commercial release. 

[Richard]

It seems to me that the top image of a stack must be selected one way as a stack and different way as a separate image. Maybe even a third way when the stack is expanded. Simply clicking on the top image can't work as the only means of selecting unless everybody has the same goal in mind when they select the image that represents a stack.

Ferdinand posted while I was writing my post.

If the stack is expanded, then you can't select the stack, can you?

It seemed to me that is what you were asking for. That clicking on the top image would select the entire stack.

[Ferdinand]

Ferdinand posted while I was writing my post.

If the stack is expanded, then you can't select the stack, can you?

It seemed to me that is what you were asking for. That clicking on the top image would select the entire stack.

We may have been speaking about different things, or using different terminology.  My suggestion has been that if the stack was collapsed, so that only the top file is visible and the other files in the stack are hidden behind it, then selecting the stack by selecting the top image would select all images in the stack.  This is not what happens at present. 

If the stack is expanded, so that you can see all the files in the stack separately, or at least all the files in that particular scope (folder, category, etc), then you select them as individual files.  There is no stack behaviour if the stack is expanded.  This is current behaviour and I'm not suggesting any change.