Colour Calibration (channel mixer question)

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.

Watch the black > white gradient on the left.

When sum = 1, neutral, no cast

When sum > 1 in R channel, red cast

When sum < 1 in R channel, cyan cast

This rule is true no matter which slider you shift, in whichever channel (though the colour of the cast changes by channel). Only when sum = 1 do neutrals remain neutral.

Not just about about maintaining overall luminosity, but maintaining neutral greys, not introducing casts. Ticking normalization also achieves this, although the mechanism is a bit unknown to me as it doesn’t alter the user entered values. So it is possible to have neutral greys with normalization ticked, even when sum <> 1.

1 Like

It is far more usual to use column vectors, in which case you need to transpose the matrix and put the in vector to the right of the matrix, so you have out=Axin.

Could you share this colorwheel?
I think that is very useful in order to check these modules.

Sure thing.

3 Likes

Thanks for your detailed response…

I think its the display profile step. If you set it to match your output profile then I see a more standard behaviour with the other channels not being affected. One note from your comment above, its not only the red for me if my display does not match the output then any R-R or G-G and B-B sliders will show cross talk in the other channels. I have working and histogram set to Rec2020. Just as proof not that it is correct as long as I use the same profile for display and output then I don’t get the cross talk otherwise I do.

EDIT: I built DT last night as I was 12 or so days behind. I did some more combinations paying closer attention. From your comments (darktable profiles more reliable) it seems like my display profile is indeed the issue. If I replace it with any of the DT profiles then it does not show the cross talk. So its not that the input and output need to match its my display profile that is causing the issue. I have 3 system, manufacturer icc, and one modified by calibrize screen calibration software. These ones are causing the issue. I must have lost track and thought they had to match as I was swapping in DT srgb rec709 rec2020 and it seemed like they needed to match but what I was doing was getting my display profile out of the mix during some of the swaps. I guess my display profile is managing gamut differently or clipping?? I’ll have to try to figure it out but I guess using sRGB for the display profile for now wont kill me if I want to use the channel mixer.

Display profiles quite usually are implemented as so-called color look-up tables. Clipping takes place because the look-up table data only spans a limited color space. On the other hand, the Darktable built-in profiles are implemented as a combination of matrix and possibly a non-linear tone curve. For those profiles, most of the Darktable color conversions work in “unbounded” mode meaning there’s no clipping done at the boundaries. That’s why the conversion to such a profile doesn’t cause those “cross talk” issues (at least as much) that have been demonstrated in this thread.

On the other hand, depending on your use case, you may just as well stick to the existing calibrated display profile you have, knowing the limitations of the color pickers. At least I’m currently pretty happy sticking mainly to the image I see on the screen, not that much following the numbers.

1 Like

Your spot on. I had been using the channel mixer as I essentially know how it works to tweak images and color casts. It was only when I tried to take one of the purple patches in a color checker and make it the purple rgb triplet that @nwinspeare was looking to get that the crosstalk made it very hard to dial it in which I thought would be easy. It may warrant a bit more in the documentation as this tool confuses many to start with and then when they are expecting only one channel to change it might create cause for pause and uncertainty.

I appreciate your time and comments as always you provide amazing feedback. Thanks so much.

3 Likes

Sure, which specific parts of the documentation are unclear?

I’m not smart enough… or more accurately, too lazy…so I just stick to the concepts over the numbers.

I am saying the tool itself (ie a channel mixer) is not easily mastered as you can clearly see by scanning the many questions and forum threads over the years. I think the documentation does a good job explaining it. There are just behavior’s at least with my configuration, for example if I use my system profile or manufacturer icc profile I cannot get any of the channel values to zero even going quite negative on the slider and then things will often go quickly to black. It may be that the tool is fine but it seems a few others have notice some interesting responses as well.

So for now I would say the opening statement quoted below is not currently accurate . I have used a channel mixer in a few programs and if I move the green slider in the green output channel I should not see all the red and blue channels changing as well. The degree to which this presents is impacted by what I choose for my display profile. So its a bug or its a side effect of the way the values are routed to the display/histogram profiles but still it would not conform to this first statement if this is functioning as intended. If I have a pixel selected and I move the green slider in the green output channel only the green value should change to become the sum of the correction as applied to the red green and blue input channels and you should not see not all three pixels changing if indeed only green is being affected. I am doing this in bypass mode with gamut compression off and normalization off so to me those conditions would be the “standard” rgb channel mixer.

There were some comments provided to indicate that the DT color profiles are more robust and more likely to behave well and I think this is true as when I substitute one of them for my display driver the results seem better.

It could just be my configuration but it appears also it has been the case for others and so the issue is on our end or a bug or a nuance of how it works in DT. If all is correct and as intended so that in DT all pixel values of an rgb triplet can change when moving any one of the r-R g-G and b-B sliders then perhaps this should be explained.

I’ll put together an issue report with examples and settings incase it is of any use but really it suspect its the position of the display profile that allows for certain display profiles to cause clipping or other gamut issues before the values make it to the histogram profile which will determine what values are reported by the colorpicker…

Quote: The remainder of this module is a standard channel mixer, allowing you to adjust the output R, G, B Unquote.

2 Likes

Ok, I see where this is misleading. It is talking about the output of the module, not the screen output, and this could be confusing. Some clarification can be added.

1 Like