I’m sorry I’m getting on your nerves. I believe I was using linear Rec2020:
And the old module:
I’ve reedited some infrared shots of mine using this module’s R and B swap, and I find it works quite nicely.
do you have gamut compression on ?
I used the preset swap G and B, so adaptation is none (bypass), gamut compression is 0, clip negative RGB from gamut is off. I think I should have attached the XMP sooner, to remove any uncertainty. Here it is now:
rgb.tif.xmp (4.4 KB)
The TIFF file is in Color calibration - colorfulness - #37 by kofa
I think there’s the issue. Following the color calibration module code, if adaptation is none, then in the R, G, B tabs R = X, G = Y and B = Z. Now the Y in XYZ is the luminance. If we replace the luminance by Z (~blue) in the mixer, the R letter goes to black because the Z component (and therefore Y in the mixing result) for it is zero.
Switching the adaptation to linear Bradford, the result looks much more sensible:
I wonder if the channel-swapping presets should indeed use something else than XYZ for the space.
Edit: the tooltip of the adaptation combobox says that “none” should use the pipeline working RGB instead of XYZ. Therefore I think it may be a bug here: darktable/src/iop/channelmixerrgb.c at c9e593666015b59b928b676f722446f5bc60acfa · darktable-org/darktable · GitHub
What do you think @anon41087856?
Let me summarize this discussion in my own words to see if I understand. Say you walk into a completely dark room and light a color wheel with one red, one light, and one green light bulb, all of equal intensity. The color wheel looks like it should.
Then, you vary the intensity of, say, the red light. This actually affects all (many?) of the colors in the color wheel, not just the reds. The same is true for the green and blue light bulbs.
The RGB sliders in the Color Calibration module have the same effect as varying the intensity of the individual R, G, B lights in my hypothetical dark room.
Is this correct?
If that is the case, then the preset basic channel mixer should also be updated (it also applies no adaptation), because completely swapping channels is just a special case. But I’d argue that since all modes result in colour shift (easily demonstrated by the swap operations), none of them truly replace the legacy channel mixer.
BTW, in my original post, the starting point of instance color calibration 1 (visible in the screenshot) was also the basic channel mixer preset, so did then reducing the colourfulness of G in fact operate based on the XYZ Y coordinate, luminance?
Please see my edit, it may be just a bug that choosing “adaptation = none” results in mixing happening in XYZ.
However, it is still not correct, as the blue is purple.
In another recent thread Aurelien criticizes a different gamut compression algorithm for degrading blue to purple. So if we want proper accuracy here the blue needs to be blue. I think the various adaptations are primarily designed for cat White balancing, and shouldn’t be used as a kind of hack to try and get the channel mixer working properly. But you may have just used that as an example to point out a flaw in the none bypass setting? Not intended as a proper solution?
Oh yeah, that’s a beautiful bug. Thanks ! Fix incoming… Since the RGB path is not used for WB nor color checker, it was the least tested.
No, you are mistaking reflection and emission. RGB is an emissive model, you work in additive light. If you display a color wheel under some lighting, then your color wheel is in reflection, so you work in subtractive light and it’s much more complicated.
No, what you describe is the RGB slope or gain in the color balance : you dial up or down the intensity of each primary color independently. What channel mixing is, is cross-talk between channels, so what you do is define a red, green, blue boost that is equal to your settings times the original RGB intensities of each pixel. Each input channel collaborates to the output boost.
Say you want to boost the red channel of pixels that are currently mostly green, you go in the R tab and set the green slider > 0. Since that adds red to green pixels, the result is actually more yellow. But it won’t affect the pixels that have barely any green component. That’s different from the color balance R gain, which would affect all the pixels proportionally to their input R channel, independently from the G one.
And because RGB is not color, but light, doing so in different color spaces is going to change the final result because you are mixing different primary lights (just imagine changing the RGB spaces change the color of the light bulbs, the same balance doesn’t give the same result).
But it’s very intuitive if you think of it as a linear change of the vector base in a 3D euclidean space : you rotate the primary colors around. Everyone got lost over the hue diagram because it’s the worst framework to think about the problem. We massage the light spectrum through its 3D decomposition, that’s all we do.
Thank you, @anon41087856 and @flannelhead.
Now just one more, and I’ll shut up, promise. Also in channel mixer mode, without adaptation:
Neutral:
This is the issue that triggered the whole discussion, with the flower at the top, I believe.
Looks like there’s a bug in this post 
I am going to have to read this 10 more times and I still don’t think I will get it. If the @kofa image is pure red R and pure green G and pure green B. I would expect only red to be effected when you remove red. Okay so this is wrong as the changes are happening in the module colorspace and then converted to display maybe?? I am not sure . But in any space how can removing red (so adding cyan??) also seem to remove green to the same extent that it removed the red?? In the first image presented above the green clearly also gets as pale as the red. Why would removing “color” from blue affect pure green?? I am clearly missing something. If the green is not 0,255,0 and some blend of rgb I still don’t think you would see that result. I guess I will re-read this and try to get my head around it… I am bracing for Aurelien please be kind I didn’t use the word intuitive anywhere 
After doing the whole spectral sensitivity function thing, I’m sorry to say that I understand what @anon41087856 is explaining… 
Now, disclaimer, I haven’t studied the tool at all, but IMHO what the dialogue portends is a chromatic adjustment, not really a color adjustment. What you’re used to is a metameric construction, where single wavelengths corresponding roughly to what we’d think of as R, G, and B (actually high, medium, and low wavelengths) are mixed in their respective intensities to produce a notion of a particular color in our heads. This tool is more about the overall spectral contributions, where both wavelength and intensity are moved around (@anon41087856, correct me if I’m wrong). That’s why one sees “non-intuitive” changes…
Thanks Glen, clearly it is complicated and I have some learning to do nevertheless having a module with a slider in a tab called colorfulness and having selections for r g and b will be a misdirection for the vast majority of DT users. If you have a module and a slider then it should behave in a predictable way based on the naming. Maybe I will come to understand this and then it will make sense…so my simple question then is if I have an image and I remove “colorfulness” say using the red slider what is it exactly that i am doing to the image and how does that change with the various possible CAT selections?? Is that a fair question or a stupid one??
Quite fair, I think. One should be able to correlate outcome with input in a meaningful way. The notion of “meaningful” is what’s vexing here, IMHO…
Thanks again. I am going to work through from the ground up to try and figure this out…if I can …no guarantee… I need to grasp this part first Spectrum to RGB Conversion
That’s the part I understand perfectly; in my work I use linear algebra every day.
What I was trying to do (and failed) was to interpret the R, G, B sliders in terms of real-world concepts. In other words, I don’t understand what you mean by RGB being light (which is a real-world concept).
Thanks for the explanation: I will take the time to study this subject and keep trying to find a correlation to the “real world”.
