And if I use the legacy workflow and disable color calibration and use the legacy wb module to set the wb I get white-gray background without the color cast.
Hard to say …if you can share the raw it might be more helpful to see if it is seen by all or something on your end…sometimes CC doesn’t read the camera data the first time…usually just clicking the picker for an average of the image…you might actually like that and if not going back to as shot will look as expected…
Here is the raw. (CC BY-SA) The as-shot white balance is off, the issue is that selecting the white wall creates correct outcome with the legace wb module, but not with new cc.
I think the problem comes indeed from the highlight reconstruction:
in the area where red is clipped, all pixels are clamped to white (i.e. the raw white point) if highlight recovery is used with “clip highlights”. The raw white point is 16300 for my camera, i.e. ~ 14 bits, data is handled in 16 bits/channel here (we are still before demosaicing)
Highlight reconstruction comesafter the raw WB module, which already applies a few mulipliers (in my case 2.958 for red, and 1.372 for blue when set to “camera reference”). So any red signal that’s over 16300/2.958 = 5510 will be considered “overexposed” by the highlight reconstruction module (if I understand the manual correctly), and in clipping mode, that means all channels will be clamped to that value. (Note that if highlight reconstruction is not used, those multipliers would not cause clipping, as we still have 2 bits room over the sensor values, that’s a factor of 4).
And that means that the “color calibration” module sees different colours over an area you tell it is neutral gray. So the poor module gets confused and decides on an average white balance, pushing the “clipped” area (relatively poor in red) to magenta, and the non-clipped area to red/magenta. And since the highlight reconstruction module introduced hue shifts in the wall area, you can’t get a decent white balance setting for the whole wall.
Using the raw WB alone gives a red multiplier that’s <1, so nothing gets clipped.
As you do not have overexposure here, the solution would be to switch off highlight reconstruction (as @Jade_NL suggested already).
Thank you all for the investigation. I usually have the highlight reconstruction off, but I was doing the processing with “out-of-the-box” instance.
This is maybe a stupid question, but has the highlight recovery be after wb? Could it be placed before to avoid the false clipping when using the scene referred workflow?
Highlight reconstruction, as found in the current 3.8 and earlier versions, aren’t one of darktable’s strong points. Not sure if it is going to be in the upcoming 3.8.1 version (don’t think so) but there are 2 projects currently being worked on to fix this shortcoming:
For now I think the best approach is to try the available options that the current highlight recovery module offers to get a good result and to keep in mind that it might interfere with the other modules (which makes turning it off a very viable option).
I’m not sure if moving the current version in the toolchain will be a good idea, maybe one of the developers (@hannoschwalm / @anon41087856 ?) can say something about that.
As the hightlight recovery aims to transform clipped areas to ‘white’ (or gray, in Lch mode), it should come after white balancing. Otherwise, you’d end up with coloured highlights: after hightlight recovery, R, G and B values are identical for clipped pixels, if WB comes after, you’d end up with coloured highlights (as the Red and Blue multipliers are rarely both 1.000)
