Talk:HSL and HSV

RGB -> HSV :: Hue transform error

I see a mod6 in the image, I don't think it's supposed to be there. Instead, ma==rn -> (g-b)/c. Can someone double-check? —Preceding unsigned comment added by 74.105.42.220 (talk) 06:21, 17 June 2010 (UTC)

The mod 6 is used so that the definition can be written piecewise in 3 parts (the part between -60° and 60°, the part between 60° and 180°, and the part between 180° and 240°), instead of 6 parts. Because hue is circular, -60° mod 360 = 240°. Does that make sense? [There are many alternate ways to write the definition: the one used is just the shortest and clearest one I could come up with.] –jacobolus (t) 23:07, 17 June 2010 (UTC)

The definition I currently see is:

 h'
  | C == 0    = 0
  | M == r    = ((g-b)/C) `mod` 6
  | M == g    = (b-r)/C + 2
  | M == b    = (r-g)/C + 4
 h = 60 * h'

However I'm pretty sure it should be:

 h'
  | C == 0    = 0
  | M == r    = (g-b)/C + 0
  | M == g    = (b-r)/C + 2
  | M == b    = (r-g)/C + 4
 h
  | h' < 0    = 60 * (360 + h')
  | otherwise = 60 * h'

The way I visualize it, the chroma defines the size of the scaled cube/hexagon. Each side of this scaled hexagon is assigned a length of one. Each color is assigned a number counter-clockwise:

 R  0
 Y  1
 G  2
 C  3
 B  4
 M  5

The piecewise function is defined for each primary color and covers, like you wrote,

 R  +60  <->  -60
 G  +180 <->  +60
 B  +300 <-> +180

The function gives the (maximum color) + (positive shift along circumference :: another color) + (negative shift along circumference :: last color). This is scaled to the size of new cube/hexagon defined by the chroma (explaining why the function divides by C). So for example, if Red is the maximum, then Green defines a postive shift along the circumference and Blue a negative (in the opposite direction).

Perhaps this is clearer:

 h'
  | C == 0    = 0
  | M == r    = 120*(0/2) + 60*((g-b)/C)
  | M == g    = 120*(2/2) + 60*((b-r)/C)
  | M == b    = 120*(4/2) + 60*((r-g)/C)
 h
  | h' < 0    = 60 * (360 + h')
  | otherwise = 60 * h'

One other clarification:

"Thus if we add or subtract the same amount from all three of R, G, and B, we move vertically within our tilted cube, and do not change the projection"

should be

"Thus if we add or subtract the same amount from all three of R, G, and B, we move vertically within our tilted cube, and do not change the hue or chroma (the value - a-axis - and saturation - are modifed)"

—Preceding unsigned comment added by 74.105.42.220 (talk) 02:52, 18 June 2010 (UTC)

The definition you are “pretty sure it should be” is not quite right, but the statement as I think you were trying to write it is mathematically identical to the current definition, just rewritten to be a bit longer and in my opinion less clear. Notice:

$60 (h^\prime \;\bmod 6) = (60 h^\prime) \;\bmod 360 = \begin{cases} 360 + 60 h^\prime, &\mbox{if } h^\prime < 0 \\ 60 h^\prime &\mbox{otherwise} \end{cases}$

–jacobolus (t) 22:34, 18 June 2010 (UTC)

huh good point, I wasn't aware of how modulus worked with negative numbers —74.105.42.220 (talk)

Yup, it works just the same on every interval. You can think of modulus as describing equivalence classes with representatives in a fixed interval. Each equivalence class includes all the points at distances which are even multiples of the interval length from the representative point (and therefore from each-other). When programming, the modulus operator is tremendously useful for normalizing angles to some desired range, because of course the reals modulo n are topologically equivalent to a circle. –jacobolus (t) 17:28, 22 June 2010 (UTC)

I don’t understand the point of your “other clarification”. –jacobolus (t) 22:34, 18 June 2010 (UTC)

Well technically it's a projection onto a hexagonal cone, which a vertical shift can modify.. but you were probably referring to the flattened projection onto the hexagon. —74.105.42.220 (talk)

The original point is in a “hexcone” (hexagonal pyramid). The projection is in a hexagon in the plane. The key insight for all the mathematical definitions used on this page – what keeps this math simpler and hopefully more comprehensible than the other definitions I’ve seen – is that we can keep “chroma” and “hue” constant (keep the same point in the projection) while moving “up” and “down”, and distort our cube into whatever “lightness”/“value” dimension we like. Later, we can find the point in the original cube by first finding the projection, and then adjusting the lightness/value (i.e. by adding equal amounts of R/G/B) to match our desired color. –jacobolus (t) 17:28, 22 June 2010 (UTC)

Converting to RGB from HSL

The H' mod2 can not be correct. Sorry I can not find if there is a mathematical mistake, but I implemented this in a program and I get all expected colors instead for the range between yellow and green, there the color becomes darker until dark olive green and then one pixel later it gets full bright green again. Can someone with more skills on maths check that out? —Preceding unsigned comment added by 78.52.53.30 (talk) 10:51, 23 November 2010 (UTC)

Can you be clearer about what you did and what’s not working? I wrote these algorithms up and have worked out the algebra at least two or three times in detail and have implemented them in matlab, python, and javascript, with a decent number of test cases, and the numbers all nicely check out. Take a look and see if the pictorial representations make sense to you, and then if you can understand how the equations as written are the same as what is represented in the pictures. I’m happy to answer questions if any of it is confusing or you get stuck. Feel free to email me directly or find me on IRC (freenode) if you want me to look at specific code. –jacobolus (t) 20:55, 23 November 2010 (UTC)

One possibility to consider is that the mod operator does not have identical semantics in all programming languages. In some implementations the mod of a negative dividend returns a negative result (for example, in JavaScript). I consider this to be a bug in the language design since it (a) contradicts the mathematical convention (which is why the equations as written in this article are “correct”) and (b) is nearly always less convenient, but it is what it is. The article Modulo operation does a nice job explaining the trouble this causes. If you know to expect it, it’s pretty easy to work around in practice. –jacobolus (t) 20:57, 23 November 2010 (UTC) [To be concrete, in JavaScript, -5 % 3 === -2, whereas in Python -5 % 3 == 1.]

One last thing: if you’re writing code instead of mathematical formulae, it probably makes sense to alter these equations somewhat: mathematical language and programming languages have different strengths and weaknesses, and the goal in this article is to make the mathematical formulas as clear and coherent as possible, not to be copy/pasteable into code. For example, some steps are probably more convenient to write using if/else logic (perhaps using a ternary operator if your language has one) instead of absolute values and mods. Perhaps we should add some code listings at the bottom of the article, after the swatches. –jacobolus (t) 21:15, 23 November 2010 (UTC)

Saturation in case C=0

The section on Saturation says for all three variants that S is 0 if C is 0, but shouldn’t that be if V or L or I is 0 (which are divisors)? — Christoph Päper 14:23, 12 September 2010 (UTC)

V = 0 ⇒ C = 0, L ∈ {0, 1} ⇒ C = 0, I = 0 ⇒ C = 0. C = 0 is just a convenient way to describe this in a slightly simpler way. It really doesn’t matter one way or the other though.

Basically, the way we’ve written it, there are some values for which C = 0 for which the other quantity (e.g. C/V) is also well-defined. But it’s fine for us to short-circuit that definition, because even for those values the property in question (e.g. S_HSV), is 0 whenever C = 0, and so our definition is still correct. It typically saves about one line of code to implement things the way written here instead of the other way, and the implementations should be otherwise indistinguishable.

In plain English, our definition just says “if C is zero, then our color is achromatic. Otherwise compute this way...” instead of the alternative “Try computing this way ... and if that result is undefined then the color must be achromatic”. –jacobolus (t) 20:37, 12 September 2010 (UTC)

definition of S_HSL

I left the following message over at User talk:209.118.174.130#HSL conversions:

You’re right that it’s possible to either write:

$C = \begin{cases} 2L \times S_{HSL}, &\mbox{if } L \leq \frac{1}{2} \\ (2 - 2L) \times S_{HSL} &\mbox{if } L > \frac{1}{2} \end{cases}$

or write:

$C = S_{HSL}(1 - \left\vert 2 L - 1 \right\vert)$

just by definition of the absolute value. I wonder which one is clearer to readers in showing what’s going on: I think we should just stick to one of these instead of including both.

Similarly, far up above it’s possible to write either:

$S_{HSL} = \begin{cases} 0, &\mbox{if } C = 0 \\ \frac{C}{2L}, &\mbox{if } L \leq \frac{1}{2} \\ \frac{C}{2-2L}, &\mbox{if } L > \frac{1}{2} \end{cases}$

or, if we prefer:

$S_{HSL} = \begin{cases} 0, &\mbox{if } C = 0 \\ \frac{C}{1 - |2L - 1|}, &\mbox{otherwise} \end{cases}$

I’m not sure which one seems clearer to me.

Anyone over here have any thoughts about it? It saves one line of math, but I’m afraid it obscures the definition a bit for readers.
–jacobolus (t) 05:52, 24 September 2010 (UTC)

There is also an interesting symmetry between:

$C = S_{HSL}(1 - \left\vert 2 L - 1 \right\vert)$

and

$X = C (1 - |H^\prime \;\bmod 2 - 1|)$

–jacobolus (t) 06:00, 24 September 2010 (UTC)

Bloat

I think the tripling of the article size over the last two years makes it bloated out of all proportion to what can sensibly be said about this topic. Can we try to go the other direction for a while? Dicklyon (talk) 01:19, 7 February 2011 (UTC)

A good bulk of the article has nothing to do with HSL or HSV specifically, and could be moved to a new article dealing with the three color psychology properties of hue, luma and chroma in general. SharkD  Talk  03:45, 7 February 2011 (UTC)

Which bits do you think are irrelevant or would do better elsewhere? I still think first few sections could be clearer for non-technical users, but for most of the article, I tried to be as clear and concise as I could, while doing justice to the topic. Part of the problem may just be that a lot of generic color topic articles are bad enough (for example, RGB, color space/color model/color solid (which should be consolidated), color attributes (doesn't exist but should, perhaps with a different name), hue, colorfulness, lightness, color reproduction (should be created and perhaps merge in additive color/subtractive color/color mixing all three of which are currently terrible), color, color vision, &c. &c.), that directing people to other articles for background ends up being unhelpful. –jacobolus (t) 04:05, 7 February 2011 (UTC)

As for the most recent addition, of converting back to RGB from luma + "non-distorted" "hue"/"chroma", I don’t really think it’s necessary, being somewhat obvious, but an anon editor added it and if it is going to be there it should be correct, so I corrected it. –jacobolus (t) 04:11, 7 February 2011 (UTC)

I haven't really read it all, so it's hard to say. It's a WP:TLDR problem for me, so I expect it will be for many readers. And the proliferation of colorful complicated images makes it look more confusing than clear. Too many ways of looking at the same thing. Dicklyon (talk) 04:21, 7 February 2011 (UTC)

Jacob, I think you're working too hard on it. Fig.1 is a complicated mess; SharkD's cylinders below it are more clear, even if less complete. And the colored squared embedded in the text are just distracting. The long-winded footnotes are also an approach I don't like, and it seems to be short on really good sources. The long review of color-making attributes seems out of place; it would be better to improve some more relevant article with that material than put it here. Dicklyon (talk) 06:31, 7 February 2011 (UTC)

I agree, the "color-making attributes" section should probably be replaced with a simple sentence stating that the dimensions of HSL and HSV are poor proxies for human-perceived color attributes, maybe with a diagram comparing a better model’s scales with those in HSL/HSV. The problem I was trying to attack with that is that almost everyone I’ve ever talked to (in person, online, etc.) about HSL and HSV was under the impression that they were “good” models which oriented colors in a human-relevant, “intuitive” way, and that the dimensions called hue, lightness, brightness, intensity, saturation, or what have you were reasonable representations of those terms. I wanted to clarify terminology, because sources around the web, and for that matter papers in reputable computing/computer graphics journals, have horribly inconsistent uses of terminology incompatible with official technical definitions. In the abstract, I agree with you that it would be great to improve other articles. –jacobolus (t) 13:47, 7 February 2011 (UTC)

I don't know; I thought it was clear already when it was much shorter. Do need the big "swatches" section? Does it contribute to understanding at all? Is there reason to think that it's a useful reference or resource? Dicklyon (talk) 05:24, 10 February 2011 (UTC)

I thought it did a pretty poor job of explaining how the spaces were put together in the “much shorter” version. But then, I’m not an unbiased observer. For what it’s worth, I’ve gotten a fair amount of positive feedback from developers trying to use HSL/HSV in their projects, especially re: the diagrams. Again though, that’s probably not entirely unbiased feedback. As for the swatches section, I think of it sort of like an appendix, which is why I buried it at the bottom of the page: something that most readers can easily skip over if it’s unhelpful. Also for what it’s worth, I didn’t originally add the swatches section. –jacobolus (t) 12:35, 10 February 2011 (UTC)

The “proliferation of colorful complicated images” happened because reading just the images is IMO much clearer than reading a lot of text. The article is explaining the mathematical derivation of these color spaces, and comparing several: without graphic comparison, skimming the text easily leaves a false understanding of what’s going on. I added the pictures partly because in reading dozens of sources which compared these similar-sounding-but-quite-different color spaces, I wished again and again for some simple pictures showing what was going on. In many cases, I think even the authors didn’t really understand it. Try reading e.g. Smith’s paper again, or one of the ones by Hanbury/Serra or Levkowitz/Herman or one of the graphics textbooks linked, and I think you’ll find that the explanation here is dramatically clearer. –jacobolus (t) 13:56, 7 February 2011 (UTC)

Do you find the colored squares distracting everywhere, or just in the basic idea section? The ones there I agree might be scrapped, but I can’t see inexperienced readers being able to easily understand the later content as well without examples. Which footnotes don’t you like? For the most part they express ideas which seemed important but distracting if included in the article body, such as clarifying exactly a model used by a particular source. There would be three times as many footnotes, except I mostly consolidated them down to 1 footnote per paragraph listing the sources for that paragraph, because I find many wiki articles which include 4 flashy blue links after each sentence pretty distracting. Which part do you think is short on sources? Sources include about 6 computer graphics books, a couple of patents, about 20 papers, and maybe 20 or 30 other sources. I don’t know of any sources better than what is cited, but please point me at anything I should look at. –jacobolus (t) 13:47, 7 February 2011 (UTC)

I can see the point of some of the later ones comparing variations, but not the red, green, blue etc. in the intro section that looks like a garish Christmas display. Dicklyon (talk) 05:19, 10 February 2011 (UTC)

Okay, I can agree with that. Feel free to take them out, or I will sometime. I still think the lead and first section or two should be rewritten. –jacobolus (t) 12:23, 10 February 2011 (UTC)

Footnotes are generally for references, and therefore generally ignored by readers except when they want to know the sources. I find other types of content in notes to be pretty much useless; if it matters to the reader, it should be in the text, and if it doesn't, leave it out. Dicklyon (talk) 05:22, 10 February 2011 (UTC)

In this article specifically, most of the “other content” in footnotes is describing and contextualizing the cited sources or explaining how they fit in with the math used in this article, to try to help the reader avoid confusion. Are there any of them specifically that you think are unhelpful? –jacobolus (t) 12:23, 10 February 2011 (UTC)

It was discussed previously that the stuff about the Runge and Munsell color spheres don't belong in this article. SharkD  Talk  20:20, 7 February 2011 (UTC)

Look through the article History at all the "Undos". It doesn't seem to me that much is able to get through the jacobolus filter. Someone should really inform the admins that they need to turn this particular MediaWiki feature off. It's getting to be very annoying... SharkD  Talk  03:05, 10 February 2011 (UTC)

Well, it's not such a one-sided problem. I agree with many of his reverts. But overall, I think Jacob has added too much stuff. I don't know a good process for getting the three of us (and whoever else cares) to come to consensus about how best to improve the article; but first we have to all assume good faith. Dicklyon (talk) 05:16, 10 February 2011 (UTC)

SharkD, from my perspective your approach to resolving differences has centered on snide remarks, insults, threats, clear distortions in describing past discussion, and a consistent pattern of dodging questions about the content of the page as soon as any substantive disagreements arise. To be honest, it’s pretty tiresome. –jacobolus (t) 12:10, 10 February 2011 (UTC)

He's just a dick! SharkD  Talk  12:19, 14 February 2011 (UTC)

Dear all. I am new to this discussion, but my first thought was that the article is too long and difficult to follow. From the talk page it seems that the same person (jacobolus) has done a lot of the editing, and that he is not keen on shortening it again. I vote to agree with Dicklyon in the first paragraph of this talk. So jacobolus, if there is some shortening, please think before undoing it. Kristjan.Jonasson (talk) 22:39, 9 June 2011 (UTC)

2 cents

After re-reading the article just now I'd like to raise one particular issue that stands out to me. The distinction between chroma and saturation, while interesting historically, is given too much weight. It's of little practical to use to anybody, and I believe is based too heavily on just a few handful of sources. Other sources ignore the distinction, and I think we should steer in that direction as well. That of course doesn't mean we have to omit mention of it entirely. SharkD  Talk  04:21, 26 June 2011 (UTC)

Saturation and chroma are entirely different quantities, and any scientific source will treat them differently. Part of the whole point of this article is to clarify that what HSL and HSV call "saturation" are two different things entirely, and only the HSV "saturation" bears even token resemblance to the perceptually relevant attribute. The only way to give a clear explanation of how HSL's and HSV's "saturation" attributes work, without just writing down a formula and hoping the reader has the time and mathematical preparation to understand it, is with reference to the quantity (max(R,G,B) - min(R,G,B)) that this article, after Joblove and Greenberg, calls "chroma". In particular, the diagram to the right shows explicitly the relationship between HSL "saturation", HSV "saturation", and "chroma". It's a more relevant quantity, practically, than either of the two "saturations", though as explained in the Disadvantages section, all of these attributes are quite misleading, and software would do well to replace them with the hue, lightness, and chroma from CIELAB, if not with the hue, lightness and chroma from CIECAM02. –jacobolus (t) 09:05, 26 June 2011 (UTC)

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)