Should be easier to make quick edits to multiple images

[xsdg]

Is your feature request related to a problem? Please describe.

Sometimes, I want to make quick changes to small groups of photos. A common example is if I spend 15 minutes taking photos at a track meet with variable light conditions. Then I want to normalize the exposures in darktable. All of the shots in a given burst will have the same ideal exposure settings, but separate bursts will often need different settings.

The current UI for engaging Selective Copy works, but is too heavy for this usecase, and ends up wasting a lot of time. Also, it requires a bunch of fairly precise mouse movements, which makes things even slower.

I show my typical steps below. And keep in mind that I need to run these steps for every edit of every burst in the set. That's a huge amount of time just spent clicking on the exact same things.

1. Set exposure on image 1 of burst 1

2. Hit "l" to return to lighttable mode

3. Potentially scroll so that the history stack "module" is visible in the sidebar

4. Click "selective copy…" at the right side of the screen

5. Click "select none" at the bottom of the dialog, which is in the center of the screen

6. Click the very small "include" checkbox for exposure, at the top of the dialog

7. Click "ok" back at the bottom of the dialog

8. Select the rest of the images in burst 1, at the top of the screen

9. Click "paste" which is a half-screen down and at the far right.

10. Double-click image 1 of burst 2

11. Scroll through modules to get to exposure

12. Set exposure on image 1 of burst 2

Describe the solution you'd like

From a UX perspective, it would help a lot to have a way to perform a simplified Selective Copy from darktable mode. Here are two ways I could imagine that happening:

1. Right click on a history element in the history list, and then click "copy" in a new context menu that pops up.
2. Click the "instance" button above any module, and then click a new "copy" item in the existing context menu that pops up.

Then for the paste side of things, here are some options that come to mind:

1. Switch back to lighttable mode and use the standard "paste" or "selective paste" buttons in the standard way.
2. Right click on single images in the bottom image carousel, and click "paste" in a new context menu that pops up.
3. Click on a new "paste" button that is added to the controls that already show on mouseover for each image in the bottom image carousel. (I don't think this is a great option, but it's still worth mentioning).

Alternatives

Additional context

[ralfbrown]

Faster:

1. while editing the first photo, Ctrl-Shift-C to bring up the selective-copy dialog
2. 1, Select None / click desired module / Copy
3. Ctrl-Shift-A to ensure no images are selected [optional for first batch]
4. Ctrl-Click in filmstrip on first of batch you want to copy to, then Shift-Click on final one
5. Ctrl-V to paste setting
6. Click on image from next batch in filmstrip

[xsdg]

Awesome. I think that already handles the majority of what I wanted out of this proposal.

Does it seem like having a faster way to copy single-module configs would be helpful? Alternately, would it be helpful to have a non-shortcut way to accomplish some of this.

(Lastly, for my own education, is there somewhere I should have looked on my own to learn about selecting images and using selective copy and paste from darktable mode?)

[wpferguson]

The Lua scripting API provides a lot of tools or implementing workflows.

For you specific exposure issue, did you try automatic mode for the exposure module?

[wpferguson]

Some further thoughts

You can set only one module open at a time in preferences to help with the scrolling issue.

You can assign keyboard shortcuts to function such as the history stack copy and paste functions

[ralfbrown]

If you hold down the 'h' key, you'll get a listing of all the keyboard shortcuts available in the current view (lighttable/darkroom/etc), including those you've defined yourself.

Virtually any GUI action can be bound to a keystroke, including not just sliders, buttons, and menu items, but also styles and module presets. You can also define shortcuts which combine keystroke and mouse actions, e.g. hold 'e' and scroll to adjust exposure.

The reason all non-trivial GUI programs have keyboard shortcuts is because they are faster even than a dedicated button on the screen (no need to move the mouse to the button with enough accuracy to actually hit it), never mind an item buried in a submenu.

[xsdg]

@ralfbrown Right, I know why keyboard shortcuts are useful. I think what I'm brainstorming is: I'm a professional photographer, and this has been slowing me down for years. I'm trying to reflect on why that happened, and whether there are any changes that might make sense to help guide users like myself to the faster approach.

I think these are important bits of information that I did not have:

1. I assumed that because the "selective copy" button existed in lighttable mode and disappeared in darkroom mode, that the "selective copy" action was exclusively associated with lighttable mode.
2. Related, I did not know that keyboard shortcuts could trigger actions that did not have other ways to trigger them in the UI.
3. Because clicking in lighttable would select an image, and clicking the filmstrip in darkroom mode would switch to an image, I assumed that there was no way to select other images while in darkroom mode.
4. I didn't realize until filing this bug how much time I spent moving the mouse to trigger the "selective copy" and "paste" actions. Consequently, I had likely previously visually ignored the "shift + ctrl + C" hint in the "selective copy" tooltip, and didn't notice it once it would have become more helpful. Personally, I think I'm more used to the GTK menu-style shortcut hints (which are on the same line as what they trigger), and that pattern would have made it easier for me to "un-ignore" that hint. (Note that this is just an observation; not a recommendation)
5. I did not know about holding "h" to see the list of keyboard shortcuts.

Since this discussion is related to UI affordances, I would offer this as a way for us to make sure we're using the same terminology to discuss how the UI works and what hints it offers to the user: https://www.uxpin.com/studio/blog/affordances-user-interaction/

Using that terminology, I would say that the Darktable UI relies a lot on hidden affordances, and given its UI style, doesn't benefit from a lot of the pattern affordances that users may be otherwise familiar with (from other GTK apps, especially). What's extra challenging is that even the features that are designed to help users get un-stuck are behind hidden affordances (like holding "h").

[xsdg]

And to add to all that, Darktable's selection behavior and targeting of image operations has long been really confusing, and continues to be really confusing. My personal sense is that it would be good to pick some major version to break UI backwards compatibility in order to fix this and make it make sense.

In particular, as related to this topic, it's extremely confusing that the target of the keyboard shortcut actions always follows the mouse, even when the obvious behavior is something else. This is one of the ways that Darktable fails to benefit from the pattern affordances that have been established by selection behavior in other apps. 1) If I select multiple images in the filmstrip, then move the mouse back over the current image, then hit Ctrl+V, that is a no-op, because the target of that action is the current image. 2) If I select multiple images in the filmstrip, then move the mouse over an unselected image, then the target of Ctrl+V is the unselected image that was under the mouse pointer, instead of the images I just selected. This is obviously the wrong behavior (even though it is consistent with Darktable's historical behavior) 3) Only if I select multiple images in the filmstrip, then leave the mouse over some ambiguous area near them in the filmstrip, does the Ctrl+V actually target the images that I wanted to affect.

Then once multiple images in the filmstrip have been selected, the only way to _de_select them is to use a keyboard shortcut. This is a case where Darktable just behaves in a way that is technically consistent by conceptually inconsistent between darkroom mode and lighttable mode. But then if I click on a different image, darkroom mode switches to that other image without clearing the image selection. That is both technically inconsistent and also conceptually inconsistent between darkroom mode and lighttable mode.

[xsdg]

@wpferguson My exposure example was one of a whole bunch of examples. Just yesterday, I needed to tweak rotation, cropping, color calibration, and tone curve.

Also, I think my broader issue (which is out-of-scope for this bug) is that there are a bunch of cases where Darktable scrolls the module pane when I don't want or expect it to.

[ptilopteri]

• Omari Stephens @.***> [04-29-24 16:08]:

  @wpferguson My exposure example was one of a whole bunch of examples. Just yesterday, I needed to tweak rotation, cropping, color calibration, and tone curve.

  Also, I think my broader issue (which is out-of-scope for this bug) is that there are a bunch of cases where Darktable scrolls the module pane when I don't want or expect it to.

set the module pane to: "expand a single processing module at a time"

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[wpferguson]

My personal sense is that it would be good to pick some major version to break UI backwards compatibility in order to fix this and make it make sense.

And that would destroy my workflow as well as that of many others.

I've been using darktable since 1.6.x. For years I didn't know about the hovering because I clicked on the image, then moved into the panel and clicked on the operation. Since I wasn't over an image, it was never a problem.

Then I saw a discussion about the hovering and decided to try it and see what all the fuss was about. I learned, after some experimentation, that it was MUCH faster to use hover and keyboard shortcuts to speed up my workflow. The mouse clicks were just slowing me down.

I think these are important bits of information that I did not have:

Did you read the manual? Meaning, did you read the manual and it didn't make sense, or you hadn't used darktable enough for it to make sense, or did you skip reading the manual and try and figure it out on the fly (that's what I did :smile:)?

[TurboGit]

What could be done maybe is to have a synchronize from darkroom.

• Select a bunch of image
• Do a change on the first selected
• Do a synchronize to all selected images

That is the "do synchronize" action takes the last edited module and apply it to all selected images.

This new action could be activated with "ctrl+shift+s" or whatever.

@xsdg : How does that sound ?

[xsdg]

My personal sense is that it would be good to pick some major version to break UI backwards compatibility in order to fix this and make it make sense.

And that would destroy my workflow as well as that of many others.

I've been using darktable since 1.6.x. For years I didn't know about the hovering because I clicked on the image, then moved into the panel and clicked on the operation. Since I wasn't over an image, it was never a problem.

Then I saw a discussion about the hovering and decided to try it and see what all the fuss was about. I learned, after some experimentation, that it was MUCH faster to use hover and keyboard shortcuts to speed up my workflow. The mouse clicks were just slowing me down.

I think there's a solution where these workflows coexist and don't conflict, but that's not achieved by the current implementation. The following is one idea of how this could work, but this should count more as "brainstorming" than as the right solution.

1) I think if the user doesn't even try to select images (which I presume would be the case for your workflow), then it makes sense to have actions always and only ever target the image that the mouse is hovering over. That said, the lighttable has a default behavior of always having a "current" image unless the user actively deselects it. I think the "always target hovered image" workflow would be even clearer and easier to reason about if that weren't the case — there is no default selected image, and images are only ever selected by hand. If you double-click an image to enter darkroom mode, that act doesn't automatically cause that image to be selected. And when you return from darkroom mode to lighttable mode, no image is selected. And then, if you do choose to single-click on an image to select it (or ctrl-click to multi-select or whatever), that automatically switches you to a different workflow mode.

2) The second workflow mode is where the selected images are always the only targets for every action. Hover state is completely ignored in this mode. So if multiple images are selected, they are the targets. If one image is selected, that is the target. Peak consistency would be for no actions to happen when zero images are selected, but that would mean there would need to be another way to transition back to workflow mode 1 (hover to target).

Mentally, I think the current implementation is really confusing because there's no clear notion of "inactive" versus "active" places for the mouse to be. People like me who never intend to use hovering as a targeting approach end up having to jump through lots of hoops in order to have darktable always behave as expected (for me, I specifically try to place my mouse between the images in the lighttable grid. This wastes a lot of time). I suspect that it's just as confusing for hover users, because if they miss the hover target even by a tiny bit, then an action will happen to target the default-selected image, which might not even be visible on the screen if the user has scrolled away from it. So for me, it feels like the current implementation is kind of the worst of both worlds in terms of behaving predictably.

I think these are important bits of information that I did not have:

Did you read the manual? Meaning, did you read the manual and it didn't make sense, or you hadn't used darktable enough for it to make sense, or did you skip reading the manual and try and figure it out on the fly (that's what I did 😄)?

I've been using Darktable for 13 or 14 years (since pre-0.9), and I don't periodically reread the manual 🤷. I care a lot about how selection works in part because it's one of the first parts of darktable that I had worked on. I remember when I first encountered selective copy, and it seemed pretty intuitive to use. So I just used it, and I developed inferences around how it worked based on how the UI worked around it.

That's why (again, using the terminology from that link) affordances and signifiers are so important. Because no user is going to be a perfect expert in how the UI behaves, and the UI should work to help users improve over time, not to cause them to suffer when they don't know what they don't know. I feel like the UI does a very good job of offering hints about details — the tooltips on everything have helped me become significantly better at using darktable as things have changed over the years. And the version selectors for things like module order or filmic color science let me know when there are new, breaking changes that I should consider trying out. But I think there's still an opportunity for it to do a better job of teaching users the broader patterns that they might not be aware of.

[xsdg]

@TurboGit Just to make sure I'm following, it sounds like synchronize would mostly just be selective copy + auto-select top item + some form of paste. I think that would be handy, but I'm not sure it's worth introducing a whole new concept for it. If there's a creative way to make it just a specialization of selective-copy (maybe "selectively copy last modification") and you could set a keyboard shortcut for it, I think that would be close to perfect for my particular usecase, and would hopefully avoid complicating things more than necessary.

In the time since @ralfbrown's response, I've been using that workflow extensively (hundreds of images) and it works really well for my needs. The example I offered (needing to match exposures) is more simplistic than my actual needs, which are more like the following for a 10-image sequence: "okay, set the white balance, then paste it across a few images. Oh, it looks like some clouds moved in, so I need to alter the white balance and paste it back two to three images in addition to forward for 4 more images. Wait, the clouds went away again, so I need to copy the initial white balance and paste it onto the final image in the sequence." Likewise with corrective image rotation, which I'll often do as a separate pass of modifications.

[wpferguson]

for a 10-image sequence: "okay, set the white balance, then paste it across a few images. Oh, it looks like some

This is similar to a timelapse workflow. If a timelapse processing solution existed, would that work for you?

[xsdg]

@wpferguson I'm not familiar with time lapse post-processing, so it's hard for me to comment on. That said, I think the challenges one would encounter with a time lapse wouldn't fully capture the challenges I tend to encounter.

Here's a very specific example of a usecase of mine, just to illustrate the combination of photo volume and chaos that I regularly need to manage. Also, consider that I shoot with two bodies with zoom lenses, so all settings can change pretty rapidly, and the two lenses might render colors slightly differently, which is something else I'll end up needing to account for. The following is a (very small) subset of photos from a track meet I photographed recently:

You can see how there's more consistency in consecutive images (vertical dimension) but very little consistency across larger periods of time (horizontal dimension). But even among consecutive images, just left of center, you can see one athlete jumping from the shade (one white balance) to the sun (a different white balance) and landing back in the shade again (original white balance). If a person turns from facing towards the sun to away from the sun, that's a different white balance. If they run past me towards the sun, that's different white balance, different crop, and a lot of times different corrective rotation in case my sense of horizon got off as I was panning. And because of the bright red track surface, bright green grass and trees, and bright blue sky, AWB usually doesn't work very well.

I'm not delivering all of these particular images by any stretch of the imagination. But the challenges illustrated here are a pretty good representation of the challenges that I actually do face within a given set of images. And I've delivered plenty of 80+-image sets before.

[wpferguson]

Timelapse processing is basically selecting a start and end image for a set (key frames), adjusting them, then applying a process to incrementally adjust the set to have a smooth transition from one key frame to the other.

The exposure module offers an exposure mapping mode where you select an area of an image (say the red track) and apply that to the red track in the other images. There is also a color mapping mode in color calibration to adjust colors.

[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.

[Solarer]

I also thought that it would be nice if I could apply my edits to multiple images without the need to hit the combo of Ctrl-C and Ctrl-V (sometimes with or without shift modifier) while taking care to hover the right image during copy and the right image during pasting.

When I edit my pictures I can see well in advance via filmstrip that the next X images have the same conditions and that I will copy and paste my edits to them once I am through with the first image of the sequence. It would be awesome if all I had to do was select these X images and start working on one of them and the edits would be propagated automatically to the rest.

I would probably leave this setting always on and only use copy and paste for some manual adjustments or corrections.

[Solarer]

@xsdg

And to add to all that, Darktable's selection behavior and targeting of image operations has long been really confusing and continues to be really confusing.

I am working on an alternative implementation that addresses your complaints but it will take more time before it is ready. If you want, you can have a look here #16850. There are other related issues linked within that one.

[ralfbrown]

It would be awesome if all I had to do was select these X images and start working on one of them and the edits would be propagated automatically to the rest.

That would require considerable re-architecting, since a parameter commit in a module could affect arbitrarily many images, not just the one showing in the center view. And then there's the issue of whether parameter changes in the "other" images should be absolute or relative.

[ptilopteri]

• Jan Kaufmann @.***> [07-23-24 14:41]:

  I also thought that it would be nice if I could apply my edits to multiple images without the need to hit the combo of Ctrl-C and Ctrl-V (sometimes with or without shift modifier) while taking care to hover the right image during copy and the right image during pasting.

  When I edit my pictures I can see well in advance via filmstrip that the next X images have the same conditions and that I will copy and paste my edits to them once I am through with the first image of the sequence. It would be awesome if all I had to do was select these X images and start working on one of them and the edits would be propagated automatically to the rest.

  I would probably leave this setting always on and only use copy and paste for some manual adjustments or corrections.

consider hovering above an image on lighttable and rolling the mouse wheel to increase/decrease the number of images displayed to determine which images you need to select to apply the "edit copy".

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[ptilopteri]

• Jan Kaufmann @.***> [07-23-24 14:41]:

  I also thought that it would be nice if I could apply my edits to multiple images without the need to hit the combo of Ctrl-C and Ctrl-V (sometimes with or without shift modifier) while taking care to hover the right image during copy and the right image during pasting.

  When I edit my pictures I can see well in advance via filmstrip that the next X images have the same conditions and that I will copy and paste my edits to them once I am through with the first image of the sequence. It would be awesome if all I had to do was select these X images and start working on one of them and the edits would be propagated automatically to the rest.

  I would probably leave this setting always on and only use copy and paste for some manual adjustments or corrections.

addendum:

consider hovering above an image on lighttable and rolling the mouse wheel while holding to increase/decrease the number of images displayed to determine which images you need to select to apply the "edit copy".

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[Solarer]

That would require considerable re-architecting, since a parameter commit in a module could affect arbitrarily many images, not just the one showing in the center view.

I was thinking: apply the module to all selected images with a delay. Start once another module is used or once a new images is put in focus (to avoid applying the changes every time a slider is moved which would probably freeze darktable). Does it make it easier to apply the module with such a delay instead on every change within a module?

And then there's the issue of whether parameter changes in the "other" images should be absolute or relative.

I was thinking relative. In which situation would that be a bad idea? Sorry, I am obviously not familiar with the code in question...

consider hovering above an image on lighttable and rolling the mouse wheel ...

Is that an alternative way to select images? I am fine with the selection step. I was asking about a way to automate the copy and paste with the key bindings since most of the time it will be "everything I just did" to "all the images that are selected"

[ptilopteri]

• Jan Kaufmann @.***> [07-23-24 18:17]:

  That would require considerable re-architecting, since a parameter commit in a module could affect arbitrarily many images, not just the one showing in the center view.

  I was thinking: apply the module to all selected images with a delay. Start once another module is used or once a new images is put in focus (to avoid applying the changes every time a slider is moved which would probably freeze darktable). Does it make it easier to apply the module with such a delay instead on every change within a module?

  And then there's the issue of whether parameter changes in the "other" images should be absolute or relative.

  I was thinking relative. In which situation would that be a bad idea? Sorry, I am obviously not familiar with the code in question...

  consider hovering above an image on lighttable and rolling the mouse wheel ...

  Is that an alternative way to select images? I am fine with the selection step. I was asking about a way to automate the copy and paste with the key bindings since most of the time it will be "everything I just did" to "all the images that are selected"

select an image you are satisfied with the edits copy the "pertinent" edits select images you wish to apply the same edit(s) append the "copies",

not a lot of work. and no coding necessary

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[ralfbrown]

Having a delay makes the code more complicated. Using relative adjustments is not a bad idea, but is more complicated - you need to track the previous value, and for some settings the change is best expressed as a percentage of the previous values (most anything where effects are nonlinear without having an explicitly nonlinear scale like EV) while for others it is best to use absolute differences (most anything using EV or a linear scale with linear effects). Plus the relative change could cause the setting in one of the other images to hit the hard limit for the parameter and thus appear to have no effect.

[Solarer]

Interesting. I did not think about non-linearities and wonder if it can even be done in a relative way. There are also tone curves that extrapolate between the markers and probably some non-symmetric functions. Calculating and applying the right delta might be impossible.

Absolute values work if the user makes sure to create a fresh instance of the module. In that case what ever changes are done in the fresh module instance could be copied one-to-one to all other images.

[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.

[TurboGit]

@xsdg : See #17589 it was trivial to add a synchronize action and makes the life easier. You can keep one hand on the keyboard doing ctrl+x from time to time while editing a picture.

[TurboGit]

PR merged, closing.