lighttable not updated when exiting from darkroom

[ptilopteri]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

import images
open image in darkroom
automatic presets applied and image reflects change
return to lighttable
images are not updated to reflect changes shown in darkroom view
image edited indicator is not shown

confirmed by wpferguson

Steps to reproduce

as above

Expected behavior

lightroom display should reflect changes in darkroom and edits indicated

Logfile | Screenshot | Screencast

No response

Commit

I first saw on master fb2287

Where did you obtain darktable from?

self compiled

darktable version

release-5.1.0-169-gfb2228727e

What OS are you using?

Linux

What is the version of your OS?

openSUSE Tumbleweed 20250121

Describe your system?

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[wpferguson]

Reproduced using an auto preset with tone equalizer

[jenshannoschwalm]

Shouldn't the changed indicator reflect only changes after auto-presets are applied?

[wpferguson]

The image is opened in darkroom and the auto preset is applied and the change observed. If you return to lighttable, the thumbnail does not update, though it should, and the edit icon does not appear, though it should.

[jenshannoschwalm]

I am really confused here

1. I could not observe this but maybe the hash was wrong so something that should have been fixed via pixelpipe basichash fix #18275 ?
2. From all what i can remember - i looked up the manual but couldn't find an explicite mentioning of this (@elstoc would you know where or is this missing) - an "anything has changed" condition is to be understood as "anything changed after auto presets being applied". This should be reflected in the lighttable +/- icon. Also this condition effects the xmp writing in lazy (after edit) mode. xmp are written if changed, otherwise they are removed.
3. About the thumb not being updated, for sure this must be - and has been / is - updated already while importing if using "use raw file instead of ..." as preference. Not sure how exactly this is supposed to work if we take thumbs from embedded jpeg.

[ptilopteri]

If one loads images into dt and presets are automagically applied, the image has changed and the lighttable display used to show such, also the changed indicator was visible but is no longer.
I create xmps on import.

[jenshannoschwalm]

OK, the thumb not updating is clearly a regression.

[ptilopteri]

* Hanno Schwalm ***@***.***> [01-28-25 11:19]:

OK, the thumb not updating is clearly a regression.

it also has lost the indication that the image has been edited.

…

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

[jenshannoschwalm]

Will bisect. Never observed that thumb problem as I always process thumbs from raw.

[jenshannoschwalm]

@ptilopteri @wpferguson @TurboGit

I bisected and it seems to me i can still trust my memories :-)

Test case here: For each test

1. use empty data.db / library.db,
2. no lua scripts activated
3. import a bunch of images with at least one raw image with a B/W embedded preview (just to make it easy to be spooted), these preferences
   
   

I could only bisect back to Merge branch 'kmilos/exiv2_bmff_ena c184919 because of problem: Exiv2::enableBMFF() build problems but that commit from July 24 already shows the behaviour that was reported as bad.

I also investigated the code and it seems to be clear to me that for long only changes done after auto-applied presets would be understood as altered leading to the added "modified icon" and updated thumb.

When enforcing thumbs developed from raw as

The initial thumb will be as auto-applied-presets but still without the "changed icon".

So i am personally back to "confused state" as what we have in master seems to be as what we have at least since 4.8 ...