Robert Krawitz wrote:> 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. Oh, yeah, it's not trivial to well-define the transformation, for sure. But geometrically, in a sort of hand-wavy manner, it's not a radical transformation — colors don't move too far away from their former neighbors. > - 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. Yes, it does leave large parts of the _coordinate_ space invalid. Admittedly, I've primarily been thinking of this as being useful for an RGB color picker, and less as a real color space in its own right. Also, yes, the UI would be tricky. Of course, we have other places where a constrained relationship needs some UI love (the image scale dialog, for instance). Of course, the real question is probably "what orthogonal vectors can we use to precisely span this space such that the meanings of the vectors are also useful?" If there's a good solution to that problem, then the UI is easy. > - 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.True, I think I misspoke by saying "and RGB" > 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.As far as using this space as a color space, it all depends on where you put the bits, right? I believe this suspicion is false when considering a transformation at L=0.5 (that is, this space will undoubtedly have at least as much bit density on that circle as HSL does). In the other cases, I think it depends on what you consider to be "saturation." If you mean the "S" in HSL, then yes, you're correct. I would question the utility of a purely-S increase, though — what would someone be trying to achieve by doing that? Certainly, it doesn't seem like an operation a photographer would undertake very often. The photographer would likely increase saturation while making lightness more neutral (to use my prior terminology, they would want to create a color that is more or less psaturated). > 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'.I need to do some more thinking to wrap my head around all this :o) --xsdg _______________________________________________Gimp-developer mailing listGimp-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
