Hi, I’m loving Darktable 3.2 (well, 3.3.0+13~ga4325917f). I’m surprised to find that enabling the channel mixer without making any adjustments in it causes changes in very bright pixels, especially in the sky. I only see this when filmic rgb is enabled. The patch of sky is pretty blown out with characteristic cyan overexposed colors, but filmic does a good job of getting it under control, until the channel mixer is enabled. Is this a bug, or inevitable at extreme brightness ranges?
Thanks,
Tim
Actually, on closer examination I see the behavior even when filmic rgb is not enabled.
Tim
Bear in mind that you need to be careful with channel mixer because it can cause clipping to occur if not used with care. When using channel mixer I usually try to position it before exposure in the pixelpipe and check that it’s not clipping anything before enabling filmic.
There should hopefully be a new version of channel mixer in v3.4 that will not have this limitation.
In the meantime a workaround could be to use an instance of exposure module to reduce exposure before channel mixer, and a second instance after channel mixer to restore exposure to the required level.
What is the channel mixer doing when all its parameters are 0.0 or 1.0?
So if we look into the source code, we can see that there are 3 modes:
RGB mode: multiply the input RGB values by a 3x3 matrix, and clamp each output channel to be within the range [0.0, 1.0]. By default, the 3x3 matrix is the identity matrix, meaning that normally output will just be a copy of the input, but the channel mixer will chop off any output values <0.0 or >1.0 and clamp them at min 0.0 or max 1.0 respectively.
Greyscale mode: take a weighted average of the RGB input channels, clamp it to be within the range [0.0, 1.0], and set the output to be this same clipped weighted average value for all three channels (when R=G=B in a well-behaved colour space, this results in some shade of grey)
HSL mode – this is very strange mode, you can control how much each of the RGB channels can shift around the H, S and L output, but there is a really weird behaviour where only the red channel contribution is clipped to [0.0, 1.0], but not the green and blue channel contributions. Very likely this is a bug, but I guess this will be addressed in the channel mixer “reboot”. I’m really not clear what sort of use cases this mode is intended to address.
Does that answer your question at all?
Thank you very much for the explanation; I should have read @elstoc 's response a little more carefully. I looked at the source code but didn’t realize the implications of the clamping. Clearly I have pixel values >1.0 in my bright sky; filmic rgb does something appealing with them, but it can’t if the channel mixer clamps them first.