RFC: behaviour of groups in Darktable

rfc_darktable_groups.md

maybe start writing up what should happen when, in a simple (hierarchical) text file. like, when grouping mode is on, then: else: also take into account if the group is expanded

another example: duplictaes get grouped, too. tagging one of them with the intended prupose (name of a client for example) shouldn't do that for all versions of the image so are ratings. they are things applied to an image that might be grouped

RFC: Behaviour of grouping in darktable

• related to issue #8968
• use cases for groups:
  • automatical grouping of RAW+JPEG on import
  • grouping of duplicates
  • images having a very strong connection: panorama image parts, exposure bracketing
    • mostly at same place & same time
  • tagging duplicated images with different effects & filter for different clients?
    • is this really done?
    • aren't tags a better solution for this?

operations on groups vs. operations on single objects

• current behaviour of the operations listed below: operation only applied to group leader (picture visible when group is collapsed)
• intended/ wishful behaviour
  • rating and rejecting
    • on group: rate/ reject all images of the group
    • on single picture/ expanded group members: group/reject only the selected image(s)
  • color labels: similar to rating & rejecting (for consistency)
  • delete/ move to trash/ copy/ move
    • on group: apply for all members of group
    • on single pictures/ expanded group members: only apply for selected members
  • duplicate
    • on group: duplicate whole group: create duplicates of all group members and group them again
    • on single pictures/ expanded group members: duplicate only selected ones
    • question: shall duplicated group members be part of the same group as the pictures they're duplicated from?
  • rotate/ reset rotation
    • on group: apply for all members
    • on single picture/ expanded group members: only apply for selected ones
  • create HDR images
    • on group: implicit assumption: all members are exposure bracketing shots -> create HDR from all of them
    • on single pictures/ expanded group members: only create HDR from selected pictures
  • tagging
    • on group: manual tags (not the automatic darktable ones) shall be applied to all members of the group
    • on single pictures/ expanded group members: tag only the selected ones
    • if you want to tag only certain group members: expand group first
  • metadata editor: similar to tagging
  • correct EXIF timestamp (via geolocation)
    • on group: correct/ shift timestamps for each group member
    • on single members (if you really want to do that): shift/correct timestamp only for selected members
  • apply preset styles
    • problematic for RAW+JPEG grouping, if RAW-specific filters (e.g. base-curve, RAW-denoise, lens correction) are part of the style
    • no good idea for that yet
    • maybe just don't apply presets to folded groups at all?
  • filtering the view e.g. by rating/ tag
    • if all images of the group suit the filter (e.g. have enough stars): show whole group collapsed as group
    • if only some members suit the filter: show them separately, but maybe hint they belong to a group?
    • curent behaviour: if only group leader gets rating, filtering for e.g. >= 2 stars only show the group leaders separately
  • "copy locally"
    • I don't use this feature at all so I can't comment on its everyday usage
    • but there's at least a bug report (#11382) suggesting to apply this copy action also to all group members

Yes, metadata similar to tagging. No exceptions of the rule please if it is avoidable.

Reject applying of presets to folded groups.

Please add a back-link to the DT issue.

@houz made some comments (marked in bold), I'll reply to the relevant part here:

• see doc/grouping.txt for general specs of how grouping works in dt
• use cases for groups:
  • tagging duplicated images with different effects & filter for different clients?
    • is this really done? – yes, because adding the image to a group when duplicating makes it the default behaviour

Ok, but does this mean anything for how groups shall behave or is the behaviour suggested below fine?

    - aren't tags a better solution for this? – **those are orthogonal things. tags are added to find the image and grouping is used to un-clutter the view**

operations on groups vs. operations on single objects

• current behaviour of the operations listed below: operation only applied to group leader (picture visible when group is collapsed)
• intended/ wishful behaviour
  • rating and rejecting – ok
    • on group: rate/ reject all images of the group
    • on single picture/ expanded group members: group/reject only the selected image(s)
  • color labels: similar to rating & rejecting (for consistency) – ok
  • delete/ move to trash/ copy/ move – ok
    • on group: apply for all members of group
    • on single pictures/ expanded group members: only apply for selected members
  • duplicate
    • on group: duplicate whole group: create duplicates of all group members and group them again – i would just duplicate the selected image/leader, expand the group and select the new duplicate. that way it's quick&easy to start a new alternate edit of an image.

I'm also fine with this, the behaviour should be quite apparent to the user.

    - on single pictures/ expanded group members: duplicate only selected ones – **ok**
    - question: shall duplicated group members be part of the same group as the pictures they're duplicated from? – **yes**
- rotate/ reset rotation – **ok**
    - on group: apply for all members
    - on single picture/ expanded group members: only apply for selected ones
- create HDR images – **in general: good idea. however, currently hdr creation fails when some of the selected images are not raw files. we'd have to make it skip those so it's still possible to shoot raw+jpeg and create an hdr from the raws without manually clicking through a lot of files. when such non-raw files are encountered during hdr merge a single message should be shown, telling the user that some files were ignored.**

This seems to be a "some work needs to be done here" point, but no blocker to changing of behaviour. Can maybe implemented later?

    - on group: implicit assumption: all members are exposure bracketing shots -> create HDR from all of them
    - on single pictures/ expanded group members: only create HDR from selected pictures
- tagging – **ok**
    - on group: manual tags (not the automatic darktable ones) shall be applied to all members of the group
    - on single pictures/ expanded group members: tag only the selected ones
    - if you want to tag only certain group members: expand group first
- metadata editor: similar to tagging – **ok**
- correct EXIF timestamp (via geolocation) – **ok**
    - on group: correct/ shift timestamps for each group member
    - on single members (if you really want to do that): shift/correct timestamp only for selected members
- apply preset styles – **i'd just apply it to the selected image/group leader. it's too easy to destroy edited duplicates otherwise.**

I see your point, the only issue I see here is that this behaviour would then differ from (nearly?) all other operations -> inconsistency
Alternative: don't apply on group pictures, just expand the group & show message overlay with hint

    - problematic for RAW+JPEG grouping, if RAW-specific filters (e.g. base-curve, RAW-denoise, lens correction) are part of the style
    - no good idea for that yet
    - maybe just don't apply presets to folded groups at all?
- filtering the view e.g. by rating/ tag
    - if all images of the group suit the filter (e.g. have enough stars): show whole group collapsed as group – **ok**
    - if only some members suit the filter: show them separately, but maybe hint they belong to a group? – **yes, showing them makes sense, either with a broder to show that they are grouped, or as a collapsed group with one of the shown images as the temporary group leader. to be discussed.**

I'm for showing the temporary group, but there should be a possibility to switch to the full group. So either expanding the group shows the full group with non-matching pictures greyed out, or we need another UI element?

    - curent behaviour: if only group leader gets rating, filtering for e.g. >= 2 stars only show the group leaders separately – **when the group leader has too few stars to be shown but there are grouped images that do have enough stars we currently hide them. which is bad.**

Yep. That's why this thing here is necessary.

- "copy locally" – **in the case of duplicates it's already copied as they share the same raw file. in the general case i tend to agree that caching all images in the group makes sense, but i don't have strong feelings about that. TODO: check if duplicates get marked as being cached.**
    - I don't use this feature at all so I can't comment on its everyday usage – **me neither**

So the only parts that we have to discuss and find a solution for are:

• applying a style to the group leader of a collapsed group
• showing images inside collapsed groups whose leader isn't shown due to filter settings

The latter is most likely going to be complicated, both from the UI and also how to code.
It should also be mentioned that all these things only apply when grouping is globally enabled in the top toolbar. Otherwise actions are always just affecting the selected image(s)!

It should also be mentioned that all these things only apply when grouping is globally enabled in the top toolbar. Otherwise actions are always just affecting the selected image(s)!

Are you sure about that? I think that we should treat all collapsed groups the same, no matter whether they're collapsed because all groups are collapsed or they've been collapsed manually.

on group: rate/ reject all images of the group

Has this been implemented and I messed up somehow, or is this still not the case, as I find it really frustrating to go through hundreds of photos hitting reject on the groups and having that only apply to the raw image and not the jpg as well.