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.
In linear Rec2020 you might check the rgb values. For the pure red in the circle - it contains green and blue values …
sRGB is non-linear, it will never work. At least use Rec709 linear if you want to test anything.
Quality insurance has been done by monitoring the delta E through the color calibration process with color checkers. The module works as it should. You just need to let go on the patch-wise meaning of colour.
OK, so the module does not work with the traditional RGB model.
In that case, I don’t think that:
- the channels on the UI should be called R (red), G (green) and B (blue)
- the module should be introduced as a replacement of the old channel mixer.
Instead:
- warnings should be added, saying ‘this is a highly technical module, don’t mess with the sliders unless you know what they mean’
- presets resembling (in name) the old channel mixer presets (like G<->B swap) should not be provided (or should be provided under a different name), as if you say the preset swaps green and blue, but instead it turn green into blue, blue into purple and red into black, everyone will be baffled:
- docs should be updated. You know that people don’t read the docs, but even if they do, currently the documentation does not mention that they should not expect that reducing the ‘g’ value on the ‘colorfulness’ tab takes greens closer to grey (rather, it will make purples duller), or that swapping colours will not work like it does in traditional channel mixers.
I don’t actually use the channel mixer, neither the old, nor the new (I only use the CAT tab); I just gave it a try now and was in for a surprise. If it’s a technical module, please mark it as such. Keeping the old channel mixer alive would be a good idea, I think, even with its shortcomings.
Testing (QA ‘via monitoring the calibration process with color checkers’) and bugs: bugs are part of coding. No amount of testing can guarantee 100% correctness (like how the bug @neuralyzer found crept through). My code usually has >90% test coverage, still, sometimes I run into bugs in production. That said, I believe you when you say that based on your understanding, what happens is the expected outcome; I find it highly unlikely that after so much discussion, thinking and scrutiny major bugs are lurking in the code.
Thanks for all the great work!
5 Likes
I do, and I’m very grateful for the new 3.4 docs (especially as they came out in time for the release - that in itself was an improvement on the old docs).
3 Likes
Yes it does. No RGB is What You See Is What You Get, no RGB translates image colors to GUI sliders, that’s why we use hue/saturation/luminance models when we need image color ↔ GUI controls matching. Any RGB is only just a 3D splitting of a light spectrum inspired by cone response, so no RGB is actuall red green blue but merely a metaphor for the light spectrum decomposition method. Blame others for the name choice, I’m only abiding by the standard.
Channel mixing is designing a light filter, it’s a cross-talk tool, not an independent channel boost, it’s standard and similarly implemented in every image application as a 3D matrix dot product. If you know how to use one, you know how to use all the others. It’s a powerful tool.
Problem here is on understanding what RGB means, what to expect from it, and how it works.
No, it’s a standard color grading tool. See Da Vinci Resolve, Lightroom, Filmlight, etc.
Again, it doesn’t turn green into blue, it swaps channels. You keep using a perceptual framework to describe the effect of a light manipulation, it’s going to fail. There are no colors in RGB. It’s light.
I need to double check the channel swapping, because R is not supposed to go black, but if you look carefully on your test image, there is a fringe around the black R letter, so you are using a gamma-encoded RGB space, which is not additive light, which behaves like shit, which I spend my weeks repeating. sRGB has nothing to do within the pipe.
That bug was in the user param → algo param binding, not in the actual pixel processing code though.
1 Like
I’m sorry I’m getting on your nerves. I believe I was using linear Rec2020:
And here is the TIFF I used as input, created in Gimp, with linear Rec2020 assigned as space, created by painting a white R on one image, G on another B on the third, merging them as the R, G and B layers of the image. I may have made a mistake, of course.
rgb.tif (12.0 MB)
And the old module:
1 Like
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 ?