Color Calibration with checker breaks saturated blues

[wilecoyote2015]

Describe the bug/issue Using the SpyderCheckr 24 (post 2018), very saturated blues turn black when using the color calibration module and calibrating via the checker. May this be related to Note 2 on the CAT tab controls section in the manual module reference for the color calibration module?

To Reproduce Please provide detailed steps to reproduce the behaviour, for example:

1. Download the images
2. Open _DSF0822.RAF
3. In the color calibration module, calibrate with checker
4. Apply the calibration via a style / module preset / copy and paste to _DSF0825.RAF

Screenshots

Platform Compilation was performed after removing the build directory and /opt/darktable, as advised in the build script readme.

• darktable version : current master
• OS : Arch Linux
• Memory : 40Gb
• Graphics card : Intel Iris Xe integrated
• Graphics driver : mesa
• OpenCL installed : yes
• OpenCL activated : Reproduced with and without OpenCL
• Xorg : Wayland
• Desktop : sway
• gcc : 12.1.0
• cflags : used build script
• CMAKE_BUILD_TYPE : release

Additional context Raw files: https://drive.google.com/drive/folders/11P756dzoA0LpM4ksmXShGZU_HLGgAEJh?usp=sharing

[SoupyGit]

I'm not a developer, but my understanding of this issue is not to do with the color checker function, but the clipping controls in the channel mixer (color calibration) - and when you use the color checker, it adjust the values in the channel mixer. I believe it clips to black whenever numbers on y scale become negative. It is reproducible by pushing any of the sliders in R,G,B tabs too far, where the limit varies with each slider. The sliders with the least room to move are B sliders in R and G tabs, when you reduce their value. We can see why blue/purple is most problematic when we look at the gamut diagram: https://en.wikipedia.org/wiki/Rec._2020#/media/File:CIExy1931_Rec_2020.svg

Those colours are closest to 0 on the y scale, giving them the least room to move. I'm only on 3.8.1 so can't check your xmp, but I'm guessing one of those two sliders I mentioned is the culprit.

Fortunately this problem will be very rare in real world photography, because we typically don't photograph synthetic objects with such highly saturated blue. Moreover, we can use scopes to ensure we don't push blue and purple out of gamut.

It is related to this issue: https://github.com/darktable-org/darktable/issues/9076 A solution suggested there is to lighten black level correction in exposure module until the problem goes away.

[wilecoyote2015]

Thanks for the information! So, I understand that the problem results from the calculation of the z component during the back transformation from the xyY space after application of the linear operator represented by the matrix defined by the estimated coefficients from the color checker. Furthermore, as @aurelienpierre explained, this is valid and expected behavior because the set of values in XYZ leading to the problem represent non-physical colors because they do not constitute possible tristimulus values.

However, I'd like to understand the reason why this occurs in my case. The problematic pixels represent physical colors measured with the camera sensor and hence I'd expect an accurate (and valid-valued) color representation as a result of the calibration via checker. My initial guess would be that the camera input profile is inaccurate?

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions[bot]]

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.