Date: Sun, 31 May 2009 20:56:25 +0000
   From: Omari Stephens <>

   Omari Stephens wrote:

   Mockup is here:

   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.


   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.

What I don't like about this is that it leaves a large fraction (well
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                                     <>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail
Project lead for Gutenprint   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Gimp-developer mailing list

Reply via email to