Re: [Gimp-developer] Saturation layer blend mode

a few frequently-used color systems:
HSV/HSL/HSB as a color "volume" looks different from RGB which looks different from CMYK.
HSV/HSL/HSB: 2 cones with bases glued together. range of top to bottom of cones is Brightless/Lightness/Value and ranges from black to white. center to horizontal outer edge is Saturation, angle around horizontal circle is Hue (typically based on the 3 primary colors Red, Blue, Yellow).
RGB: 3D cube. each axis represents a range from black to Red or Green or Blue.
CMYK: 4D cube. each axis represents a range from black to Cyan or Magenta or Yellow or Black.

as you can see, representing these 3 color systems well is a challenge.  for instance, how do you flatten out HLS?  RGB (3 cliders or red axis+blue axis + green slider and dropdown to change scheme)?  CMYK (4 sliders)?

From: yahvuu <yahvuu gmail com>
To: Tom Hall <tahall256 gmail com>
Cc: gimp-developer-list gnome org
Sent: Thursday, October 27, 2011 7:52 AM
Subject: Re: [Gimp-developer] Saturation layer blend mode

[re-posting to new mailing list]

Hi Tom and all,

Am 23.09.2011 02:36, schrieb Tom Hall:
> I would regard the saturation layer blend mode's result as unexpected

the good news first off: the upcoming GEGL implementation of the
"color space" layer modes uses LAB color space which gives much
more useful results, if at the price of consuming more processor power.
You can test-drive the new behaviour using "View -> Use GEGL" on a
development version of GIMP.

The current implementation, in contrast, is based on the HSV color model
which has some rather unpleasant characteristics.

For example, take a saturation blend of two gray orthogonal gradients,
created with the default "use dithering" setting:
The resulting image[1] is rendered with a stripe of highly saturated
pixels, even though all source pixel are gray.

Accordingly, decomposition into HSV or HSL exhibits similar artifacts:
Decomposing a gray gradient[3] using Colors->Components->Decompose
gives unexpected non-black pixels in the saturation result.

So what's behind all this?
It's not a bug in GIMP; it's a flaw of HSV/HSL, which does not properly
reflect human perception of color. For example, consider the following
example of a RGB <-> HSV correspondance (assuming 8-bit RGB with range

RGB            HSV
---            ---
R = 0          Hue:        120°
G = 1          Saturation: 100%
B = 0          Value:      0,39%

On screen, this color is perceived as almost black, mostly uncolored.
Despite that fact, the HSV result claims full saturation.

In summary: don't use cheap HSV when you can afford a fast CPU :->

best regards,


Am 23.09.2011 02:36, schrieb Tom Hall:
> Colours with a saturation of zero (Greys) have no hue value (stored as
> RGB). When increasing the saturation of such colours, "saturation" layer
> blend mode assumes they have a hue of zero, i.e. red.
> I'm assuming using a HSV or HSL colour profile might avoid this (by
> having a redundant hue value even when saturation is zero), but I
> haven't found any such profiles to test.
> Note that increasing saturation using the hue-saturation tool does not
> give the same result: white remains white, grey remains grey.
> I would regard the saturation layer blend mode's result as unexpected
> behaviour for the following reasons:
> - Making assumption of non-existent hue data.
> - Not useful to end user. Controlling the saturation of parts of an
>    image via a saturation layer doesn't work if the image contains any
>    white (or grey) pixels. For example, an image of a green apple with
>    white highlights will end up as a green apple with red or pink
>    highlights. (With discontinuity being introduced as very pale green
>    suddenly reaches pure white)
> - Behaviour different from tool with same name.
> Regards,
> Tom
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer lists XCF Berkeley EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

gimp-developer-list mailing list
gimp-developer-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]