Talk:HSL and HSV

Proposal

This article is too long because it reviews too many topics: the HSV, HSL, and HSI models, for example. Other Wikipedias do not have this problem because they have separate articles for the HSV and HSL models (for example, the Wikipedia in French language).

I propose create at least the articles "HSL color model" and "HSV color model". In these articles would be written technical data or concepts specifical for each of them. For example: "Converting to RGB from HSV section" and the value concept in HSV.

At the same time, this article could be renamed to "Cylindrical-coordinate color models" or something similar. Then, this article would be like an umbrella and a disambiguation page for HSL, HSI, HSV, and other cylindrical-coordinate color models. Consequently, in this article would be discussed their common concepts and similarities.--Adelpine (talk) 21:53, 22 June 2011 (UTC)

The problems with this: (1) to give a reasonable description of these spaces requires something like 75% common material, (2) an article without that material (say, about only HSV) is not self-contained and does not give a reader an accurate impression of the history and practical use of its subject space, (3) these spaces are dramatically easier to understand with reference to each-other, (4) once you put the useful common "umbrella" content into a renamed version of this page, that basically contains everything that would be on the separate other pages, making those basically superfluous, (5) the other-language articles you suggest looking at are filled with inaccuracies and distortions. A quick question: have you carefully read this article as it stands? By what standard have you decided that it is too long? Was there something in particular that you wanted to learn about HSL or HSV that you couldn’t figure out because navigating took too long? Or is this a purely theoretical objection? Many articles on Wikipedia are as long or longer. Keep in mind that it is not necessary for readers to read a whole article to get value from it. Cheers, –jacobolus (t) 06:06, 24 June 2011 (UTC)

To be a bit blunter/more specific: I think both of the relevant French language wikipedia articles are quite bad: fr:Teinte Saturation Valeur is unreferenced and nearly devoid of content, and what it does have is a difficult-to-decipher (certainly for a layperson) set of mathematical formulae, plus the same misleading diagrams that the English wikipedia was using a couple years ago (the only content there not on this english wiki page, the section about complementary colors, is entirely misguided); fr:Teinte saturation lumière is also pretty much unreferenced (as far as I can tell the two references are made up of images and material mostly copied from french wikipedia or perhaps translated from earlier versions of the english wiki pages, making the whole thing a bit circular) and is pervaded by distortions and inaccuracies in both its text and its diagrams, spends most of its text on mathematical irrelevancies such as the long section about thinking of the space as a cube rather than a cylinder (this has no practical value but confuses the geometry of the space since proximate hues are arbitrarily geometrically separated, misleading readers), and does not bother to describe the history or usage of the space. Someone reading only the introduction and "basic idea" sections of this English wikipedia article, and then briefly glancing through the diagrams, would end up with a better understanding of HSL and HSV than someone reading either or both of the French wikipedia’s articles. If that reader then cared to know more, this article would support that desire; the two French language articles do not. –jacobolus (t) 06:23, 24 June 2011 (UTC)

I like the idea. That said, good luck accomplishing it. SharkD  Talk  04:11, 26 June 2011 (UTC)

When I wrote my suggestion I was looking for some color model to get hue values from RGB images. At that time, I was in a hurry; so I did not have time to read this article. Later, I read it thoroughly—even I found some typos/mistakes. For example, in Fig.9, says that chroma is B-G; however, is B-R. Another example, in the description of the same figure, it says that “Chroma is the relative size of the hexagon passing through a point”, but the size ratio depends on the square of (OP/OP') instead of the ratio OP/OP'.

I arrived to these conclusions: (1) HSL, HSV and HSI can be useful to get hue but they are useless to get what human beings perceive as saturation, or lightness. (2) Hopefully, these models will be part of the history of image processing in a short while. So, we shouldn't spend so much time improving this article. Consequently, I recommend to forget the idea of splitting it.--Adelpine (talk) 21:32, 27 June 2011 (UTC)

Ooh, good catch on that mistake. You’re right, it should be B – R. I’ll try to fix that soon. Looks like it snuck in in the change from this version to this one. As for “relative size of the hexagon”: I thought it was pretty clear in the context of the diagram, where the formula OP/OP' is written out explicitly, that the quantity C is proportional to the circumradius of the hexagon, not to its area. If you think that the caption might lead readers to believe it is proportional to the area of the hexagon, instead, then perhaps the language of the caption should be changed. I’m not sure I’d call that a “mistake” though. Your conclusion (1) seems mostly right to me, though if you ask me, these spaces also have quite poor hue dimensions, which aren’t anywhere close to perceptually spaced, and yield “complementary” hues which are essentially arbitrary. –jacobolus (t) 03:09, 28 June 2011 (UTC)

Fixed the typo. –jacobolus (t) 02:04, 10 July 2011 (UTC)

chromaticity diagram

First: a minor error on the HSL/HSV chromaticity diagram: the value posited for G is not the value represented in the equation for C.. B & G are interchanged.

Second: will someone please explain how one gets from the RATIO of the lengths of the vectors OP/OP' in the chromaticity plane, to the arithmetic difference between the max and the min of (R,G,B)?

Third: what is the perceptual basis for considering chromaticity to be be the difference between max & min of (R,G,B)? Why?

Fourth: what is the physical significance of the numerical values associated with R,G,B respectively?

Thank you

— Preceding unsigned comment added by HilbertHilbert (talk • contribs) 03:19, 29 June 2011 (UTC)

To begin with, I’d avoid calling it a “chromaticity diagram”, to prevent confusion. Even though most computer graphics sources are extremely sloppy with their terminology, it’s worth remembering that RGB and derived spaces like the ones described in this article are only very loosely similar to perceptually-based color spaces like CIELAB or perceptually-based chromaticity diagrams like the u′–v′ diagram.

1. as Adelpine pointed out 30 hours ago, it should read B – R rather than B – G. I’ll try to fix this soon.
2. The derivation is much less obvious/intuitive algebraically than geometrically, but it’s not too hard either way if you fiddle around with it. A brief geometric explanation: When we tilt the RGB cube up on its corner, and look down from above the neutral axis, we can think of it as being made up of a series of layers, where each layer has the same value for M = max(R, G, B). The topmost layer in this case is made up of the three top square surfaces of the cube, one where R = 1, one where G = 1, and one where B = 1, and of course with the edges where the meet being places where two of the components are 1, and the white point at the center has R = G = B = 1. Because a projection onto the plane perpendicular to the neutral axis of each of the three squares making up this surface is a projective transformation, it preserves the ratio of the distance between the white center point and a point to the distance between the center point and the edge of the surface along the same direction (all projective transformations preserve such ratios). Furthermore, notice that changing the median component moves us, in the projection, along the direction of the hexagon through the current point, while changing the minimum component moves us along a radial line. Again, because projective transformations preserve ratios, it must be the case that changes in the smallest component are proportional to distance from the outside hexagon to the hexagon through the current point. [This is a bit handwavey: I urge you to draw a picture or rotate a large cube in your hands or work through the algebra if you want to convince yourself. Either that or pick 10 or 12 example points and work through the arithmetic] Now notice that the maximum side length, as well as the maximum value of C, for any of the other such “shells” depends on max(R, G, B). Because for any of the three sides of any shell, the projection onto the plane is a projective transformation, the same argument about distances holds as in the outermost shell case. Alternately, you can think of C as the distance from the central axis after doing the requisite distortions of RGB to arrive at any of the slices in this diagram: File:Hsl-hsv chroma-lightness slices.svg.
3. (A) “chromaticity” has a different meaning than “chroma”. (B) None of the geometry of an RGB cube or the derived dimensions like the ones discussed in this article have a particularly strong “perceptual basis”, cf. the disadvantages section. At best, they are “inspired” by the perceptual attributes of lightness, chroma, saturation, and so forth.
4. They are related to the intensities of primary lights in an additive color system such as a computer display, often non-linearly (see gamma correction).

Hope that helps, –jacobolus (t) 05:02, 29 June 2011 (UTC)

Thanks. I'll work on that. I called it a "chromaticity diagram" becasue the text at the diagram states that it represents, inter alia, the "chromaticity plane". Shall we call it a "diagram that involves the chormaticity plane"? I agree that we should be fussy about definitions. — Preceding unsigned comment added by HilbertHilbert (talk • contribs)

Fair enough. It's hard to find terminology when working with HSL/HSV that is meaningful enough to be understood but doesn’t give a false impression. Maybe “chromaticity diagram” is an okay name. In the article body, I put “chromaticity” in scare quotes. –jacobolus (t) 17:25, 29 June 2011 (UTC)

Some further points:

1) would it be possble to provide the algrebraic demonstration (in addition to the geometric conceptualization) relating the ratio & the difference, as queried above?

2) This is important: jacobolus insists that the distinction between chorma and saturation is very important. then it should be clearly explained in the aritcle itself. I do not (& cannot) take a position on whether it is important, but, assuming it is, it should be in the body. I do note that every other source I find on the web about HSV & HSV uses "saturation", not "chroma", so I think this fact merits an explanation (& the related analysis of the distinction) in the article.

3. As to the size of the article -- I take no position as to its absolute length, but I think it might help clarify the presentation if the definitions presented are restricted to those that have a direct bearing on the HSV & HSL analyses. In particular, "intensity", "luminance, & luma are not obviously necessary to the analysis here. If "necessary" for background, move them to a footnote."Lightness, value" might be useful, but only if "lightness, value" = value. Also "Y'CbCr" is undefined, and quite collateral.

Also, Chroma = the colorfulness relative to the brightness of a similarly illuminated white. But "colorfulness" = the attribute of a visual sensation according to which the perceived color of an area appears to be more or less chromatic. But where is the definuition of "chromatic"? If "chromatic" is the property of having chroma (which does not fit well with the presented definiton of "chroma"), this is clearly circular. Otherwise what is "chromatic"?

The defintions "chroma" and "saturation" distinguish between the refrence: relative to the brightness of a saimialrly illuminated white (chroma), vs. relative to its own brightness (saturation). This is simply stated. I suggest that this should be the introduction to the technical argument presented above as to the distinction bwteen saturation and chroma in the HSV & HSL structures, and how the math of the representations differs corresponding to those two definitions ( = concepts).

1. Go ahead and work it out. It’ll probably take you a couple sheets of loose leaf and it shouldn’t take you more than an hour to work through the algebra. In the diagram itself, you can think of this as sort of a side-note, not essential to any argument, and a proof is well beyond the scope of this article. I’m not going to spend the time to write it in enough detail to be thorougly convincing (that would take me at least 40 minutes to an hour, and I’m spending enough time responding here as is), but here’s a hint: start by considering only the cases where R > G > B.
2. The distinction is demonstrated in great detail in both diagrams and formulae in the article. I really don’t know how it could be clearer. “Saturation” in HSL means something very different than “saturation” in HSV which means something very different than “saturation” in HSI which means something very different than what photoshop calls “saturation” for its “hue”/“luminosity”/“saturation” dimensions (which we here are calling hue/luma/chroma). The best way to compare these is by showing how they are related to what this article (based on the usage of Joblove/Greenberg) is calling “chroma”, from which they can all be thought to derive. When someone draws a diagram of a cone or double-cone, and claims it represents “HSL” or “HSV” that is somewhere between a distortion and a lie: the radial dimension in such a diagram represents what we’re here calling “chroma” rather than HSL or HSV’s “saturation”. In color science descriptions of the perceptual attributes of human vision, saturation and chroma are two different quantities. See for instance RWG Hunt, “Saturation, Superfluous or Superior?” Note that the perceptually relevant attribute “saturation” is not especially close to the attributes in either HSL or HSV, as described in the “disadvantages” section of this article.
3. Quite commonly in non-scientific sources such as computer graphics journal articles and blogs, these color spaces are referred to by a mixed-up set of names; also, the mathematical definitions are not uncommonly confused. Sometimes, what is usually called HSL gets called HSV instead, or vice versa. The order of the abbreviation is not consistent, and HSL in particular is often called HLS. Sometimes HLS means something different than HSL within the same source. Sometimes, their “L” dimension is called “luminance” or “luminosity”. Sometimes it is called “intensity” and a space is called HSI instead. Sometimes “HSI” refers to HSV, or more often it refers to something different (as described by this article). Luma is the clearly correct term for what Photoshop in some contexts calls “luminosity” (Photoshop also calls CIELAB lightness “luminosity”, and uses HSL saturation, HSV saturation, and what this article calls chroma in various contexts, all under the name “saturation”). Explaining in painful detail every single use and misuse of these terms is obviously beyond the scope of this article, so in writing it I tried to stick to the most common definitions and most reputable sources, and to use consistent symbols for each quantity throughout the article. You might be right that some of the scientific definitions at the top could be skipped. I wanted to make it entirely clear to readers that what gets called by these names in HSL/HSV/etc. is not actually the same as the technical scientific definition of any of these terms.

Inre: chroma/chromatic/saturation, the reason these terms are defined somewhat cryptically/circularly is that there is no objective standard for human perceptions. How can you say something has a “color” to a reader who doesn’t know what a color is? This is a problem with the official scientific definitions, not Wikipedia. Go take it up with the CIE. :-)

Notice that what this article calls “chroma” is not the same as the perceived attribute “chroma”, and none of the attributes called “saturation” are the same as the perceived attribute “saturation”. We might say that Joblove/Greenberg (and this article) call chroma was “loosely inspired by” perceived chroma, and what HSV and HSI call “saturation” were each “loosely inspired by” perceived saturation. What HSL calls saturation is basically useless, and bears no resemblance at all to any perceptually relevant quantity.

Similarly, we could say that HSL lightness and HSI “intensity” are “loosely inspired by” perceived lightness (“value” is an exact synonym, in technically accurate usage), while what HSV calls “value” is a basically useless quantity unrelated to human perception.

Cheers, jacobolus (t) 19:52, 1 July 2011 (UTC)

fix diagram

Can someone remove the irrelevant stuff from the diagram about another model luma/chroma/hue not part of this article. QuentinUK (talk) 18:36, 8 July 2011 (UTC)

someone might also fix fig. 8 the "coördinates"... [an] — Preceding unsigned comment added by 141.2.38.54 (talk) 14:06, 27 January 2012 (UTC)

As explained at great length and demonstrated in the diagram, the “luma/chroma/hue” stuff are (1) closely related to HSL/HSV, and (2) luma & chroma are often called lightness/luminosity & saturation. They’re widely used in graphics software, most famously Photoshop. As for “coördinates”, that’s a perfectly reasonable spelling. –jacobolus (t) 18:38, 27 January 2012 (UTC)

Formula for X

Can’t X(H prime) be simplified? Isn't $X=C(1-|H^{\prime }\;{\bmod {2}}-1|)$ the same as $X=C(H^{\prime }\;{\bmod {2}})$ ? Yurivict (talk) 00:16, 4 April 2012 (UTC)

Nope. Try plotting them. –jacobolus (t) 01:32, 4 April 2012 (UTC)

What is mod 2 in the formula? — Preceding unsigned comment added by 74.190.149.81 (talk) 01:26, 4 May 2012 (UTC)

Got it now. thanks jacobolus for the graph: Try plotting them — Preceding unsigned comment added by 74.190.149.81 (talk) 01:33, 4 May 2012 (UTC)

That's because Mathematica implements mod 2 for floats as well. Not all programming languages have this. In the Wikipedia section of mod, it only discusses integer mod. Angry bee (talk) 06:17, 22 December 2012 (UTC)

The formulas shown in this article are not supposed to be ideally efficient programming language implementations, but rather mathematical descriptions. I recommend using conditional statements when actually implementing this in code, though most programming languages also have a mod operator for floats, so that’s also an okay implementation. Ideally, test various implementations in your language of choice, profile them, and choose the one which is best trades off readability and efficiency. Cheers. –jacobolus (t) 22:14, 22 December 2012 (UTC)

My point is that mathematical description as described in modular arithmetic only deals with integers although it has a functional description that allows it to extend to floats. The use of mod here in the article is extended to floats. For clarity it should mention that mod 2 is mod 2 over the reals. Angry bee (talk) 19:29, 23 December 2012 (UTC)

Okay. Put it in one of those lettered footnotes if you want. No one else has said they were confused about this. –jacobolus (t) 00:34, 29 December 2012 (UTC)

Google Spreadsheet Appscript for HSL to RGB

function onEdit() {
  rang = SpreadsheetApp.getActiveRange()
  c = rang.getValue();  
  if (c < 10){
    setBackgroundHSL(36*c, 1,0.8, rang);
  }
  if (c >= 10){
   setBackgroundHSL(c*36, 1,0.5, rang);
  }
  
  if (c < 0){
    c = abs(c)
    setBackgroundHSL(c*36, 1,0.8, rang);
    rang.setFontColor('#FF0000');
  }
}

function abs(a){
  if (a < 0) {
    return -a;
  }else{
  return a;
  }
}


function mod2(a){
  a = abs(a)
  while (a >= 2){
    a = a - 2;
    }
  return a;
}

function setBackgroundHSL(ho,s,l, cel){
  r=255;
  g=255;
  b=255;
  h=ho/60;
  c = (1-abs(2*l-1))*s;
  x = c*(1-abs(mod2(h)-1));
  if (h < 1){
    r = c;
    g = x;
    b = 0;
  }else if (h<2){
    r = x;
    g = c;
    b = 0;
  }else if (h<3){
    r=0;
    g=c;
    b=x;
  }else if (h<4){
    r=0;
    g=x;
    b=c;
  }else if (h<5){
    r=x;
    g=0;
    b=c;
  }else if (h<6){
    r=c;
    g=0;
    b=x;
  }
  m = l - c/2;
  r=r+m;
  g=g+m;
  b=b+m;
  r=r*255;
  g=g*255;
  b=b*255;
  cel.setBackgroundRGB(r, g, b);
}

For what it’s worth, this talk page really isn’t the place for this. –jacobolus (t) 03:05, 4 May 2012 (UTC)

Where did this get derived from?

${\begin{aligned}H^{\prime }&={\begin{cases}\mathrm {undefined} ,&{\mbox{if }}C=0\\{\frac {G-B}{C}}\;{\bmod {6}},&{\mbox{if }}M=R\\{\frac {B-R}{C}}+2,&{\mbox{if }}M=G\\{\frac {R-G}{C}}+4,&{\mbox{if }}M=B\end{cases}}\\H&=60^{\circ }\times H^{\prime }\end{aligned}}$

Specifically I'm curious about the Mod6 part of it for when M=R. Since G and B each range for 0 to 1, and the dividing by C is just a normalizing factor, this means that the term G-B can never exceed an absolute value of 1. Therefore you don't need Mod6 to make it cycle back to 0 when G-B=6, because in fact G-B will never be equal to 6. If I'm missing anything, please explain it to me. Thanks.

Animedude5555 (talk) 21:04, 8 August 2012 (UTC)

There are a bunch of possible ways to express the derivation of H from R/G/B. This one is just the clearest and most compact that I could come up with in a few days of thinking about it. The best way to understand what’s going on is to look at the pictures, which show the same formulae visually. The mod 6 bit is useful because the values of G - B can be anywhere in range [-1, 1], and we want to map those that fall in range [-1, 0) to range [5, 6) instead. Most formula just write 7 cases instead of our four cases, but I find this version expresses the mathematical structure a fair bit more clearly. –jacobolus (t) 14:20, 9 August 2012 (UTC)

I'm also curious about this part:

${\begin{aligned}\alpha &=\textstyle {\frac {1}{2}}(2R-G-B)\\\beta &=\textstyle {\frac {\sqrt {3}}{2}}(G-B)\\H_{2}&=\operatorname {atan2} (\beta ,\alpha )\\C_{2}&={\sqrt {\alpha ^{2}+\beta ^{2}}}\end{aligned}}$

Specifically I want to know how you figured out how to calculate Beta. After working out the part for Alpha it makes sense, as when R,G,B are constrained to 0 to 1, Alpha will range from -1 to 1. But Beta makes no sense Since hue is like a color wheel, and Alpha is the vertical axis, and Beta is the horizontal axis, then it would make sense that the horizontal range spanned the same number of possible values as the vertical range. Remember a color wheel is a circle, NOT an elipse. If the axes aren't equal, you have an elipse. I actually worked out Beta myself and here's what I found. Beta goes from yellowish green (R=127.5 and G=255), to purple (R=127.5 and B=255). So R contributes 1/3 of the total intensity and G or B contributes 2/3 of the total intensity. This gives: Beta = R*0.33 + G*0.67 - R*0.33 - B*0.67 then to simplify it you cross out cancel terms when possible Beta = G*0.67 - B*0.67 lastly you normalize it Beta = G - B Now Beta also will range from -1 to 1, just like Alpha had done.

If I got any math wrong here, or if I overlooked something, please let me know. Thanks.

Animedude5555 (talk) 21:18, 8 August 2012 (UTC)

Take a look at the picture to the right, which shows what’s going on pretty clearly. If you project points in the RGB cube onto a plane perpendicular to the neutral axis, you can express any color’s position in that plane in terms of coordinates relative to two orthogonal axes. α and β are just the axes that result from defining 0° to be pointed towards the red primary. The reason β has a smaller range of values than α does is that the the the projection of the RGB cube into a plane perpendicular to the neutral axis forms a hexagon, not a circle or ellipse, and when you try to overlay a rectangular grid onto a hexagon, oriented so that one of the hexagon’s vertices fall along one axis, one coordinate necessarily has a wider range than the other. –jacobolus (t) 14:20, 9 August 2012 (UTC)

Slight error in hsv conversion

In the section 'Converting to RGB' under 'From HSV' the method states that it is defined for the interval 0 <= H <= 360. however if H = 360, then H' is calculated to be 6, which is not caught by the equation for (R,G,B). this equation catches 5 <= H' < 6, setting (R,G,B) = (C,0,X). the conditional for this equation should include H' = 6 (as in 5 <= H' <= 6). — Preceding unsigned comment added by 142.104.74.14 (talk) 20:30, 18 September 2012 (UTC)

Thanks for catching the typo. It was originally a half-open interval, but “helpful” anonymous editors keep changing it to a closed interval instead. I fixed it for now. –jacobolus (t) 14:10, 19 September 2012 (UTC)

Oh wow, that error was introduced quite a while ago. The disagreement might help explain why other anonymous readers keep trying to make the other half-open intervals into closed intervals. –jacobolus (t) 14:16, 19 September 2012 (UTC)

So what should result when H=360? Online calculators suggest when H=360, R=B=C (red, blue, chroma). This is not included anywhere in this formula. -- 124.148.36.155 (talk) 04:30, 4 January 2013 (UTC)