Also, what’s pure red/green/blue in one color space, isn’t pure anymore in another color space, as different spaces use different primaries (assuming the original colors are within the other color spaces in volved; if not, clipping/mapping will complicate the issue even more).
So unless every change is done in the same color space as the original, you will get “crosstalk”.
But why are not all blue areas/components reduced when you pull down the blue slider in the channel mixer?
What is your histogram profile…that determines your picker values. Often the expected readings come when set for sRGB vs the default linear rec2020
Did you use the simple channel mixer preset, or did you disable chromatic adaptation? Unless adaptation is disabled, you won’t be mixing R, G and B channels (of the working space, by default Rec 2020), but rather the LMS RGB channels used by the adaptation.
Read more about that here: darktable 4.6 user manual - color calibration. About LMS: LMS color space - Wikipedia; about chromatic adaptation: Chromatic adaptation - Wikipedia
As mentioned by @rvietor, an sRGB input, converted to the working space, Rec 2020, will be represented by a mix of the Rec 2020 primaries, and the pure sRGB primary colours will no longer be ‘pure’ in Rec 2020. (Sorry about the repetition, I started writing this shortly after you posted the question, but didn’t have time to finish and post it.)
The sRGB primaries (red: 100% R, 0% G, 0% B; and similarly for the others, green and blue) are represented by the following components in Rec 2020, which is darktable’s default working space (these values are for D65 white point, but darktable uses D50 – anyway, these should give you an idea):
sRGB red: (62.74%, 6.91%, 1.64%); green: 32.93%, 91.95%, 8.80%; blue: 4.33%, 1.14%, 89.56%. (If I got my maths right.)
Those numbers indicate 2 things:
Then, if you mix those, and e.g. reduce Rec 2020 blue, you won’t only affect the original sRGB blue patch, but also the others.
Finally, I think the colour picker is influenced by the output and display colour profile (I may be mistaken, but I think for a long time it was a problematic area in darktable).
I think the last part while still true wouldn’t likely be an issue for this type of image if it’s a prepared sRGB tiff. I think taking out unnecessary color space conversions by setting the working profile to sRGB, using a new instance of color calibration with Cat disabled for channel mixing, and setting the histogram profile to sRGB so it reports values in that color space should be more as expected…
And probably linear sRGB or linear Rec 709 (uses the same primaries); otherwise, the numbers ‘may not add up’ (or may ‘add up’ in unexpected ways). 
Thank you for a thorough answer (as always).
There are several things in this subject I don’t fully understand, but maybe we return to the subject of difference in color spaces later on.
The most basic problem is the following: Pulling down the blue slider in the blue tab changes the value of blues in all areas except in the red circle. Why?
Adaptation is turned off in the CAT tab (apparently the default setting for a tiff file).
I haven’t used the basic channel mixer preset. If I turn this on nothing happens when I pull the blue slider unless I uncheck “normalize channels”. If this option is unchecked, we are back to “square one” the blues in the red circle doesn’t change when pulling the blue slider.
I think it’d be very hard to track those changes numerically in darktable. If your input is sRGB, it gets converted into the working space, which uses different primaries, so the ‘pure’ red, green and blue of the circles are no longer ‘pure’. Then, you rely on the colour picker, but:
As the global color picker runs at the end of the preview pixelpipe, it receives data in display color space then converts it to histogram color space.
I think the output colour profile is also applied, since I see the processing message:
[dev_pixelpipe] took 0.031 secs (0.227 CPU) [preview] processed `colorout' on CPU, blended on CPU
So, D65 sRGB input → D50 Rec 2020 → channel mixing → D65 sRGB (output) → display space (with whatever illuminant white point) → histogram space (probably D65) → colour picker.
In other words, before you applied the channel mixing, the colour picker did not show numbers which would become direct inputs of the mixing; after you made your adjustments, it did not show numbers that were the direct outputs.
So, you were exactly right here:
Note that when @s7habo uses the mixer, he does not make precise calculations; he’d apply his general knowledge of colours, and maybe glance at the picker to check for dominant colours and some ratios, and then eyeball the situation: ‘we mix a bit of x to y, but now there’s a touch too much y in z, so we need to tweak that a little’, not ‘we added 7.2% of x to y, but now there’s 1.3% too much y in z’ (sorry about the horribly jumbled example, Boris).
Ok, thank you for a quick response….
.
So by pulling the blue slider in Darktables channel mixer you affect the blue colors in the general direction you want but you may also influence the red and greens to some extent.
This comes as a surprise (to me at least) and it’s not the impression you get when you read the documentation and study the matrix multiplications.
This tab:
… sets how much of the value of the red, green and blue channels to mix into the red output channel. Moving the blue slider here adds or removes red to pixels that also contain blue (the higher the blue component, the more red will be affected).
This, on the other hand:
Here, moving red (or green, or blue) will affect the blue channel depending on the input red (or green, or blue) channel.
Suppose you have a pixel that has D50 Rec 2020 values of [20, 0, 70] (the ‘trouble’ is, you’ll never see those values displayed anywhere in darktable). No matter which (output R, G or B) tab you select, the pixel will be unaffected by changing input green on that tab, but will react slightly to changing input R and much more to changing input B.
I just generated this from a script but it should be srgb …
If you set up DT to minimize and gamut cleansing and colorspace conversions by setting your display, histogram, picker and working profile to linear rec709 you can explore the sliders and see basically what you would expect …
My display profile will result in the r g and blue not being free of some contamination from one of the other channels… its small and it happens because of the way the pipeline is organized and since the display profile comes before the histogram profile certain profiles can modify the data hitting the histogram profile… setting the display, working and histogram profile remove that…
Green output channel as an example
GG = 0
Leave green there and tweak based on red…GG =0 RG=1
Do the same but with blue…GG=0 BG =1
Reset green to full and also add green to red and blue RG=1 GG=1 BG=1
You can try various combinations… negative values for sliders can sometime be interesting as you can add say enough negative blue to the reds to make them go to black…
Not sure if this helps at this point or if you are all good with how things work… just ignore this post if it is not of use …
Screenshot 2024-06-23 105457.png.xmp (7.8 KB)
Thank you for all your effort.
I had no problem getting familiar with channel mixing in Photoshop, it works just as the theory goes.
My problem was to understand why channel mixing apparently doesn’t work (strictly) according to theory in Darktable. I think that @kofa has explained that in great detail.
Ya that was why I set it up to account for the pipeline and colorspace nuances to demonstrate that it does actually work the same when you account for the defaults selected for the various profiles that darktable uses to both process the data and then present that in the color picker…
New episode: color equalizer module
Finally, after quite a long time, a video again.
Excellent !
Excellent video. The transformation of the leaves was simply amazing
Thank you for this excellent presentation, especially on the advanced options of the color equalizer. I can already imagine some use cases for a bunch of images within my collection
Thanx for this tutorial. I left colour equalizer aside in the past, because I thought the colour zone modul is better. I still think that, because it is more flexible regarding the zones you want to edit. The fixed node distance is not to my taste. Anyway, watching your video shows, that leaving this modul simply aside is a mistake. There are many great options, which gives you a lot of possibilties, which are probably quite hard to achieve with the colour zone module.
A big thank you to you and to the developers! 
I have to thank you for all the improvements of the module and especially for the nice teamwork! 
I see you prefer the node interface over slider interface… or do you just like it compact?
