Re: [Gimp-developer] HSL Color Picker
On Sun, May 31, 2009 at 9:13 PM, Robert Krawitz wrote: From: Christian zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. Munsell anyone? :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
On Sunday 31 May 2009 05:36:00 pm Øyvind Kolås wrote: snip The colors selected in this manner will likely be used in a different color space than the one they are selected in anyways. This means that undefined regions of the colorspace and computational complexity are only a concern of the color picker interface. CIE Lch is another options that can be considered. I haven't studied it but suspect that the current computation of Lightness has crude 8bit/gamma assumptions in it. /Øyvind K. In addition CIE L*c*h* is device independent which would allow the color picker to be color managed (IE. CIE L*c*h* - monitor device colors) and it would also allow for the picked colors to be converted into the correct color space for the image being edited. I think this is an important consideration. L* is the same as L* in CIE L*a*b* and is linear with values between 0.0 for black and 100.0 for diffuse white but higher values are allowed for spectral whites. Hal ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] HSL Color Picker
http://bugzilla.gnome.org/show_bug.cgi?id=584338 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Christian wrote: http://bugzilla.gnome.org/show_bug.cgi?id=584338 A bit more text than just pasting a Bugzilla link would be nice. Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. [1] http://en.wikipedia.org/wiki/File:Color_cones.png More about color theory: 1. Newton Isaac, 1704: Color spectrum. 2. Maxwell James Clerk, 1856: Color gyro. 3. Benson William, 1868: Color cube. 4. Hickethier Alfred, 1952: Color cube. 5. Hölzel Adolf, 1904: 12-piece color cube. 6. Harald Küppers, 1985: Das Grundgesetz der Farbenlehre, Homepage kuepperscolor.de 7. Parramón José Maria, 1989: Color Theory, Wie mische ich meine Farben richtig, Der Maler und seine Farben, Das große Buch der Farben und mehr. 8. Ames Jim, 1996: Color Theory Made Easy 9. Crüger Ingrid, 1999: Farbentheorie und Farbgestaltung 10. Johansson, Donald, 1998: Colors on the Web 11. Franklin, Kirk, 2001: moreCrayons 12. Zwick, Carola and Schmitz Burkhard / Studio 7.5, 2003: Digital Colour for the Internet and Other Media 13. Fraser Tom and Banks Adam, 2004: Designer's Color Manual 14. Greve, Kai, 2005: Die Farbe in der Computergrafik 15. Bachmann Ulrich, 2006: Farben zwischen Licht und Dunkelheit 16. Weber Helen, 2006: Digitale Farbe, Handbuch Farbkomposition and Handbuch Farbkomposition - Webfarben. 17. Gekeler Hans, 2007: Handbuch der Farbe 18. Welsch, Norbert and Liebmann, Claus Chr., 2007: Farben: Natur, Technik, Kunst 19. Hammer Norbert, 2008: Mediendesign für Studium und Beruf ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
On Sun, 2009-05-31 at 17:53 +0200, Christian wrote: Looking at http://bugzilla.gnome.org/attachment.cgi?id=135649action=view my first feeling is that I use the triangle/circle a lot, to choose complementary colours. I'd actually like it if there were a mark on opposite side of the circle to the apex, too. Some colour selectors let you choose line/triangle/square/etc, and that is also useful. Even Itten at the Bauhaus used the wheel. Let's keep it. Or are you proposing to add a new mode, and keep the wheel? But I think that's a separate issue from HSV vs. HSL. The colours you mention that can't be represented in hex also can't be represented in an 8-bit-per-channel image model. Certainly there's merit in re-thinking the colour choosers once the gimp core has more than 8-bit-per-channel colour. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. I'd ideally like to see an HSL-based correction pack in GIMP using the Gutenprint algorithm, where it's possible to correct all three channels as a single operation. The correction adjustments (+/- delta for H, multiplicative factors with soft clipping for S and L) are done with curves, where the X axis is the starting hue and the Y axis is the correction. This would allow selective hue shifting along with saturation and lightness adjustments in one shot, with only one loss of precision. -- 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
Re: [Gimp-developer] HSL Color Picker
Robert Krawitz wrote: From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. The representation certainly seems useful. My major concern is that, as a photographer, saturation in HSL doesn't seem to usefully map to what we typically call saturation (hereafter, psaturation) — if I'm talking about a psaturated red sunset, a mostly-white sky with a touch of red isn't what I'm describing. Put another way, a photographer's sense of psaturation is well-represented by saturation in HSV. In HSL, the concept of psaturation is split across both saturation _and_ lightness — a color which is psaturated tends to have both high HSL saturation and neutral lightness. Note, however, that the HSV and HSL saturation would align to a useful extent if HSL coordinates were defined in terms of a cylinder, but the color space were actually shaped like a double-cone (see [1]). Or really, if it were any shape with single points at full-lightness (white) and zero-lightness (black), and with a circle/hexagon at neutral lightness. In that case, a color could only be described as fully saturated when it has neutral lightness. Colors that are between neutral lightness and extreme lightness have gradations of saturation, and the saturation is bounded such that it must decrease as you approach one extreme or the other (of lightness). Of course, when you do that, computations become harder. *sigh* I'll send out a mockup of what I mean shortly. [1] http://en.wikipedia.org/wiki/File:HSL_HSV_cylinder_color_solid_comparison.png --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Omari Stephens wrote: Robert Krawitz wrote: From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. The representation certainly seems useful. My major concern is that, as a photographer, saturation in HSL doesn't seem to usefully map to what we typically call saturation (hereafter, psaturation) — if I'm talking about a psaturated red sunset, a mostly-white sky with a touch of red isn't what I'm describing. Put another way, a photographer's sense of psaturation is well-represented by saturation in HSV. In HSL, the concept of psaturation is split across both saturation _and_ lightness — a color which is psaturated tends to have both high HSL saturation and neutral lightness. Note, however, that the HSV and HSL saturation would align to a useful extent if HSL coordinates were defined in terms of a cylinder, but the color space were actually shaped like a double-cone (see [1]). Or really, if it were any shape with single points at full-lightness (white) and zero-lightness (black), and with a circle/hexagon at neutral lightness. In that case, a color could only be described as fully saturated when it has neutral lightness. Colors that are between neutral lightness and extreme lightness have gradations of saturation, and the saturation is bounded such that it must decrease as you approach one extreme or the other (of lightness). Of course, when you do that, computations become harder. *sigh* I'll send out a mockup of what I mean shortly. 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. I think this is a good representation for a couple reasons: - It retains the advantages of HSL over HSV (primarily, the symmetry and the ability to move from a color with a certain psaturation to the equivalent gray). - It retains the photographer's sense of psaturation as its concept of saturation - Unlike both HSV and HSL, it compresses the volumes that are mostly-white and mostly-black. This matches RGB's compression of those same volumes (see [2]), which is nice, assuming that images will be stored in RGBA of some bit depth. This also makes sense in terms of the colors that humans can perceive — we can more-easily perceive differences in highly-saturated colors than we can differences in mostly-white swatches with a hint of color. Also, given that our brains correct for white-balance continuously, the difference between shades of white becomes even less important. And given that our cones hardly work in the dark, the difference between shades of black becomes even less important. - 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. - It creates a bijection (a one-to-one mapping) between valid coordinates and points in the color space. Put differently, there is no coordinate change you can make that will leave you at the same color. This property holds for RGB as well, but not for HSV or HSL (in HSL,
Re: [Gimp-developer] HSL Color Picker
Date: Sun, 31 May 2009 20:56:25 + 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. 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 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
Re: [Gimp-developer] HSL Color Picker
On Sunday 31 May 2009 01:56:25 pm Omari Stephens wrote: his also makes sense in terms of the colors that humans can perceive — we can more-easily perceive differences in highly-saturated colors than we can differences in mostly-white swatches with a hint of color. This is not correct. Humans are much more sensitive to differences in color near the neutral axis (IE. grays) then in colors that are highly saturated. Hal ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Hal V. Engel wrote: On Sunday 31 May 2009 01:56:25 pm Omari Stephens wrote: his also makes sense in terms of the colors that humans can perceive — we can more-easily perceive differences in highly-saturated colors than we can differences in mostly-white swatches with a hint of color. This is not correct. Humans are much more sensitive to differences in color near the neutral axis (IE. grays) then in colors that are highly saturated. Oops; I think this was a half-developed thought, and now I'm having trouble defining it well enough to put into words. Oh well. Thanks for the correction. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL Color Picker
Robert Krawitz wrote: Date: Sun, 31 May 2009 20:56:25 + 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. 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
Re: [Gimp-developer] HSL Color Picker
On Sun, May 31, 2009 at 10:36 PM, Robert Krawitz r...@alum.mit.edu wrote: Omari Stephens wrote: - 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. The colors selected in this manner will likely be used in a different color space than the one they are selected in anyways. This means that undefined regions of the colorspace and computational complexity are only a concern of the color picker interface. CIE Lch is another options that can be considered. I haven't studied it but suspect that the current computation of Lightness has crude 8bit/gamma assumptions in it. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
