Project

General

Profile

Feature #8968

Actions are not applied to all grouped images when collapsed

Added by Rick Gabriel about 7 years ago. Updated 4 months ago.

Status:
Triaged
Priority:
Medium
Category:
Lighttable
Start date:
10/02/2012
Due date:
% Done:

20%

Estimated time:
Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When viewing images shot in RAW+JPG, the new automated grouping of the images is very nice. However, when reviewing images with groups collapsed, it would be nice for rating and meta information to be applied to both the CR2 and JPG simultaneously. For example, marking the group as rejected should apply to both images. Currently, marking a collapsed group as rejected only seems to affect the raw. When expanded, the JPG is not flagged as rejected. This feature would make it easier for those who shoot in RAW+JPG.

reject_group.lua (964 Bytes) reject_group.lua Reject all selected and grouped images at once Thibault Jouannic, 12/30/2015 06:43 PM
rate_group.lua (3.03 KB) rate_group.lua applying a rating (or rejection) to all images within a group hxy io, 12/31/2015 06:13 PM
group_leader_rating.lua (1.05 KB) group_leader_rating.lua Jörg Mensmann, 07/09/2016 08:03 PM

Related issues

Related to darktable - Bug #10099: Rejecting group head hides other group memberNew09/06/2014

Related to darktable - Bug #11382: Copy local only copies group headNew12/22/2016

Has duplicate darktable - Bug #10663: Darktable should attach tag to all images in the selected groupDuplicate10/12/2015

History

#1 Updated by Rick Gabriel about 7 years ago

If my suggestion doesn't work for you, I'm just looking for some method of dealing with RAW+JPG files without going through each individually. ASP combines them into a single thumbnail and operations happen on the RAW only I think.

#2 Updated by Simon Spannagel about 7 years ago

  • Affected Version set to git development version
  • % Done changed from 0 to 20
  • Status changed from New to Triaged
  • Subject changed from Apply tags to all grouped images when collapsed to Tags are not applied to all grouped images when collapsed
  • Tracker changed from Feature to Bug

Good catch, Rick.

I would even say this is not a feature request but a bug. And most likely it#s not only tags but everything else, too that workds with selection.
If groups are collapsed and I select one group all contained images should be "selected" and actions should work in all of them (deleting, assigning tags, ...)

Tobias, what do you think?

#3 Updated by Tobias Ellinghaus about 7 years ago

Yes, I know that this functionality is missing. I was too lazy to code it.

#4 Updated by Tobias Ellinghaus about 7 years ago

  • Target version set to Candidate for next minor release
  • Assignee set to Tobias Ellinghaus

#5 Updated by Simon Spannagel about 7 years ago

  • Subject changed from Tags are not applied to all grouped images when collapsed to Actions are not applied to all grouped images when collapsed

Changed the title. This also affects things like dragging an image group onto the map.

#6 Updated by Tobias Ellinghaus about 7 years ago

  • Status changed from Triaged to Incomplete

I am no longer convinced that this is a good idea. If you group several images (for example bracketed shots + the generated HDR) only some images might justify a high star rating while the source images should be unstarred. The same applies when you use color labels to mark images that are to be exported.

#7 Updated by Rick Gabriel about 7 years ago

That's a good point. My main goal is to be able to deal with shots taken in RAW+JPG together instead of having to view, rate, and reject each image twice. I think some other functions might be nice to apply to a whole group too but you brought up a good use case where you might not want that. Then again, maybe we could justify assuming that if images are grouped together, the user probably wants setting to be applied to the whole groups. Otherwise, they could ungroup them. Thoughts?

#8 Updated by Anonymous almost 7 years ago

I have exactly the same problem as Rick. This feature could be really usefull when working with RAW+JPG, but at the moment this disfunctionality is preventing me from using it. I also think the possibilty of ungrouping and then rating, tagging etc. the subimages in different ways is a practicable solution.

In this connection the possibility of choosing the "main" image in a group while importing would be another improvement. So I prefer to have the JPG displayed when the groups are collapsed, not the RAW. Hope you understand me :-) And thanks for this great software!!

#9 Updated by Simon Spannagel almost 7 years ago

  • Tracker changed from Bug to Feature

The representative image of a group can be chosen in current git version. Use the "g" button on the image for it.
Not sure about the rest, certainly needs some more discussion, I'd convert this to a feature request again.

#10 Updated by Tobias Ellinghaus almost 7 years ago

  • Target version changed from Candidate for next minor release to Future

#11 Updated by Martin Schweifer about 6 years ago

I also miss the capability to rate jpg+raw simultaneously. For my workflow the efficiency would be highly increased. Without this feature, in ungrouped view each pair has to be rated double. I'm certain this is a benefit for the majority of users shooting jpg+raw and hope it will be implemented in a future version.

The other point of preferring the jpg as cover foto could also be meaningful. For example if someone prefers to work with jpg and rarely uses raw, a double click on the cover foto opens the right file. Selecting it using the "G" button in each group of course would work, but I think the request was meant as default setting (as an option in the menu). Maybe this should be discussed in a seperate thread.

#12 Updated by Tobias Ellinghaus about 6 years ago

  • % Done changed from 20 to 0
  • Target version changed from Future to Candidate for next minor release
  • Status changed from Incomplete to Closed: won't fix

After having thought about this quite a lot I came to the conclusion that this should not be part of regular darktable. However, once Lua support is working as intended I guess that this would be a job for a tiny script that registers to rating/labeling signals and does the same on all other images in the same group. I am sure Boucman (Jérémy Rosen) can help with that.

#13 Updated by Torsten Bronger over 5 years ago

I was bitten by this today. I imported all pictures of my last holiday trip (RAW/JPEG groups), rejected the bad, geotagged -- and then saw that still all JPEGs were neither rejected nor geotagged.

In http://darktable.org/redmine/issues/9785 it was requested again, and Simon says in http://darktable.org/redmine/issues/9907#note-1

However, if groups are collapsed and I try to delete it, what actually happens is that the group representative (in this case the RAW file) is deleted, but the rest stays. This is somehow inconsistent and imho we should just delete the whole group in this case.

So, I ask to implement this in DT core. I think such a feature would follow the Principle of Least Surprise. If members of a group differ in geoloc, rating, description, tags, they should not be in a group in my opinion. A group is the closest possible relation of images, and should be used for RAW/JPEG pairs, panorama components, and HDR components.

#14 Updated by Simon Spannagel over 5 years ago

  • % Done changed from 0 to 20
  • Status changed from Closed: won't fix to Triaged

Maybe we can find a solution that satisfies all needs and is consistent in it's behavior. Current situation definitely is not...

#15 Updated by Reed Law about 5 years ago

Tobias Ellinghaus wrote:

After having thought about this quite a lot I came to the conclusion that this should not be part of regular darktable. However, once Lua support is working as intended I guess that this would be a job for a tiny script that registers to rating/labeling signals and does the same on all other images in the same group. I am sure Boucman (Jérémy Rosen) can help with that.

Can this be done by a Lua script now? Or is there any other workaround available?

#16 Updated by Jérémy Rosen about 5 years ago

  • bitness set to 64-bit
  • System set to all
  • Affected Version set to git development version

there is a script in the wiki that does more or less that...

you can't have an event that triggers when rating changes, but you can do a lua shortcut that will change the rating for you (thus doing the same thing)

#17 Updated by Timo Steuerwald over 4 years ago

Jérémy Rosen wrote:

there is a script in the wiki that does more or less that...

Can you please provide a link to this script?

#18 Updated by Roman Lebedev about 4 years ago

  • Has duplicate Bug #10663: Darktable should attach tag to all images in the selected group added

#19 Updated by Michael Bewley almost 4 years ago

Would it make sense to just have a setting for this? "actions applied to group affect whole group TRUE/FALSE". It seems clear that both cases are valid (I'm in the raw+jpeg camp that would prefer whole group for accept/reject).

#20 Updated by Thibault Jouannic almost 4 years ago

I've been annoyed by this issue, since I'm also a raw+jpeg shooter. I realize that, depending on your workflow, you might want rating actions to be applied to only the group leader or to all group members.

I tried to write a small lua script to overcome this issue and was quite happy to discover that scripting is quite easy with darktable. Here is my script in attachment.

To use it, copy the script in ~/.config/darktable/lua and add `require "reject_group"` to the ~/.config/darktable/luarc file.

Restart Darktable, go to settings > shortcuts > lua and then assign shortcuts to "Reject all group members" (I use Shift+R) and to "Cancel grouped images rejection" (I use Ctrl+Shift+0).

Then, when pressing Shift+R, it will reject all selected images and all the images they are grouped with at once. Pressing Ctrl+Shift+0 will do the opposite and reset the rating attribute.

I don't use the 1~5 and color ratings, but the script should be quite easy to adapt and complete.

I hope this will be useful.

#21 Updated by thokster . almost 4 years ago

Perfect!
Very useful, thanks!

#22 Updated by hxy io almost 4 years ago

Thibault Jouannic wrote:

I don't use the 1~5 and color ratings, but the script should be quite easy to adapt and complete.

Thanks so much for your script!

I've adapted it slightly to cater for my needs to apply ratings (0-5) as well as rejections to images within a group:

  • Reject group: Ctrl+R
  • Rate group 0: Ctrl+0
  • Rate group 1: Ctrl+1
  • Rate group 2: Ctrl+2
  • Rate group 3: Ctrl+3
  • Rate group 4: Ctrl+4
  • Rate group 5: Ctrl+5

I've attached my modified script, but I've also uploaded it to a GitHub repo in the hope that others can improve and expand upon it:

https://github.com/ribmo/darktable-rate-group

https://github.com/ribmo/lua-scripts/blob/master/contrib/rate_group.lua

Edit: This is my first time playing with lua and since posting the script I've done a little refactoring. However, I can't seem to replace the attached file, so I'll continue to host the updated version on GitHub. (Unless there's an alternative way to maintain scripts preferred by the community?)

#24 Updated by hxy io almost 4 years ago

Thank you. I've now submitted a pull request to have the script added to the contrib lua scripts:

https://github.com/darktable-org/lua-scripts/pull/21

#25 Updated by Martin Dahlgren almost 4 years ago

Simon Spannagel wrote:

Maybe we can find a solution that satisfies all needs and is consistent in it's behavior. Current situation definitely is not...

Maybe a simple toggle in the settings 'should tags and ratings apply to all images in collapsed groups'. The Lua script is probably a great workaround (the Fedora package doesn't support Lua scripting so I can not tell) but since a jpeg+RAW-workflow is so common this functionality should probably be included in standard release.

#26 Updated by Jörg Mensmann over 3 years ago

The attached script uses a slightly different approach: It copies the star rating of the group leader (=RAW) to the other images in a group (=JPEG).

This means you can apply the ratings to the RAW files as usual, then later copy the ratings to the corresponding JPEGs. Just select all images and run the script. Useful when you already have a large library of images where the rating was only applied to the RAW files.

#27 Updated by Tobias Ellinghaus almost 3 years ago

  • Related to Bug #10099: Rejecting group head hides other group member added

#28 Updated by Tobias Ellinghaus almost 3 years ago

  • Related to Bug #11382: Copy local only copies group head added

#29 Updated by Trolli Schmittlauch over 2 years ago

Tobias Ellinghaus wrote:

If you group several images (for example bracketed shots + the generated HDR) only some images might justify a high star rating while the source images should be unstarred.

I don't see an issue there as groups can easily be expanded by clicking the G symbol. IMHO the "principle of least surprise" would mean that a collapsed group is treated as one object while members of an expanded group are treated as separate files.

Maybe the UI could also be improved to make this behaviour more obvious, but IMHO the current state of the UI already reflects the suggested behaviour.

#30 Updated by Trolli Schmittlauch over 2 years ago

I wrote a small RFC about how groups in darktable should behave. Please give me your comments on that. https://gist.github.com/schmittlauch/03ccf97ed19154e767d920992214f8ec

TL;DR: I found two not-so-easy cases:
  • applying styles
  • duplicating members of a group

#31 Updated by Diego Cesar about 2 years ago

I don't use the 1~5 and color ratings, but the script should be quite easy to adapt and complete.

Thanks for the script to rate groups. I'm also got surprised when I finished to rate/label tons of pictures and then found out they were only applied to the group header. These scripts saved a lot of extra work.

I understand it is not a simple decision, but so far I've based on scripts posted here to also label groups by color. I've made it public here:

https://gist.github.com/dbcesar/21ee10412e9310652aaa855020b1737d

Thx

#32 Updated by m laverdiere over 1 year ago

I'm new to darktable (which is awesome btw) and I stumbled upon this pretty quickly, as I was culling my first imported film roll full of RAW+JPG. As far as I understand, current LUA scripts help with color labels and rejection operations, but not with tagging, so that's a big part of a regular photo management workflow that is not covered.

So +1 for integration in the "next minor release", if possible.

#33 Updated by Rick Yorgason over 1 year ago

The solution to #6 is:

When selecting a new rating for an image:
→ If rating is the same for all grouped images:
  → Change the rating for all images in the group
  Else
  → Pop up a dialog saying "Images in this group contain different ratings. Are you sure you would like to apply this rating to all images in the group?"

#34 Updated by Rick Yorgason over 1 year ago

After some thought, I have a better idea:

1) Add a new image collection option: group leaders only. This gives everybody a way to access the current behaviour.
2) In 'G' mode, clicking a rating or the reject button applies that setting to all items in the group. This gives the behaviour everybody expects in this request.
3) In 'G' mode, selecting the group leader selects all items in the group, as originally suggested by Simon. This allows the rating and colour options in the bottom-left to work as expected, and would also make exporting groups or tagging groups easier.

I think this is a more consistent approach. If you're looking for a way to only show only the 'representative' images of HDR groups, that's exactly the sort of filtering that collections are supposed to provide.

#35 Updated by Rick Yorgason over 1 year ago

Implemented as described in my last comment. See pull request here: https://github.com/darktable-org/darktable/pull/1703

#36 Updated by Michael Demetriou 11 months ago

When grouping > group leaders is selected and grouping (the G on the upper right) is enabled, actions are still is being applied to both images, which is kind of confusing, since the followers aren't supposed to be in the collection at all.

#37 Updated by m laverdiere 11 months ago

As far as I can see, with dt 2.6 on Linux and Windows, this bug seems to be resolved as described in comment #34. Perfect! Thanks.

#38 Updated by Trolli Schmittlauch 10 months ago

Thanks to Rick Yorgason, all actions are now applied to all group members. Thanks for your work.

When working with darktable 2.6.0 thogh I found 2 actions, where having them applied to all pictures of the group is quite confusing and not what I intended:
I use auto-grouping of RAW+JPEG images.
1. Applying style presets to the group applies the same preset to both the JPEG and the RAW file. As all my presets have been taken from and are designed for RAW images, they look very weird on JPEG images.
2. When exporting a whole group, all images of the group get exported. As RAW and JPEG are grouped, all images get exported twice – once from the RAW, once from the JPEG.

I think it makes sense to distuingish between RAW and JPEG styles and only apply each type to the respective images of a group.
But about the image export I have no clue whether it should be different and if yes how to handle it.

#39 Updated by Rick Yorgason 10 months ago

Hi Trolli,

Have you tried using the "group leaders only" collection yet? It's in the collections panel on the left, and it's the new intended workflow for the issues you're describing.

When you turn grouping on, you can see your images "stack", so when you select a group, you select all the images in the group. This is good for actions like rating, where you want the same rating to apply to your RAW and JPG files.

On the other hand, you use the "group leaders only" collection, it doesn't stack the files, instead it just removes the images that wouldn't have been on top. This is good for actions that you only want to apply to your RAW files, like exporting.

It's like if you're sorting a deck of cards into suits: you can either make four piles of cards on your table, with the aces on top, or you can put only the aces on the table, and leave the rest of the cards in the box.

#40 Updated by Torsten Bronger 10 months ago

Thank you for the explanation but this is unnecessarily complicated in my opinion. Workflows are well supported if you optimise for the frequent use case. In case of tagging, this is the whole stack. In case of exporting, this is only one picture in each stack. Users should be forced to take additional action only if they want to deviate from this.

#41 Updated by thokster . 10 months ago

IMHO the current behavior follows not the "principle of least surprise". With one keystroke I'm editing pictures which are not visible.
Why should I rate always the whole group the same.
The "group leaders only" workaround is not usable if you are using any duplicates in a group.
IMO pressing one key should should only affect one image at a time.
CMD+key should be for all actions that should affect a group.

#42 Updated by Trolli Schmittlauch 10 months ago

thokster . wrote:

Why should I rate always the whole group the same.

At least in my case the motivation behind that were groups of RAW and corresponding camera JPEG files created by darktable's auto-grouping feature for RAW+JPEG imports. There all of the current behaviour, except for export and styles, totally makes sense.
I'd even not see any use case where you only want to rate the leader of a group (of 2 or more pictures). I see the use of rating certain single images of a group, but for that you can just expand it.

Torsten Bronger wrote:

Workflows are well supported if you optimise for the frequent use case.

That's exactly the problem here: It doesn't seem to be clear what workflow(s) we need to optimize for, at least thokster seems to have a different one then both of us.
I tried to get some feedback on sensible behaviour/ workflows in preparation of this feature, but unfortunately not that much feedback was given. https://gist.github.com/schmittlauch/03ccf97ed19154e767d920992214f8ec

Rick Yorgason wrote:

Have you tried using the "group leaders only" collection yet? It's in the collections panel on the left, and it's the new intended workflow for the issues you're describing.

I cannot find such a collection, could you point me to it on a screenshot please?
That might be a feasible, possibly still bumpy, workaround allowing different workflows to co-exist, one just has to remember switching between collections depending on which operations are expected.
This could be the best we can do, but maybe we also manage to put together all important workflows and find a solution to meet all expectations. So if you have a certain workflow, please speak up before they are re-designed.

#43 Updated by Trolli Schmittlauch 10 months ago

EDIT: I now found the "group leaders only" collection, and I have to say that is no feasible solution for (my/ a) workflow: When I apply styles or want to export images, I'm usually in a more or less cutomized view either filtered by a film role, tags or directory and filtered by star rating. The "group leaders only" collection forces me to change to another collection without my filters and try to locate the wanted images again.

#44 Updated by Rick Yorgason 10 months ago

Trolli, did you know that you can have as many collection filters as you want? If you have your view filtered by film roll, you can click the little 'v' to the right of that collection and choose "Narrow down this search", then add "group leaders only" as your second filter.

The only downside is that when you add a new collection filter, the scrolling moves for some reason. It would be nice to fix that.

I'm leery of doing too much that tries to invisibly, magically guess what the user wants to do. The way it works currently has absolutely no surprises once you understand the system. If we only applied exporting or styles to the group leader, that would work fine for the RAW+JPG use case, but it would surprise people when they use grouping for HDR or timelapses.

I could see an argument for adding a "Group leaders only yes/no" option to the export panel; that would be useful, and doesn't seem to surprising. I'm a little less sure about the styles panel; adding a "group leaders only" option that only matters when you double-click on a setting sounds confusing to me.

The other thing I'd like to see is a better visual indicator of groups. Currently, our indicators are the 'G' icon in the top-right corner of each image, and the '2 of whatever' indicator at the top of the screen when you select a group that represents a RAW+JPG group. I'd like to see something more like Mac's desktop stacks: https://images.idgesg.net/images/article/2018/06/macos-mojave-stacks-100762048-large.jpg

That will make it more obvious when you've selected a group of images, and also give you an indication as to whether the group is two images (probably RAW+JPG) or many images (like a timelapse or HDR group), all before you've even moved your mouse over the stack.

#45 Updated by Alex Besnier 9 months ago

This feature works well for me on dt 2.6/windows except in one case. If groups are collapsed, and if I switch from picture to picture using right/left arrow, when I set the colour label only the group leader is affected. Whereas, if I select a group clicking with mouse left button, then all pictures of the group are updated with the same colour label.
I haven't this behaviour with ratings, in both cases, all pictures are updated.

#46 Updated by m laverdiere 4 months ago

I.m on 2.6.2 (Linux and Windows) and as far as I can tell, this bug seems to be resolevec, i.e. actions are now applied to all grouped images when collapsed, including color labels, tags and rejection.

Also available in: Atom PDF

Go to top