No, if i multiply
┌ 1/3 0 0 ┐ ┌ 255┐
│ 1/3 0 0 │ X │ 0 │
└ 1/3 0 0┘ └ 0. ┘
The result is
┌ 85┐
│ 85│
└ 85┘
So the red turns to dark gray.Just to check, which version of Darktable are you using? There was a bug in RGB channel mixing that was fixed in Darktable 3.4.1.
I’m using 3.4.1 on Mac
Had a closer look at your screenshots - you’re entering the coefficients in the wrong place. Think of it this way: in the R tab you see the coefficients which are multiplied by input red, green and blue to form the output red. In the case of your matrix, you would have to enter the nonzero coefficients in the first slider of the R, G and B tabs and zero out the others.
Edit: i.e. each R, G, B tab defines one row of the matrix even though the positioning of the sliders makes it look like a column.
and
However I have found this not to be true. For instance, with the above image provided by Nicolas, turn on color calibration, make sure gamut compression is 0, negative values are unticked and adaptation is none (bypass) in cat, then in R tab, reduce R slider from 1 > 0.5.
We see our purple patch has changed from 152,155,199 to 56,159,200. Sure, changes in G and B channels are minimal, but nonetheless, all three channels have changed. Now increase G slider in G tab to 1.5. Values become 8,199,197. In this case, we have not just a dramatic change in G channel as expected, but R channel also.
There are a couple of reasons you might observe this:
- is the color picker working in the same RGB space as the pipeline? Normally it uses the histogram colourspace, which may be set to something different to the pipeline. Then, transforming to a different set of basis vectors will cause the values to shift
- are there any modules active after color calibration, such as base curve or filmic? These modules again can cause values to shift as they do their job.
I have histogram profile set to export profile, in this case sRGB. If I change histogram profile to working profile, I still get a shift in both R and G channel when shifting G slider in G tab. If I change histogram profile and output profile and export profile all to working profile, in this case linear rec 2020, there are still shifts in both R and G channel, although much less pronounced.
There are no other modules between color calibration and output profile.
@nwinspeare: I’m not a darktable expert, but I think your matrix is transposed, as @flannelhead says. According to your screenshot, you have set the output red channel to various factors of the input channel. Assuming your other multipliers are zero, then you have set this matrix:
┌ 69/152 203/152 129/152 ┐
│ 0 0 0 │
└ 0 0 0 ┘
If you want a gray output, then the values your set in the “R” tab can be different to each other, but you should set identical channels in the “R”, “G” and “B” tabs.
Its a fair observation there is certainly cross talk so maybe this module doesn’t work like a classic display referred channel mixer. Also if you say drag the red channel in the red input or any other similar far enough down things go black even though in this case the image should still have blue and green so to me it doesn’t behave as a normal standard channel mixer…
Yes, I opened an issue in GitHub recently about color calibration returning black, which I guess is the same thing you’re seeing. (Edit: Link here: Color Calibration Channel Mixer produces black patch · Issue #9076 · darktable-org/darktable · GitHub) My understanding from that discussion is if you push normal channel mixers into negative xy values they’ll return a blob of saturated colour at the gamut border, whereas the colour calibration channel mixer clips to black. This is by design, so it is up to the user not to push things so far.
Edit: Although why in some instances turning down R slider in R channel leads to the whole image going black, instead of just the R channel, is beyond me. It’s also a weird phenomenon that turning down the channel slider (Eg. R in R, G in G) will see that channel approach 0 (RGB value), until you hit 0 slider value. Once you go negative slider value, that channel value starts increasing again, before the sudden black. This doesn’t happen with the old channel mixer. There, once you go into negative values on the slider, the RGB value just stays the same.
I wonder if it is something about the scene referred workflow. I’ve noticed also when blending in a single channel - for instance R - that if you take that individual channel down to 0, then the module has absolutely no effect, when you would expect it to still have an effect on both G and B channels. I don’t know if that is a related issue, or a different one.
There is a certain flow of data through the profiles right now and I think this is the source of the shift I think. If you set your display profile to match your output profile it behaves without crosstalk at least with the sliders in the positive range. Extreme negative ones produce some weird results or maybe expected but other channels will change values in the negative range and then suddenly the color goes to black. I think its is related to a number of issues where the data goes through the display profile and then to the histogram profile so it can be like there is an extra step of processing… There were a lot of discussion around issue like this one [RFC/WIP] Move overexposed before colorout by flannelhead · Pull Request #8051 · darktable-org/darktable · GitHub and others in this part of the processing pipeline…
Since matching the display and output corrects the behaviour I think this is the issue… but really I just stumbled on it by fiddling around
PS @Soupy Just see if you see the same thing ie it behaves if you make your display and output the same…setting both to sRGB is the easiest…but for fun I set my monitor profile as the output profile so matched those and again it seemed to work with not crosstalk…Also it would show 0 at 0 value of the slider and then negative values if you left clip off and it stayed at zero if you selected clipped. When they are not paired I would see 0 values for the channel with the slider above zero and sometimes positive values with the slider below zero…So again seemed more predictable when you matched those profiles. It did not seem to matter what the histogram profile was.
1 Like
I set my histogram and output profiles to linear Rec.2020, same as the working profile in the input profile module, and if I adjust the red slider in channelmixerrgb, only the red value on global colour picker changes. There was some math error that was corrected a week or two back, maybe you are still using a buggy version of DT?
1 Like
Could be. I am on dt 3.4.1, so wouldn’t have any corrections made in the last week or two. I hope this is the solution, as having to change display profile for this to work correctly as per Todd’s post doesn’t sound ideal.
Edit: Having tested some more, with output and histogram matching working profile (linear rec 2020), and display my calibrated profile, the G slider in G channel effects only G value when slider is >0 and <1. For negative values, or values > 1, only then does it effect the other channels.
I have set display, histogram, and output profile all to sRGB. I put a solid block of one single colour on screen (using colorize module) - a green. The only slider I alter is G in G channel. It effects all three RGB values quite dramatically, whether positive or negative values. However, if I set display, histogram and output profile all to linear rec 2020 (working profile), it behaves as expected, changing only the G value, leaving R&B as is, no matter whether slider value is positive or negative.
A curiosity, if I increase G slider to its maximum of 2, I get 472 in the G channel! Given 255, should be max, I wonder if that is one of the math problems fixed recently?
I’m on 3.5.0+2210. I will update and see. I have to have the display and output matching. Your setup doesn’t seem to work with this build. And it seems it does not matter what I set them to as long as they match so this seems different from @Soupy with 3.4.1 as he seemed to need rec2020. There is a lot going on with the introduction of the vectorscope etc to tie all this color stuff together…
I think the math errors were here, including problems with color space conversions:
(the channelmixerrgb will convert RGB->XYZ, do some gamut mapping and maybe clipping, then back XYZ->RGB)
I tested on 3.5.0+2382, plus some dirty stuff (related to CR3 support I think).
I’m tired and off to bed just built a few min ago…on my windows built. Output and display have to be set the same doesn’t matter what you use. If they are not it doesnt isolate the channels
Thanks, I can get it working now. In reality then the formula is
What is the business about the sum of the coefficients being equal to 1 ?
(By the way, I put input and output the same and I use no other modules of course.)
Thanks,
Nicolas.
2 Likes
There are two distinct issues discussed in this thread. The first one is that OP had the matrix transposed (i.e. coefficients entered in the wrong place).
The second one is that in some configurations changing the coefficients in R tab seem to affect the other channels, G and B. This happens because there is gamut clipping taking place somewhere in the pipe. The color calibration module itself has two settings that do this: gamut compression if there’s a nonzero value and clip negative RGB from gamut if checked (unchecked seems to cause quite a bunch of problems further along the pipe e.g. in contrast equalizer). The basic channel mixer preset has the settings so that there’s no gamut clipping done in color calibration.
Then gamut clipping may also happen when the image is transformed to the display profile. Darktable built-in profiles generally don’t seem to cause severe clipping, but for example if you have a XYZLUT profile generated by a calibration software, there’s going to be clipping and you’ll see it in the global color picker because the colors are converted to display profile in an intermediate step before converting back to the histogram profile. This is why setting the display profile to the same as the working profile helps.
Then of course, if the histogram profile is different from the working profile, one is going to see “cross talk” between the R, G, B channels because the primaries in the picker and the color calibration module are different from each other.
I’d be very surprised if the output profile affected any of the color picker values Darktable, because the output profile (actually called export profile and set in the output color profile module) is only used during the export.
Depends on the notation, I guess. If e.g. by Rg you mean the “input green” value on the R tab, then yes.
If you only care about the proportions of the coefficients forming e.g. output red but would like to approximately maintain the overall luminosity, then I guess the normalization can be used. Perhaps there are also other uses.