White (dis)balance and Darktable

I would mostly agree, although real connoisseurs can see the Fuji colors in a raw because of that sweet x-trans sensor that no one else has :slight_smile:

1 Like

After experimenting a bit, I fractionally prefer the rendering of WB in daylight-ish situations, but switch to CC in difficult or mixed lighting. The difference is small, but to my eyes, significant, especially in skin tones. I’ll see if I can find a non-personal picture to illustrate the effect.

Regrettably, it seems impossible to create a preset for “as shot” WB? Any time I create the preset, it records the temp/tint.

Have you considered Ulrich’s initial workflow script… lots of options there…including setting WB settings and auto exposure and auto filmic B/W relative …

Lua script…

Gives you all these options…

image

1 Like

I have found the error, finally. CC actually works fine, and there is no green tint, iff it is set to “as shot”. The default, however, is “daylight” if CC is daylight-adjacent, which produces the tint I mentioned. I can indeed quantify this: In one picture (that I don’t want to share, sorry), CC “as shot”, switched to “custom” gives hue: 58.0°, chroma: 26.0%. Going “as shot”, then “daylight”, then “custom” gives hue: 50.4°, chroma 24.4%. That hue shift from 50° → 58° is my green tint.

This is easy enough to work around with a CC preset for “as shot”, which solves the issue for me. Frankly, though, it is simply highlighting the need for an old-school temp/tint slider. I know temp/tint not “correct” because tint is a lie, but it is a useful lie, at least for daylight-adjacent illuminants.

1 Like

I use exactly such an ‘as shot’ preset for both my Nikon and my Lumix camera. Switching to the other modes, e.g. custom, involves some rounding,I think (maybe only because of the limited resolution of the values one can input using the sliders).

@bastibe I also own a fuji. And the green cast when using daylight is due to a non perfect matrix (the adobe one).

A good fix is to use what is described in the manual darktable 4.2 user manual - color calibration.

When you use as shot you are extracting hue and chroma of the illuminant from the image exif. You can also fix them with custom. Basically you’re removing the greenish caused by the not perfect d65 matrix.

This will restart the discussion of the original thread where AP explained quite well the reasons of not using tint. Just use hue and chroma with custom if you want to manually set the illuminant color. That thread is a really good read.

As a side note one of the more interesting comment in the original thread is this:

Using spectral sensitivites instead of matrixes that are also non perfect will help to obtain really good color reproduction. The dual illuminant DCP profile are a step forward but with many issues (see dcamprof neutral operator implementation to obtain a real neutral dcp profile, adobe dcp profiles, that like the matrices extracted by it, have some subjective look and aren’t neutral profiles. For example I heard somewhere that in lightroom Fuji cameras has too much magenta. Obviously it’s not caused by the camera (raw files don’t have colors…). it’s just how they are profiled…).

Vkdt has some support for spectral profiles in the colour module but looks like you have to manually set the CCT, so I’m not sure how it works and how it could be ported to darktable.

3 Likes

I will try that, thank you! Recalibrating my monitor has been on my todo list anyway.

I’m aware of that discussion, but as they say in Python, practicality beats purity. Anyway, this is an old discussion that has reached a consensus before, so I won’t belabor the point.

Calibration alone may not be enough to fully realize the intended application of CAT WB in DT.

I have to admit I don’t always follow all the math in many of the color science papers and this was done with a different CAT model but in my limited understanding the CAT16 used in DT for a “white balance” is to better display/convey neutral/white and by association I would guess all colors from the scene to d65 viewing conditions of a typical monitor using all the rgb data and not just simple wb coefficients.

But not surprisingly how well this is able to work is also strongly impacted by the properties of the ambient light if I interpret the findings reported here.

So unless we are all in the same room with the same monitor with the same ambient light it might be hard to say that what we see when reporting these tints etc in DT is totally due CAT applied in the CC module but also in some cases perhaps as much or more about local conditions as well… Again as I said not surprising when you think about it as it is dealing with a “perceptual” aspect of color.

So this would likely lend even more support for the approach of one keeping your lighting consistent and two doing as Aurelien suggested and taking a photo of your D65 calibrated screen in that ambient light to make a corrective preset so you could help minimize that ambient lighting effect and assist a more complete CAT as intended without bias from ambient light properties.

CIC27_Peng_PG_231.pdf (804.6 KB)

2 Likes

You’re right. I just tried to create a style from the WB set to “as shot” and it saves the parameters as “user modified” with a set temperature and tint. Considering the “as shot” state can be saved for the color calibration module, perhaps a change request should be submitted so that the same can be done to the WB module? “As shot” should use the white balance extracted from the raw file if that’s possible.

I think you can do it for now if you were to use Ulrich’s lua script for initial workflow. It can set auto filmic, auto exposure at the chosen percentage…I start with 50 and just modify if needed and it will set the mask in the tone eq so it is ready among other things including set the various combinations of wb / CC settings and setting the fulcrums for color balance so that the adjustments are better targeted with an optimized tonal mask… its really a clever implementation

1 Like

I might take a look at that, thanks. My other thought is that the “legacy” setting for “auto apply chromatic adaptation defaults” uses “as shot” in the WB module. So, if you create a style that excludes the WB module and then apply the style in Append mode, you should retain the “as shot” state. So, there are at least a couple of workarounds for those who don’t want to use CC and still use styles/presets and want WB to always default to “as shot”.

Regardless, I still think saving the WB state as “user defined” when it’s actually “as shot” is undesirable behaviour, so I’ll submit an issue on github when I get around to it.

1 Like

Legacy has actually been removed… there are just three workflow choices now… scene, display and none… no entry for wb… so when DT updates you won’t see legacy anymore…

You have this now with wb and toning combined into workflow…

image

The thing I don’t like is that I used legacy wb and then used CC for the color tabs and as a channel mixer but now when you enable it it enables the cat it is not in bypass so I have to create a work around with a preset… its about a push to make you use scene unless you explicitly select display and the you get the base curve… so its a bit of a tweak if you use a hybrid of settings… You can also select none and get as shot but if you activate CC it will turn on the CAT now so then you have to disable CAT or correct wb to d65 or you get a double WB…

1 Like

What? Well that’s annoying because I’ve started doing exactly what you said, ie. using WB for main white balance and then CC only for channel mixing and other tweaking.
I’m already using scene-referred so I don’t need any more of a push to use it. I just want my default to be WB “as shot” and CC in bypass mode. Why did they have to mess with this?

1 Like

No idea… you can just create an auto preset to put CC in bypass but then you would have to remember you have done that… this will work in none and display but not the others as those workflows set wb to D65 and so having CC in bypass will give the wrong WB so you just have to remember you did it … so you can get to what you want ie the hybrid but you now have to use a preset to get that combination

@priort : In your screen shot you show the settings for work flow. For me (version 4.2.1) there’s another option just below it “auto-apply chromatic adaptation defaults” with choices “modern” or “legacy”. Using the legacy option, CC defaults to bypass… (adaptation “none” and illuminant “same as pipeline”).
That seems to do exactly what you want.

(As the field titles are cropped off, I can’t tell which option follows the workflow setting in your screen shot)

1 Like

That option is now gone

image

The settings are merged…

You get scene modes for sigmoid or filmic which both use modern WB aka CC module and apply scene default exposure.

You have base curve which applies BC and legacy WB and none which only applies legacy WB…

The issue arises now if you select legacy and then activate CC to do channel mixing or use the brightness or color tabs then it is activated with the CAT applied not in bypass so now your WB is wrong and you have to select bypass or create an autopreset with CC to avoid having to do that.

Then if you go back to modern with that preset in place you have to remember because then you will have to enable the CAT…

It seems like it is introducing an extra step as I would think those that choose none or legacy are not then often using that if they are also often using CC for WB…

At the very least the none workflow should leave CC activated in bypass IMO

1 Like

Not a good news now that I learned the CC module actually ruins my photos. :frowning:

Likely it doesn’t but bad D65 values would … and it relies on them…

Agreed. CC should always be in bypass mode if the WB is set to “as shot”.

A quick test of CC with the new D65 values seems to show my “green tint” issue solved. The original D65 values were apparently wildly off.