Darktable preview differs from its own snapshot

[mjstahlberg]

Is there an existing issue for this?

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

Describe the bug

In the attached screenshot on the right is an image as I see it while editing it in darktable, and on the left is a snapshot of the latest history state of the same image taken just before making that screenshot.

As you can see, the image while editing is significantly darker and has higher contrast than its own current snapshot, even though the two should (conceptually) be identical. When I export the image and look at it in geequie or GIMP, or view it in lighttable as a preview thumbnail, then I also see a brighter-than-desired version matching the snapshot shown on the left.

Steps to reproduce

I do not know how to reproduce this, and it has not happened to me for other images in the past.

Expected behavior

The snapshot comparison, lighttable preview, and exported image should match the appearance of the darktable editing preview much more closely.

Logfile | Screenshot | Screencast

Commit

No response

Where did you obtain darktable from?

distro packaging

darktable version

5.4.0

What OS are you using?

Linux

What is the version of your OS?

Arch Linux

Describe your system

No response

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

NVIDIA GeForce RTX 3070, NVIDIA 590.48.01

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

The issue persists regardless of whether I use high quality processing or not, use the system or sRGB display profile, or disable OpenCL in the settings.

[TurboGit]

Can you provide the RAW and XMP for the image it reproduces? TIA

[mjstahlberg]

Here's the DNG and xmp.

[TurboGit]

The issue comes from tone equalizer... Strange...

[wpferguson]

@TurboGit running in a console I got

   116.2208 Cholesky decomposition returned NaNs
   116.2401 Cholesky decomposition returned NaNs

which is used by tone equalizer

[mjstahlberg]

I'm not sure what role the Cholesky decomposition plays here but I can tell that, while it exists mathematically for all positive semidefinite matrices (which may only have positive or zero eigenvalues), numeric calculation of it typically requires the matrix in question to be positive definite (have strictly positive eigenvalues). Maybe at some resolution or precision of operations you get numerically zero eigenvalues that are causing these numeric issues while at other resolutions they end up all positive? A workaround for that would be to add the identity matrix with a small coefficient to the matrix being decomposed.

[TurboGit]

You curve smoothing is to big for this curve, see the line cannot be aligned with the curve:

You need to lower this until the curve fits:

So from 0.99 to 0.96.

And then the snapshot matches the darkroom.

[TurboGit]

So after all not a bug but a push over the limits.

[TurboGit]

Maybe at some resolution or precision of operations you get numerically zero eigenvalues that are causing these numeric issues while at other resolutions they end up all positive? A workaround for that would be to add the identity matrix with a small coefficient to the matrix being decomposed.

Maybe, let me reopen and discuss this with @jenshannoschwalm.