Introducing color calibration module (formerly known as channel mixer rgb)

I just tried that image. The CAT relies on the usual white balance to correct the image to D65, so that the color input profile gets predictable. But for the Sony from that picture, the red white-balance coeff is 2.67, which is massive and probably wrong (most sensors are between 2 and 2.33). If you force a red coeff of 2.0 in white balance module, then retry the color calibration sampling from any grey patch, then it will work.

Problem here is we stack the color calibration on top of white balance and input color profile, so we expect/pray for anything else having been profiled properly.

I got the smell of the red factor issue because cyan is the opponent color.

All the CCT computations there are approximations. The temperature slider of color calibration computes the XYZ coordinates of the illuminant from an approximation based on temperature input. Then the CCT display tries to find the best temperature match from an approximation based on XYZ input. Having only 1 K of error in the roundtrip is actually impressive. And you get rounded to 1 K, so a visible difference of 1K could be an actual difference of 0.5 K.

Don’t even try to compare temperature readings from both modules. Again, color calibration takes an input that is already pre-corrected by white balance and input profile.

Right click on slider, input value on keyboard up to 10.

1 Like

On that point, it might be time to check the WB coefficients of your camera.

If your screen is properly calibrated to D65, just display a grey gradient on it, shoot it with your camera, then open the raw in darktable and do a spot-white balance on the whole ramp in the white balance module.

Finally, compare the RGB coeffs you got with the sampling with the “camera reference” ones, and report here in case of large shift.

1 Like

Would it be possible to add a warning + tooltip to the UI that warns the user and proposes this fix in case the multipliers seem fishy? We could get it in the docs, but users, so far, have not been very good at reading that.

It’s just something I noticed on one picture so far, let’s try to understand what happens first, see how frequent it is, then decide about what we do.

@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)


Again, image is not mine and exact source is unknown.

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

2 Likes

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.

1 Like

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! :slight_smile:

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.

1 Like

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.

2 Likes

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

image

you can do this already using color lookup table module with darktable chart … It’s just not an integrated tool

1 Like