Here are a couple to try ??
For this synthetic test, color zones - hue tab might work better, maybe since color balance rgb is designed for an other kind of workflow.
Thanks, but darktable does not support svg files.
Tried with png one, guess found some bug, on 89⁰ shift got blues with 43k saturation value (HSL)
But yet again, i can’t understand why visually colour wheel does not rotate on hue shift value?
Here is pure cyan, if i set +5⁰ hue shift in color balance, hues value of cyan sifts only by 1.57⁰
Also here is original HSL values of primary colors, and after 1⁰ hue shift by color balance rgb
I’m afraid I have absolutely no clue about the science behind that stuff, so I can’t help with that. But here are people with expertise who will propably raise their hands.
1 Like
Thanks anyway. Hope i’ll see them.
1 Like
I think color balance rgb does not work in HSL.
Switch the histogram to vectorscope, and apply the rotation. You’ll see a kind of rotation there.
Now, whether that makes the tool less usable, or simply different, I don’t know.
According to the documentation:
hue shift
Rotate all colors in the image by an angle over the chromaticity plane, at constant luminance and chroma. You can use this control to remove spilled colored light on a subject or to quickly change the color of some object. This setting is usually best applied locally, using masks.
So maybe it’s more suited to fix subtle colour casts than to actually rotate colours (the suggestion to mask the effect reinforces that, I think).
Just guessing, but wouldn’t the effect of a rotating colorwheel only work if all the colors it contains had the same brightness?
Looks like the brightness of the different areas is not affected by hue shift, so it should be impossible to get the same color on the opposite side.
5 Likes
*Colorbalance rgb, hue 180:
*Channel Mixer (Color Calibration) with inverted colours:
RED (R -1, G 1, B 1), GREEN (R 1, G -1, B 1), BLUE (R 1, G 1, B -1)
You will notice a large black patch in green (now magenta). That is because the green part of our gamut is far larger than the magenta, and when you invert, you go out of gamut. It goes black because of the way color calibration deals with clipped colors, which is different to how other channel mixers handle clipped colours (or don’t).
*Channel Mixer (Color Calibration) with a compromise on the inverted colours to avoid the black clipping:
RED (R -0.3, G 0.65, B 0.65), GREEN (R 0.65, G -0.3, B 0.65), BLUE (R 0.65, G 0.65, B -0.3)
*For reference, Colorbalance hue shift 180 with blend mode ‘chromacity’ is very similar:
3 Likes
Might be useful to do comparisons with @jandren 's constant-luminance triangle, to avoid some of the luminance concerns raised.
@Entropy512
What is that triangle about?
@Soupy
Am i correctly understand, that black patch gamut may be displayed with that picture?
@apostel338
Yes, it seems to be true. Then i guess Darktable has no rude color messing modules)
One thing to keep in mind is the axis you use for rotation. “Rotating a plane” only works as expected (i.e.(without tilting it) when the rotation axis is perpendicular to the plane. AS far as I know, that’s not guaranteed in any of the colour models used, nor is it clear how the “hue plane” is cut/projected.
So, unless you are sure that your model is what you want:
- i.e. a polar representation
- with hue as the rotation,
- one of the remaining two axes in the plane, and
- the third perpendicular to the plane,
you’ll get unexpected effects rotating your colour wheel, as you will also change the two other values (and not just the hue) for each point. And as important, even if you create your colour wheel correctly in one colour system, it doesn’t have to be correct (for this use) in a different system (as systems differ in how they define their basic axes, in lenght and in orientation relative to other systems)
I don’t see a clear specification of what system is used to create the colour wheel, nor in what model it is rotated.
2 Likes
@Mikh_B3d
Yes those are good visuals! In regards to the first one, I don’t think it is all out of gamut Magenta that goes black, rather just the Magenta that produces negative values. The non negative out of gamut values get shoved back in (by algo? By rendering intent? By display? Not sure), thus producing clumps of Magenta without fine gradients (Compare my second channel mixer hue wheel with my second color balance hue wheel, for example. Still some Magenta OOG in the second channel mixer version me thinks). Someone can correct me if I’m wrong.
1 Like
My guess is that there are attempts to keep things like ‘colorfulness’ more persistent , and/or the luminance/brightness of the colors. As in , there is ‘perceptual’ studd going on.
And then all colors don’t respond the same , which causes weird results if you are working on images that are computer generated.
The color calibration comes to mind , when people expected a pure channel mixer but that’s now how it works.
More and more parts of Darktable are meant to be used in the context of a light capture , not computer RGB values as in an ordinary image. Trying to use Darktable for things normally done in an image editor can sometimes cause weird results .
What do you mean by " ‘perceptual’ studd (stuff)". The manual states that color balance RGB works “in a linear RGB color space [which] exhibits a uniform spacing of perceptual hues while retaining a physically-scaled luminance”. And at output colours can be pushed back into range by changing chroma and lightness at constant hue. So that should give the expected results here (within the limits of the colour spaces used…)
Keep in mind also that computer RGB values are usually display referred, and can represent very saturated colours. Those can easily get out of the range of valid colours when manipulated in another representation.
As an example, look at the limits of the sRBG colour space. There are colour spaces that are enough larger that you can “rotate” the ‘sRGB triangle’ as much as you want without getting outside that colour space. But you can’t then go back to sRGB and hope to have all your colours intact as you rotated them out of the range sRGB can present. (even a rotation of 1° in the shown plane is enough to lose some colours).
Color balance RGB has built-in gamut mapping to avoid creating crazy colors.
When you rotate hues, you do so at constant luminance and chroma. But nothing guarantees than the new hue at same chroma still lies within the working RGB space gamut. So it gets clipped.
To avoid this, you need to reduce the global linear chroma. But ultimately, this is not very suitable for large hue shifts. Hue is an angle, in 3D color spaces, and you will have an hard time to blend large angle shifts smoothly.
1 Like