@anon41087856 It’s not necessarily just the red channel coefficient. Here’s another image from the same camera with red = 2,672 when the wb is set to camera reference. But applying the color calibration does not give a cyan hue to the white patch.
_DSC3684.ARW (47.1 MB)
_DSC3684.ARW.xmp (18.1 KB)
All I can say is your problematic sample is very peculiar. The light source is suspicious in the first place, it’s around 2400 K with seemingly low color reproduction index. Since I don’t know anything about the conditions of the shot, it’s hard for me to conclude where the failure is.
For cases like this, the white balance module is more robust. As I said above, more robust usually means less accurate, but predictably inaccurate.
To solve this kind of issue, I guess we will have to perform chromatic adaptation in spectral (which is planned for the future, I have all the coding bits required, just need to wire them).
Regarding color calibrator
So I noticed and maybe this is intended that if you use the color picker in the CAT tab the transform skips to Linear Bradford if you are on another transform. You can then go back to the transform you were using and so I was wondering why it jumps to that?? AI edges/ surfaces also jumps to linear Bradford however with surfaces the illuminant jumped to daylight but edges jumps to Planckian…I will need to test more images and maybe this is to be expected??
The Bradford transform is known to be more accurate than CAT16 for daylight illuminants, and CAT16 is known to hold the gamut better in case of difficult illuminants.
Whenever an auto illuminant is loaded (by reading the raw EXIF, sampling a surface or machine learning detection), there is a check that computes how far this illuminant is from daylight and black body: if close enough, Bradford is chosen, if not, it defaults to CAT16.
Same thing with the GUI. If the illuminant is less than 2.5% away from daylight, you are prompted with the temperature/daylight GUI. If it is closer to blackbody, you are prompted to temperature/planckian GUI. Else the program goes directly to custom hue/saturation GUI.
So the program always offers you the easiest method that ensure maximum accuracy.
Could somebody explain what is “camera reference” (D65) in the white balance module?
To be more specific:
I am currently working with dng files converted from Canon’s cr3 (since cr3 files cannot be read yet by exiv2/darktable), so the “camera reference” setting in white balance module does not seem to work (quite logically I supposed, since it’s a camera-dependent setting it probably need to be defined first).
With the “modern” option for chromatic adaptation, the white-balance module stays on “camera” setting and the color calibration module have adaptation=none.
If I manually set the white balance module to “camera reference”, it does not work (it does not change the channels coefficients).
Should I change the temperature de 6502 K and tint to 1 or wouldn’t it work that way?
Is there a way to determine the correct channel coefficients for camera reference/D65?
I can also continue to use just the white balance module without the new CAT, but since it give better results for my older cr2 files, I want to see if a can already switch to the modern way! 
Camera reference is a set of WB coefficients that make D65 light shot by this camera a neutral color. You can see that as the bare minimum for removing the green cast and ensuring the validity of the input color profile.
It doesn’t work for DNG because they have their own built-in profiles and it needs special handling that is not coded in darktable now.
Ok, thanks.
Does the color calibration module relies on an exact D65 setting (then, I suppose I could determine the corresponding channel coefficients by taking a picture of neutral grey lighted by day light?) or would it work with a approximate setting in white balance module (enough to removed the green cast and be around the validity of the input color profile)?
Also: if I store a auto preset for CAT=Linear Bradford (for this camera), will it do the same thing as the “modern” option (for a working camera / raw) or is this option cleverer than just a auto preset?
Exact D65 is what the input color profile expects, yes, so color calibration relies on that. You can just shoot a grey gradient on your PC screen, if it’s properly calibrated.
But the auto setting for color calibration won’t work in that setup, it reads the internal matrices we have for each sensor. It should be a bit more work to make DNG work. They are an exception in the raw landscape, full of peculiar behaviours.
Ok…
I suspected there was a technical basis…just had no idea of how it worked…I just tried it in a couple of outdoor shots…I have some indoor ones with some cast so I’ll see how it responds to those…thx
I thought DCP files were d65 and DNG are essentially embedded with DCP data are they not?? Just wondering. I have a couple of phones that capture raw as DNG. Whereas ICC is d50 based no?? So if you replace input color profile with a calibrated ICC how does that change things if at all??
While not mandatory, DCPs can contain two colormatrices, usually one for D65 and the other for StdA white points. They are interpolated between to get the matrix for the intended color temperature.
Of note is, while the ICC standard is D50-based, profile matrices don’t have to be with a good CMS library. dcraw matrices are D65.
It’s a weird business…
Thanks Glen .,.ya like 2850 k for the second one…I just wondered how the new modules various modes worked with that maybe that is what aurelien was taking about it needing further coding for DNG…
So if one was to use an input profile with D50 white point, would white balance temp need to match it?
No input matrice so far expects anything but D65, and the WB algo assumes D65 at the output. Remember we are in raw undemosaiced “RGB”, before input color profile.
I hope the Channel Mixer will stay. It’s a module that any other software I know uses. Renaming it would be strange and would certainly raise an eyebrow for anybody that uses any other photo editor.
A separate color calibration module would be great. I didn’t see any reference to any colorcheckers, hope the most basic ones will be included. Like in DaVinci Resolve (that is the free version). They have a preset matrix for 8 or so different colorcheckers (you can even use a cheap AliExpress one).
you can do this already using color lookup table module with darktable chart … It’s just not an integrated tool
There is a channel mixer inside the color calibration.
Now, extracting an RGB matrix from a color checker image to preset the channel coeffs is not super difficult, but I have no idea how to wire that in GUI, with a perspective correction.
So, no, no color checker for now.
Maybe @st.raw means the name should stay, as without the name well-known in the editing world people may think that the tool is missing:
However, since it does a lot more than the usual ‘channel mixer’ (thanks for that, Aurélien!), maybe the name could still reference channels somehow. ‘colour calibration & channels’, maybe (I know it could quickly become awkwardly long)?
Compared to the current longest (English) names:
‘colour adaptation & channels’
‘colour calibration & channels’
‘CAT & channel mixer’
‘CAT & channels’
vs
‘highlight reconstruction’
‘chromatic aberrations’
‘perspective correction’
‘output color profile’
‘color look up table’
‘contrast equalizer’
I’m starting to wonder if this module (like the filmic and color equaliser modules) shouldn’t be split in 2 or 3 separate modules. Even if that means doing basically the same mathematical operation 2 or 3 times.
At the moment it feels as if those three modules each have several functions, with separate interfaces.
One way to split it could be CAT vs channel mixer, which would have the brightness/colourfulness etc. tabs.
Or even split off the brightness and colourfulness in separate modules. Although that increases the number of modules quite a bit, I can see using several copies to deal with the separate functionalities with the module in its current form.
Wrt filmic, the reconstruction part could perhaps be split off? (if that’s possible and reasonable, a change to the filmic module should be moved to a different thread)
CAT is a channel mixer, and channel mixing is a way to correct the input color profile, which means it is a color calibration. There is only one function, but many uses. Besides, having everything in the same module is more computationally efficient since we have only one I/O. Splitting the features into separated modules will also increase the UI bloat.
It doesn’t make sense, since the reconstruction mask is defined from filmic white exposure and is intended to blend the clipping areas near white.
