Changing illuminant to custom in color calibration changes image tone

[juhavlintula]

Describe the bug/issue I have an image where changing the illuminant from daylight to custom changes the image tone. When I open an image with default modules (scene referred, modern chromatic adaptation) and then change the illuminant from daylight to custom (without changing any other parameters) the overall tone changes.

To Reproduce

1. Open an image with empty history
2. Open color calibration
3. Change illuminant to custom
4. See the change in the tone

Expected behavior No visible change in the image

Screenshots Left side image before changing the illuminant, right hand side illuminant changed from daylight to custom.

Platform

• darktable version : 3.6.0 (official build)
• OS : Win10
• OpenCL installed : yes
• OpenCL activated : no impact

Additional context

• Can be reproduced with 3.7.0+1014~g6b4283c47
• Exists also in Ubuntu with 3.7.0+1014~g6b4283c47

Example image P8291577.zip

[paolodepetrillo]

This is what's happening in channelmixerrgb.c to cause the problem:

When the image is first loaded, reload_defaults gets the white balance from find_temperature_from_raw_coeffs as an xy chromaticity and sets the module parameters x and y to that. check_if_close_to_daylight then changes the illuminant from custom to daylight and sets the temperature parameter to the closest color temperature derived from x and y. But if that daylight color temperature was converted back to xy by illuminant_to_xy, it doesn't exactly match the original xy. So now the module's x and y parameters are inconsistent with its temperature parameter.

When illuminant is set to daylight, temperature is used, resulting in the greener sky on the left. But when it's changed to custom, the x and y that were originally set in reload_defaults are used, resulting in the bluer sky on the right.

The mismatch doesn't occur if the daylight color temperature 3861K for this image is entered manually rather than being set automatically: when gui_changed sets the temperature module parameter, it also sets x and y to the values derived from temperature by illuminant_to_xy so they are consistent. So the fix for this bug is to also do the same when setting the temperature in reload_defaults.

Even after this bug is fixed I wonder if it's really doing the right thing in this case switching automatically to a daylight illuminant based on color temperature rather than leaving it as custom. The bluer sky from the case where that switch did not occur does look more correct? Maybe the issues described in the caveats section of color calibration manual are involved?

[paolodepetrillo]

The illuminant for this particular image happens to be just barely under the threshold where it switches automatically from custom to daylight. In this case the difference between the custom illuminant and the daylight illuminant is 0.48%, and the threshold is 0.5%.

[juhavlintula]

The trick instructed in the manual did change the image significantly. I did a quick test and took a shot from my screen and defined a new WB setting.

Left with standard D65 and on the right my D65.

With my D65 setting, the difference when moving from as shot in camera to custom is much more subtle.

[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.

[lintujuh]

The issue still exists in 4.0.1+116. The eft side is how the image looks, when loaded into darkroom, and the modern chromatic adaptation defaults applied, the right hand side is when the illuminant is switched from Daylight to Custom.

[lintujuh]

As a workaround I have defined a preset with value "as shot in camera", and auto-apply it. This avoids the color change, when switching between daylight and custom illuminants.

[github-actions[bot]]

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[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.