Color calibration - colorfulness

Software darktable
,
#1

Hello,

I was working on a shot of a purple flower on green background, and wanted to darken and desaturate the background.

image
image757×608 92.6 KB

Using color calibration, I dragged the green down on the colorfulness tab:
image
image757×608 89.4 KB

It appears to me that the flower was affected way more than the background.

I then tried a colour wheel:

image
image757×543 85 KB

Less red colourfulness:
image
image757×543 83.5 KB

Less green:
image
image757×543 83.6 KB

Less blue:
image
image755×541 84.8 KB

The brightness tab works as I’d expect:
Red:

image
image757×543 83 KB

Green:
image
image757×543 81.6 KB

Blue:
image
image757×608 90 KB

@aurelienpierre: is this the expected behaviour?

2 Likes
#2

The green and the blue slider seem to have the same effect. Both seem to act on blue.

#3

Im not familiar enough with the code, but maybe here is a bug https://github.com/darktable-org/darktable/blob/darktable-3.4.x/src/iop/channelmixerrgb.c#L1188 ?

    d->MIX[0][i] = p->red[i] / norm_R;
    d->MIX[1][i] = p->green[i] / norm_B;
    d->MIX[2][i] = p->blue[i] / norm_G;

Just wondering why green is divided by norm_B and blue by norm_G but red by norm_R?

I might be completely off however, since I only looked at the code for seemingly irregular patterns, admittedly not really understanding what is going on. I hope it helps.

1 Like
#4

@kofa can you share your color wheel so that we can test it against a small patch based on @neuralyzer findings ?

#5
2 Likes
#6

I’m compiling a version based on @neuralyzer’s discovery.

#7

I reset the module and applied green desaturation again, but it did not help.

image
image757×608 90.5 KB

Though the affected code was on lines 2396-2397 (master branch). I only did a quick recompile, so if you could double-check, I’d be grateful.

#8

I changed the lines and recompiled. However, it still seems to be the case that the green slider is affecting the blue colors. So unfortunately I can confirm your finding.

#9

Thanks

#10

I can confirm …looking at a color chart image and the color picker the green does not move…only changes happen with Blue primarily…so I would guess this is a bug… @aurelienpierre

#11

Could it be that you expect colorfulness as (almost) the same thing as saturation?

#12

It’s expected because we work in RGB, which is not perceptually even.

F********ck. That’s a typo and a bug. Although unrelated to the problem, but thanks for spotting it !

1 Like
#13

This is what I feared. If there is no hidden bug, it probably means very few people will be able to use this functionality. If there’s a green slider, it seems like a reasonable expectation that it affects the greens.

3 Likes
#14

I’m confused enough by all the terms that mean related things. In fact, Aurélien calls this saturation in the code. :slight_smile:
https://github.com/darktable-org/darktable/blob/release-3.4.0/src/iop/channelmixerrgb.c#L517-L521 (check line 520).

1 Like
#15

Interestingly, when you move the slider (to left, for example) the histogram changes “as expected”. Move the green slider, only the green part of the histogram changes. Greenness of the green parts of the image doesn’t.

#16

Playing a bit with those sliders on an image of a (almost pure red) poppy also showed a marked influence of the adaptation setting. When I put the green at -0.5 in the colorfulness tab (with normalisation ‘on’), I saw:

  • very little effect on the (red) flower with adaptation set to CAT16
  • moderate effect with adaptation = XYZ
  • strong effect with adaptation = Bradford (linear or non-linear).
    With normalisation off, the effects were a lot weaker, but still there (and in the same order).

And using demosaicing set to “photosite color” shows a strong effect of the ‘green’ slider on the red pixels (in colourfulness tab) when using either Bradford adaptation.

1 Like
#17

Well, it is a kind of saturation but not exactly perceptual.

Greenness, in LMS spaces and friends (CAT16, Bradford, XYZ) is more like luminance.

That bug got fixed today. Don’t use normalization modes in 3.4.0 for R, G, B tabs.

3 Likes
#18

I think this is what I noted…despite AP’s comment on perception…the green should change value I would think and for me with the picker on a green square in a color chart the green value in the rgb triplet did not change in the full range of the slider…

4 Likes
#19

Yes it is very strange how the green slider effects blue. However I’ve found that boosting R and B sliders together also boosts green colours, perhaps because most greens in the image also have some amount of R and B?

If anyone wants to boost saturation of only green channel, go to G channel, and set R -0.5, G 2, B -0.5, and use opacity to control the amount. This gives the effect I was expecting from colourfulness. (I assume when the bug is fixed you will be able to just tick normalize, set G 2 and leave the others alone).

#20

Nope.

What you see on your screen is probably sRGB. So your goal is to push R and B of sRGB space. But what you control is R and B of Rec2020 or CAT16 or Bradford CAT spaces. Those control RGB will later be mixed in various proportions to create our final sRGB.

Therefore, don’t get too stuck on the meaning of R, G, B. Call them bullshit channel 1, bullshit channel 2 and bullshit channel 3 if it helps. Channel mixing is not perceptual. However, it blends changes more smoothly than pushing selective hues on color zones, for example. So this is the trade-off.

But you will need to learn the relationship between effect and setting, because the settings are not perceptually meaningful.

3 Likes