Group ID is altered to Image ID of current group leader about darktable HOT 5 CLOSED

Is this intended bevahiour?
The group ID of an image group is altered to the image id of the current group leader.

Yes, that's how groups are created.

group ids should not change once created

When an image is imported the group id is set to the image id. If this were the case, we could never have groups.

How are you changing the group leader?

As far as the collection, it displays what was at the time the filter ran. If you change the conditions then you need to rerun the filter to update.

from darktable.

Furthermore....

It's not just groups that behave this way.

For example: I display a film roll/folder. I select an image and rename it using a lua script. If I hover over the image after I've renamed it, the old name still shows up. If I refresh the collection, then the new name shows up.

from darktable.

How are you changing the group leader?

by clicking the group icon in the image overlay

As far as the collection, it displays what was at the time the filter ran. If you change the conditions then you need to rerun the filter to update.

This is what I am well aware of.

When an image is imported the group id is set to the image id.

I was thinking about this and tbh i find this behavior somehow odd for a variety of reasons. The fact that it creates this huge, useless set of one-image-sized groups being the most prominent even though it almost doesn't become visible in day-to-day use unless you are actually working with groups.

If this were the case, we could never have groups.

And for that reason I think, the underlying behavior should change.
Instead of setting group id to image id on import, group id should not be set or set to 0 (to represent no group assignment). Once a group is created the group id should (of course) be unique and not depend on image id at all and - most important - should not change during it's lifetime.

I do however suspect that this change probably requires quite large code changes and might also cause database compatibility issues. So unless there are further comments or thoughts on this feel free to close this issue and in the meantime I will think about how i can change my workflow. I might try to hook into the group leader change and dynamically update the collection filter in my group-view lua plugin.

from darktable.

be unique and not depend on image id at all and - most important - should not change during it's lifetime.

The image id is unique :-).

I use the autogrouper script, which groups by time interval. If I run it and don't like the grouping, because I didn't choose the right time, then I just rerun it with another time setting. If group ids can never be changed then I couldn't do this.

I do however suspect that this change probably requires quite large code changes and might also cause database compatibility issues.

Yes :-). As well as having to rethink grouping entirely.

Grouping isn't saved in the XMP file, #16827, because it's dependent on the image id which would probably change on a re-import. As I was trying to think of workarounds to this I thought about using tags, which are kept in the XMP, to record grouping information. If you use the darktable|<something> then they don't show up in the tag list but you can still access them from lua. Doing that you could have darktable|group|<somevalue> and darktable|group-leader|<samevalue as group> to keep track of your grouping. You could also have images in multiple groups. You could manipulate darktable.gui.selection() to display your groups or use collect rules to filter.

from darktable.

Thanks for additional input

from darktable.