Darktable: [WIP] need help to define what offset should be

[AlicVB]

I'm quite puzzled on how to implement offset changes in the new thumbtable (see #4103) Currently it's not really satisfactory (see #4168 as the last example)

• By offset I mean which image should be shown on top-left of the filemanager.
• In graphics representations bellow, I've shown what is the "ideal" situation in my mind.
• The case to handle is when you change rating of image(s) with "sort by rating" or "filter by rating" for example (if the main query change, we reset the offset, it's easy !)

Initial situation (number is ordering value and letter is the imgid and x means the image is shown)

1-2-3-4-5-6-7-8-9
A-B-C-D-E-F-G-H-I
      x x x x

case 1 In case there's movement in all images except D : no problem, we just need to ensure D is still the first image shown (keep offset by imgid)

In case D moves, it's problematic :
case 2 CDE are removed (example : they are selected and we reject the selection):

1-2-3-4-5-6
A-B-F-G-H-I
    x x x x

Here we need to know previous collection, to use the "first-still-here" imgid as offset (need some modification but doable)

case 3 D move to the beginning

1-2-3-4-5-6-7-8-9
D-A-B-C-E-F-G-H-I
        x x x x

And here is the problem : we can't rely on imgid offset, but I don't see how to be sure that D has moved (yes ordering has changed, but this is true in case 1 too)
And keeping offset by ordering doesn't work well too :

case 4 CDE move to the beginning

1-2-3-4-5-6-7-8-9
C-D-E-A-B-F-G-H-I
          x x x x

ATM, I've not seen any easy way to implement a "clear and consistent" algorithm to determine the new offset after a collection changed.

So if some other devs have ideas, I would be grateful !

[TurboGit]

Maybe the solution is to forget about what is displayed and ensure that we are always seeing the same picture slots on screen?

1-2-3-4-5-6-7-8-9
A-B-C-D-E-F-G-H-I
      x x x x

Case 2:

1-2-3-4-5-6
A-B-F-G-H-I
      x x x x

Case 3:

1-2-3-4-5-6-7-8-9
D-A-B-C-E-F-G-H-I
      x x x x

Case 4:

1-2-3-4-5-6-7-8-9
C-D-E-A-B-F-G-H-I
      x x x x

That is, if we are looking at the 3 first images of the collection, we will always look at the 3 first whatever happens to the collection. This seems safe and very easy to understand for end-user. Won't this works in all cases? Any drawbacks?

BTW, what other software (shotwell, digikam, gthumb...) are doing in such situation ? Maybe following what others do will make more sense.

[GrahamByrnes]

I'm not a dev... but still opinionated :-)
Basically you want a sort order that can be applied during a sort, which respects both the post-sort and pre-sort order. I don't think that is possible.
So what is it that the user is trying to do? Do a complete traverse of the collection without revisiting previously graded images? In that case moving D to the front should make it disappear from the screen, since it is "done" (a bucket-sort logic, D is "good enough"). If otoh it is meant to be competitive grading, ie what is the "best" image, then D needs to be kept on screen (first position reserved for highest ranked image) while the "challengers" continue to arrive in the remaining observation slots.
That could be generalised up to preserving upto the first n-1 of n slots.
But the basic problem is that there is no O(m) sorting routine for m objects, so there can be no single-pass complete sort.

[AlicVB]

So... I've done some quick tests with different software (note that I certainly have missed some specific features here, as I'm not really familiar with those apps...)

• Digikam use @TurboGit suggestion if the modified image is not in a selection. In case the modified image is inside a selection, it applies the change to all image of the selection and "follow" the selection.
• Shotwell always "follow" the changed image, but it seems that you always have to select images before doing changes.
• Geeqie change order only after some click in the interface, and move to the new position of the clicked image (doesn't works well imho)

Finally, @TurboGit may be the better solution. Not to say that it's the simplest to implement :P

[AlicVB]

Ok, I've gone a little further in the implementation, and I finally think that keeping offsets in not a good idea after all, at least for this cases :

• if you sort by rating, with all image set to 1 star and apply for example star 4 to image D, you'll end with the previous image under cursor, although you may usually want to rate the next one... This is especially problematic if you have 1 image per row (or in full preview)
• if you apply ratings to "big" selection, you may end with fully new images in your view altough you didn't touch the first image in the screen, which is quite confusing and give the impression to end up at a random position in the collection...

So after some thought, I think I'll be able to implement this :

• add new event with modified image list in parameter
• if the first image doesn't belong to this list, we ensure that this image is stiff in first (keep offset by imageid)
• if the first image belong to the list AND it's rowid hasn't changed => keep this image first (keep offset by imageid) this is the case if the change to images doesn't image position in collection
• if the first image belong to the list AND it's rowid has changed => put the first image not in the list at first place

I see one problematic case, if the change to the list move images but not the first one although the first is in the list : this can be the case if D has 4 stars, E-F has 3 stars and you apply "4 stars" to DEF
But well, this is a corner case, so I'm not sure that "failing" here is so problematic...

The "new" algorithm should do :

Initial situation (number is ordering value and letter is the imgid and little x means the image is shown)

1-2-3-4-5-6-7-8-9
A-B-C-D-E-F-G-H-I
      x x x x

A. EF move to the beginning

1-2-3-4-5-6-7-8-9
E-F-A-B-C-D-G-H-I
          x x x x

B. CDE are removed (example : they are selected and we reject the selection):

1-2-3-4-5-6
A-B-F-G-H-I
    x x x x

C. D move to the beginning

1-2-3-4-5-6-7-8-9
D-A-B-C-E-F-G-H-I
        x x x x

D. CDE are move to the beginning

1-2-3-4-5-6-7-8-9
C-D-E-A-B-F-G-H-I
          x x x x

What do you think ? any drawback or forgotten cases ?

[TurboGit]

Hard to visualize all cases but what you describes seems workable to me. I suppose all this will be really tested when having the lt in front of us and see how the images are moving around and to see of our cognitive understanding makes sense of the new positions easily.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.

[AlicVB]

closing, now that lighttable rewrite as landed in master