# Re: [Gimp-developer] HSL Color Picker

```   Date: Sun, 31 May 2009 20:56:25 +0000
From: Omari Stephens <x...@csail.mit.edu>```
```
Omari Stephens wrote:

Mockup is here:
http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/hsl-doublecone.png

Note that when I mention "HSL" below, I mean HSL with its
traditional coordinate system, as depicted in [1].

Also note that this is a quick transformation away from the RGB
color cube, [2], so many nice properties of RGB are shared by this
representation.  The lightness axis is just one of the major
diagonals of the cube.

The lightness axis is indeed the major diagonal between black and
white, but the rest of the transformation isn't particularly easy.
The circle at the join of the cones represents the other 6 vertices of
the cube and the 6 edges connecting them, but that doesn't seem like a
simple transformation.

- Similarly to the previous point, this representation matches
our perception well.  Consider any two points in this
representation, in HSV, in HSL, and in RGB.  This
representation and RGB are the only ones where the length of
that path MUST correspond to the ease with which we can
differentiate between the two colors at the endpoints of the
path.  That is, the magnitude of a segment corresponds
naturally to important aspects of our visual system.

Agreed.

Of course, there are always drawbacks:

- This requires more computation to use because of the "odd"
shape of the space of valid coordinates.  That is, not all
valid coordinates are valid colors.

over half) of the color space unused and functionally meaningless.  I
agree that this representation is more accurate, but functionally it
seems more difficult to work with.  Think about the UI implications.

- HSL and HSV are in wide use, and this is neither HSL nor HSV
(though it's just a coordinate transformation away from both
HSL and RGB)

It's a simple coordinate transformation from HSL:

H' = H
S' = S * (1 - ((|L - .5|) * 2))
L' = L

but it's not any simpler than RGB->HSL.

Operationally, I suspect a problem with this is that transformations
in this space that increase saturation will tend to amplify chroma
noise (which is more prominent in dark areas) more than
transformations in HSL space.  In principle, this isn't true, but in
practice I suspect it will be.

I think this space has a lot in common with the HLK space Gutenprint
uses for its HL transformations (for additive colors HLW would be
used).  HLK is computed as follows:

K = min(C, M, Y)
C' = C - K
M' = M - K
Y' = Y - K
(H, L) = HSL(C', M', Y')

Note that S is always 1 in this case, so it's ignored.  I'm not sure
what S transforms in this space would be.  H transforms are the same
as in HSL space, but L transforms that are based on hue yield better
results (you don't want L transforms where L' = fn(H, L) to operate on
the gray component).  Also note that for K close to 0 or 1 there's a
limit on the value of L similar to your S'.

--
Robert Krawitz                                     <r...@alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail l...@uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
```