Date: Sun, 31 May 2009 20:56:25 +0000 From: Omari Stephens <xsdg@xxxxxxxxxxxxx> 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. 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 <rlk@xxxxxxxxxxxx> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
