with multiple instances of an effect, the lowermost one expands incorrectly on change of image

[douzzer]

Describe the bug

If an image is set up with multiple instances of an effect, and a later (visually higher) instance is expanded, or indeed if all of the instances are expanded, and then the image is changed to another one with the same multiple instance configuration, only the earliest (visually lowermost) instance is expanded.

Note the earliest instance is expanded even if it was not expanded in the previous image. I.e., if any instance is expanded in the first image, then the earliest instance will be expanded in the second image, and only the earliest instance.

Steps to reproduce

1. Duplicate the "exposure" effect on an image with right-mouse-button on the "multiple instance actions" widget.
2. Duplicate it again. Now there are 3 instances.
3. Type Control-D while hovering over the thumbnail for the image, to create a duplicate image with this configuration.
4. Use Shift-left-mouse-button on the upper and/or middle exposure instance to expand it.
5. Change to the duplicate image. The lowermost instance will be expanded, and the upper and middle will be minimized.

Expected behavior

Darktable should do with multiple instances what it does with single instances: if an effect is expanded in darkroom for the previous image, and it exists in the next image, it should remain expanded after switching to the next image. Similarly, minimization should carry through to the next image.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you install darktable from?

distro packaging

darktable version

4.4.2 release

What OS are you using?

Linux

What is the version of your OS?

Gentoo

Describe your system?

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[dterrahe]

This is not an unreasonable request and in the straightforward case you describe, where basically two images have the same set of modules in the same order it would be clear (but still not trivial, due to how this data is structured internally) what could be implemented. But if there are slight differences it all becomes muddled quickly and people might get disappointed in their expectations.

For example what if you added another instance in the duplicate. You'd say just keep them expanded in the same order, but what if they are named/based on presets and it looks like this: Image A: exposure 1: preset X, exposure 2: preset Y Image B: exposure 1: preset X, exposure 2: preset Z exposure 3: preset Y If in A you had exposure 2 expanded, after switching to B you'd want exposure 3 expanded, right? We could try to match names, but what if they were not named or based on preset but still identical? We would have to match on all parameters? Pick which one is "closest"? Just use the module order? Add a bunch of settings to preferences to select which behavior each individual user prefers?

All just to say that if someone picks up this bug report and tries to improve the situation, please be kind to them and understand that they'll probably not be able to make you happy in all situations and "unexpected" stuff will continue to happen.

[douzzer]

Yup I had exactly the same thoughts about it -- that as soon as there isn't a 1:1 mapping of instances between the two images, someone's gonna be surprised/disappointed. So best to control expectations.

As for what "1:1 mapping" means, I think it has to just mean same effect name and instance number, ignoring preset name and settings. That makes it easy to understand+explain, and I hope easy+cheap to implement. And, no small thing, when someone is inevitably surprised by the "wrong" effect being expanded after switching to an image with different instance count, it's easy to explain to them why the behavior they're seeing is expected.

Fortunately this is just a matter of which effects are expanded in the UI, not of the actual computations performed by the pipeline.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[douzzer]

This behavior is still there and still mildly annoying...

(just bumping the issue)

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.