It’s expected because we work in RGB, which is not perceptually even.
F********ck. That’s a typo and a bug. Although unrelated to the problem, but thanks for spotting it !
1 Like
This is what I feared. If there is no hidden bug, it probably means very few people will be able to use this functionality. If there’s a green slider, it seems like a reasonable expectation that it affects the greens.
3 Likes
I’m confused enough by all the terms that mean related things. In fact, Aurélien calls this saturation in the code. 
darktable/src/iop/channelmixerrgb.c at release-3.4.0 · darktable-org/darktable · GitHub (check line 520).
1 Like
Interestingly, when you move the slider (to left, for example) the histogram changes “as expected”. Move the green slider, only the green part of the histogram changes. Greenness of the green parts of the image doesn’t.
Playing a bit with those sliders on an image of a (almost pure red) poppy also showed a marked influence of the adaptation setting. When I put the green at -0.5 in the colorfulness tab (with normalisation ‘on’), I saw:
- very little effect on the (red) flower with adaptation set to CAT16
- moderate effect with adaptation = XYZ
- strong effect with adaptation = Bradford (linear or non-linear).
With normalisation off, the effects were a lot weaker, but still there (and in the same order).
And using demosaicing set to “photosite color” shows a strong effect of the ‘green’ slider on the red pixels (in colourfulness tab) when using either Bradford adaptation.
1 Like
Well, it is a kind of saturation but not exactly perceptual.
Greenness, in LMS spaces and friends (CAT16, Bradford, XYZ) is more like luminance.
That bug got fixed today. Don’t use normalization modes in 3.4.0 for R, G, B tabs.
3 Likes
I think this is what I noted…despite AP’s comment on perception…the green should change value I would think and for me with the picker on a green square in a color chart the green value in the rgb triplet did not change in the full range of the slider…
4 Likes
Yes it is very strange how the green slider effects blue. However I’ve found that boosting R and B sliders together also boosts green colours, perhaps because most greens in the image also have some amount of R and B?
If anyone wants to boost saturation of only green channel, go to G channel, and set R -0.5, G 2, B -0.5, and use opacity to control the amount. This gives the effect I was expecting from colourfulness. (I assume when the bug is fixed you will be able to just tick normalize, set G 2 and leave the others alone).
Nope.
What you see on your screen is probably sRGB. So your goal is to push R and B of sRGB space. But what you control is R and B of Rec2020 or CAT16 or Bradford CAT spaces. Those control RGB will later be mixed in various proportions to create our final sRGB.
Therefore, don’t get too stuck on the meaning of R, G, B. Call them bullshit channel 1, bullshit channel 2 and bullshit channel 3 if it helps. Channel mixing is not perceptual. However, it blends changes more smoothly than pushing selective hues on color zones, for example. So this is the trade-off.
But you will need to learn the relationship between effect and setting, because the settings are not perceptually meaningful.
3 Likes
Thanks for this…I think this makes more sense now i was thinking of them as a global removal or addition of chroma for example with colorfulness and the brightness as some sort of color channel luma but it is something different…
Because brightness, inside, is an exposure compensation. Multiply whatever linear RGB by some constant, and it will hold. This doesn’t need to be perceptual. Hue, chroma, saturation are something else.
1 Like
OK, thanks for the explanation.
Can this be used as a normal channel mixer like the one in Gimp, Photoshop or DaVinci Resolve? Will the result from those be reproduced in DT color calibration the same way?
For that use I believe you use an instance set to bypass and then use the R G and B tabs…that is the channel mixer version
1 Like
Oh, there’s even a preset for that, thanks 
It’s excellent, I love it 
I guess I’m still a little confused. I used the “basic channel mixer” preset and loaded an example png file I created with inkscape:
(first row is 255 red, 255 green, 255 blue, second row is 128 red, 128 green, 128 blue, last row is 0,0,m 128,128,128 and 255,255,255)
I set the working profile to sRGB:
Adaptation is set to “none” as defined by the preset
Adjusting blue seems only to affect blue (I disabled normalization due to the bug):
However, adjusting green seems to also affect red:
And adjusting red seems to affect green and blue:
I guess I’m still not getting how it works. The “input green slider” does not seem to just multiply the green value (in sRGB) by some number, although i selected “none (bypass)” as adaptation.
1 Like
Either the module has bugs, or it is not a replacement of the old channel mixer, in which case it should be restored, I think.
Here is the colour wheel; I’ve set the working profile to sRGB, took a snapshot and activated the ‘swap G and B’ preset of colour calibration. What I expect is a mirrored version of the image, but comparing with the snapshot, that is not the case.
Switching the working space to linear Rec2020, the result is even more puzzling (for me) (comparison to snapshot has been turned off):
2 Likes
The ‘old’ channel mixer also does not simply produce a mirrored image when working space is linear Rec2020.
Colour calibration is the module that is supposed to replace channel mixer, and they have presets with the same name but rather different outcomes. I think the documentation (https://darktable-org.github.io/dtdocs/module-reference/processing-modules/color-calibration/) needs to mention this, and the other surprising aspects of the module. In particular,
To get an intuitive understanding…
seems to be rather unlikely.