style applies differently in lighttable compare to darkroom

[SoupyGit]

Describe the bug

See title.

Steps to reproduce

1. Duplicate an image twice
2. Discard History on both
3. On the first duplicate, apply a style in lighttable by double clicking the style name in 'styles' dialog
4. On the second duplicate, go into darkroom and apply the same style via the quick access button in bottom panel
5. Observe that the two duplicates do not match

*This may be dependent on the complexity of the style - in particular multiple instances (color calibration is a key culprit) and re-worked module order. I have attached a problematic style below (remove .txt). Correct behaviour for this style is as per step 4 above. Wrong behaviour is step 3:

portrait 2023-12-29.dtstyle.txt

Expected behavior

style is applied same way in both lighttable and darktable

Logfile | Screenshot | Screencast

Observe the first three thumbnails. The second two are the duplicates. The first duplicate (middle thumbnail) is as per step 3 above. The second duplicate (third thumbnail) as per step 4, and how it should look. That image can be found at pixls, but it happens on all images I've tried.

Logfile: -d.common.29-12-2023.txt

Commit

did not have this issue on 4.4

Where did you obtain darktable from?

self compiled

darktable version

dd604c1

What OS are you using?

Linux

What is the version of your OS?

Linux Mint 21.2 Cinnamon

Describe your system?

32gb
x11

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

nvidia geforce rtx 2060, 6gb, 535.129.03-0ubuntu0.22.04.1

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

not using lua

[TurboGit]

Your style is using a 3D Lut cube external file. Please try to reproduce with a self contained style. TIA.

[TurboGit]

BTW, removing the 3D Lut module from the style I cannot reproduce the issue.

[TurboGit]

Just in case make sure you don't apply the style in overwrite mode in Lighttable.

[SoupyGit]

I still reproduce with 3d lut taken out of the style:
portrait no lut.dtstyle.txt

Can confirm mode is 'append'.

[TurboGit]

Is that with all images? I still can't reproduce with your latest style. Do you have the same rendering when viewed in darkroom?

[TurboGit]

When I apply your style I see on the console:

    71,9762 [colorin] could not find requested profile `/home/tim/.config/darktable/color/in/Nikon_D3500_ssf-d65-mtx-cc24.icc'!
    72,0050 [colorout] could not find requested profile `/home/tim/.config/darktable/color/out/Rec2020-elle-V4-g22.icc'!
    72,3623 [colorin] could not find requested profile `/home/tim/.config/darktable/color/in/Nikon_D3500_ssf-d65-mtx-cc24.icc'!
    72,3681 [colorout] could not find requested profile `/home/tim/.config/darktable/color/out/Rec2020-elle-V4-g22.icc'!

Maybe that's part the issue and why I cannot reproduce?

[SoupyGit]

That is not the issue as those profiles are present in colorin and colorout on my system. Here is the same style without input and output profile: portrait v3.dtstyle.txt

Further experimentation has shown that it sometimes works and sometimes doesn't when applied in lighttable. See the below screencast (which is an mp4 file, not a txt).

style-issue.txt

In styles module, you will notice there is flickering when hovering over 'portrait v3' (and a couple of other styles located immediately above it), but no flickering when hovering over styles 'RAW', 'framing 3% white' or 'zones LUT colour reference'. If I apply 'portrait v3' without hovering over one of those no-flickering styles beforehand, the style applies incorrectly (image becomes too orange in thumbnail). However, if I apply 'portrait v3' after hovering over one of those no-flickering styles, the style applies correctly.

[SoupyGit]

One more test: duplicate an image, discard history, open the duplicate in darkroom, go back to lighttable and apply the style, it now applies correctly.

[TurboGit]

I can't reproduce the flickering, nor the wrong style apply... Really not sure what to do at this stage.

Maybe a compiler issue... Can you reproduce with a 4.6.0 binary (not self compiled)?

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions]

This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.