Talk:HSL and HSV

please explain

The article says both The HSL color space was invented in 1938 by Georges Valensi and computer graphics pioneers at PARC and NYIT developed the HSV model in the mid-1970s, formally described by Alvy Ray Smith[10] in the August 1978 issue of Computer Graphics.

What does this mean? Is this contradictory, or if not, why? CapnZapp (talk) 06:56, 16 June 2018 (UTC)

Judging only by your quotes, there doesn't seem to be a problem, since HSL and HSV are different things. ➧datumizer  ☎  04:06, 27 August 2018 (UTC)

per CapnZapp and datumizer thoughts I elaborated on HSL "invented for television" and HSV "introduced the HSV model for computer display technology" in an attempt to clarify the original concern without altering meaning. HSL_and_HSV&diff=prev&oldid=901938209 Rdela (talk) 10:12, 15 June 2019 (UTC)

I know this topic is many years old, but the opening paragraph is misleading and confusing, partly due to bad grammar and partly due to the contradications that @CapnZapp points out.

The body of the article reads:

"The HSL color space was invented for television in 1938 by Georges Valensi..."

and later:

"...computer graphics pioneers at PARC and NYIT developed the HSV model in the mid-1970s..."

But the leading sentence of the article says that both HSL and HSV were designed in the 1970s, which is misleading at best. It also seems to use an appositive incorrectly: "...are alternative representations of the RGB color model, designed in the 1970s... to more closely align with the way human vision perceives color..." This implies that it is RGB that was designed in the 1970s and that RGB was designed to align with how humans perceive color. I believe it's incorrect to say that HSL and HSV are "representations" of RGB. HSL, HSV, and RGB are each color models or gamuts in their own right. They are all alternatives to one another.

I recommend that the reference to RGB and the misleading fact that both HSL and HSV were invented in the 1970s be removed completely from the leading paragraph. That level of detail is appropriate for the body of the article where it can be treated more carefully. 2600:1700:2820:5630:3DE7:6C28:D3AA:FC12 (talk) 20:03, 13 June 2023 (UTC)

I don't have the expertise to totally fix it but will take out some of the unsourced stuff that looks wrong. North8000 (talk) 20:50, 13 June 2023 (UTC)

I wrote this article to be clear and well sourced over a decade ago, but in the mean time it has suffered from gradual deterioration. The stuff about TV color broadcasting is not really directly relevant IMO, and is not sourced to secondary sources. It would be nice if someone who is an expert on old television broadcast standards could write a clear summary, but this article isn't really the place for it IMO. –jacobolus (t) 09:53, 10 January 2024 (UTC)

Issues with HSI to RGB formulas

Unless I am missing something, I believe there are issues with the HSI to RGB formulas. The result of the formula C = (3 · I · S) / (1 + Z) can yield values where 0 ≤ C ≤ 3. Values where C + m > 1 are problematic, since this will result in values for R, G, and B that are outside the acceptable range of 0 to 1 (inclusive). Techfan101 (talk) 16:17, 1 March 2021 (UTC)

"HSV, V for light" -- ?

It says that HSV represent { "how the object appear under light" / amount of reflected light, by the V value } . This is not true .?

HSV's V behave irrelevantly to light, for some colors . If you use any white light source, you get what HSL's L does . Try to use these 2 values on #49301D . In HSV, after 50% HSL's L, the color still can be made brighter, but in reality, under white light, surface with such color will only reflect more and more white, as in HSL .

For preview,

• HSV -- https://www.getpaint.net/download.html ,
• HSL -- https://www.w3schools.com/colors/colors_hsl.asp .

Irvnriir (talk) 16:52, 11 March 2021 (UTC)

I reverted to an older version of the lead section. That was nonsense. –jacobolus (t) 08:29, 10 January 2024 (UTC)

Formula section poorly written

I'm not a wikipedian, I'm not sure how one would request a rewrite, but the section describing the various conversion formulae has grammatical mistakes and is just in general really hard to read.

--71.231.105.84 (talk) 11:04, 15 April 2022 (UTC)

It was clear and carefully written a decade ago. unfortunately entropy is generally not kind to wikipedia articles. –jacobolus (t) 08:29, 10 January 2024 (UTC)

Section 3.6 Examples

Is it just me, or are some of the examples wrong? Or maybe they're using some idealized values?

For example, #008000 would have the RGB values of (0,128,0). If you normalize these values, you should get (0.0,0.501,0.0), but in the example it gives much "nicer looking" values of (0.0,0.500,0.0). This affects the downstream calculation as well. So instead of getting HSV of (120.0,1.00,0.502), you get (120.0,1.00,0.500). Certainly a "nicer looking" result, but unless I'm missing something, it's slightly inaccurate.

A couple online calculators seem to give the results I'm expecting (different from the examples on this page). So, what am I missing here?

Justin T Conroy (talk) 05:52, 26 March 2024 (UTC)

The exact (R, G, B) values are canonical here, and the 8-bit/channel version is an approximation (which is why it is only an intentionally invisible hexadecimal string, rather than a numerical column). The approximation is necessary because HTML/CSS (and many operating systems and displays) are only capable of describing colors using 8 bit/channel. If you instead treated the 8 bit/channel colors as canonical and computed a decimal approximation for the (R, G, B) columns, that would be worse, because 255ths are not cleanly expressible as decimal numbers, so it would not be obvious which values should be taken as canonical for putting into the definitional formulas for these various color representations between a fraction out of 255 vs. a fraction out of 1000 (3 decimal places). The point of the examples is substantially so people can double-check implementations of these formulas, so the resulting confusion would compromise that goal. –jacobolus (t) 07:40, 26 March 2024 (UTC)

So, how would you go about converting the hexadecimal values to these canonical RGB values? Justin T Conroy (talk) 15:05, 26 March 2024 (UTC)

The conversion went the other way. If you start with an arbitrary number between 0 and 1, you can multiply it by 255 and then round to the nearest integer, which will be between 0 and 255 or in hexadecimal between 0x00 and 0xFF. For example,

$0.750\times 255=191.25\approx 191=11\cdot 16+15\cdot 1.$

So the number 0.750 corresponds (approximately) to 0xBF. If instead you treated 191/255 as the canonical value, then the decimal fraction for that is 0.749... –jacobolus (t) 16:37, 26 March 2024 (UTC)

Reverted addition of an "advantages" section

Hi @8-leaf clover, I reverted your "advantages" section, and changes to the "disadvantages" section. Giving examples is extremely helpful in explaining what the significant problems are with HSL/HSV, and removing the examples does not benefit readers.

I don't think the "Advantages over perceptually uniform color spaces" section is supportable, even beyond the lack of any source: It's obviously true that colors representable in an RGB cube are in a 1:1 relationship with colors representable in an HSL or HSV cylinder, as already described elsewhere in the article, but the rest is somewhere between misleading and wrong. Even wording like "use saturation instead of chroma" is quite problematic since the HSL/HSV "S" parameter is really not anything close to the same as "saturation" as a human-perceived color attribute. A claim that computations are "three times simpler" than RGB computations seems ridiculous to me, and I think you'd be hard pressed to find any expert saying something like that – we are talking about a trivial bit of arithmetic.

At best, if you find a source, you could probably add an extra disclaimer sentence or two in the Disadvantages section explaining why that source prefers it. But frankly the whole rest of the article already serves to describe the purpose / uses / "advantages" of HSL and HSV.

Overall, including a disadvantages section here is of high importance because most shallow sources about HSL and HSV that someone might find in a web search do not discuss the problems, but serious experts on color find HSL and HSV to be unusably bad for almost any situation, and their advice to use them sparingly or not at all is extremely strongly worded. Watering down those expert warnings leaves readers misguided about where HSL / HSV are appropriate and how they relate to other systems for color order. –jacobolus (t) 19:17, 2 February 2025 (UTC)

Hello. While it's true that readers should understand the disadvantages of these color spaces over perceptually uniform color spaces for certain applications, it's also true that the article is biased against them, to the point where the information stops being entirely correct. For instance, the article says:

In HSV, the blue primary   and white   are held to have the same value, even though perceptually the blue primary has somewhere around 10% of the luminance of white (the exact fraction depends on the particular RGB primaries in use). In HSL, a mix of 100% red, 100% green, 90% blue – that is, a very light yellow   – is held to have the same saturation as the green primary  , even though the former color has almost no chroma or saturation by the conventional psychometric definitions. Such perversities led Cynthia Brewer, expert in color scheme choices for maps and information displays, to tell the American Statistical Association...

Value, in the context of HSV, is not meant to represent perceptually uniform lightness, not even approximate it. Neither does "lightness" in HSL.

The same goes for "saturation" in HSL. It is not meant to represent saturation as defined by the CIE, it is simply another way to refer to relative chroma with respect to the sRGB boundary. Even worse, chroma and saturation seem to have been confused in the article. As you said, "HSL/HSV "S" parameter is really not anything close to the same as "saturation" as a human-perceived color attribute".

Neither HSL nor HSV were designed to be even close to perceptually uniform, only simple to compute, simple to use. The properties of all colors inside them being also inside the sRGB gamut, and that all maximum-chroma colors share the same lightness/value are very useful.

Judging color spaces that are not meant to be perceptually uniform by their perceptual uniformity is a very common mistake. It's like if we judged CIE Lab for not being linear. It is not uncommon to see people criticizing even fundamental color spaces like CIE 1931 XYZ or CIE 1931 xyY because they are not perceptually uniform, when their purpose is completely different. Not being perceptually unform is not necessarily "a problem of a color space", unless, of course, the color space was designed to be perceptually uniform.

It is important to mark the ways in which HSL/HSV and perceptually uniform color spaces differ, and I'm not saying that we should add an "advantages" section, but it is not correct to say that they are "offenders" in any way. They don't "own" anyone any perceptual uniformity. I respect what the color experts have to say about them, but abandoning them for not accomplishing a criterion that they weren't designed to accomplish seems senseless. 8-leaf clover (talk) 00:04, 13 February 2025 (UTC)

The term "value" was adopted for the context of color by Albert Munsell (cf. Munsell color system), and it most certainly does mean perceived lightness, as does "lightness". I'm not sure how standardized the meaning of the term "saturation" was in the 1970s, but "saturation" also historically and currently refers to a human-perceived quality of color, which is intended to be meaningfully comparable from one hue to another.

HSL and HSV were invented in a context (1970s computer graphics system) where perceptual uniformity was not possible to achieve with a reasonable amount of computation. But they were explicitly intended to be similar/comparable to perceptually uniform color spaces, and adopted the same terminology for that reason. If you read early documents introducing/explaining these systems they are clearly intended to have more-or-less human-meaningful coordinates, with the goal of being "intuitive" and comprehensible to humans. Unfortunately they just do a very poor job at meeting their own goals (as color experts have written about clearly and at length).

Using names "value", "lightness", "saturation", and even "hue" for HSV and HSL coordinates is extremely misleading, because these words have been redefined to mean something vaguely similar but not really very close to their widely adopted ordinary technical (or lay conventional English) meanings. It's very important to warn readers away from the false impression given by the terminology, because most naïve readers are not color scientists and don't realize that they are being bamboozled by poorly chosen terminology.

I don't think you have an accurate impression of the goals or context of these color spaces. But with that said, if you can find publications by experts advocating the use of these spaces, I'd be happy to quote / paraphrase and link those.

The properties of all colors inside them being also inside the sRGB gamut, and that all maximum-chroma colors share the same lightness/value are very useful. – Useful for who, in what context? My own extensive personal experience in photographic printing, illustration, information design, user interface design, etc. (like the experience of the quoted world-class experts) is that these features are effectively never important enough to justify the severe faults of these color spaces. –jacobolus (t) 01:47, 13 February 2025 (UTC)

In the article, we could point out that the dimensions of "saturation" and "lightness" in HSL, and "value" in HSV do not correspond to the psychometric definitions provided by the CIE; and that neither "hue" nor HSV "saturation" are perceptually uniform. Criticizing the names of the dimensions of color of these color spaces is valid, because they might be misleading.

However, that still doesn't mean that criticizing these color spaces for their perceptual uniformity is valid. These color spaces were designed with the objective of being intuitive for color picking, with notions that artists or the average person might have about color: Any color can be obtained by (additively) mixing a pure hue with black, white, or both. The range from black, to shade, to maximum-chroma color (MCC), to tint, to white is located at the periphery of the HSL color cylinder, and that is HSL's "lightness" indicates. It does not pretend to be a true measure of lightness [1]. In this sense, HSL is similar to the Ostwald color system, or the NCS color space (are we going to judge them, too?). Perceptual uniformity is, again, not the goal of HSL and HSV, so, expert or not, it is unfair to judge them by those standards. And, I insist, the article is biased against them.

The misuse of these color spaces as perceptually uniform ones is not a flaw. Plus, any rational user will quickly realize that the names of their dimensions of color do not refer to the perceptual attributes with the same name.

HSL and HSV may be useful for:

- Generating gradients.

- Color calibration of different kinds.

- Image color adjustment: Lightness and chroma are not always desired to be preserved. When, for example, hue shifting, or increasing the colorfulness, preserving the relation of the colors with black/white and the MCCs might be desirable.

- Digital artists and graphic designers: When color picking, it is useful for many to know exactly where the MCC is, and how that color relates to black and white. With a perceptually uniform color space, this could be solved with hue planes, but changing the hue will also change the lightness and chroma of the MCC, forcing the user to constantly correct these parameters, or enter them manually via hex code/RGB coordinates.

In this sense, GIMP does a good job both in image manipulation and in color picking, because you can choose between HSL and perceptually uniform(ish) CIE Lab; further showcasing that both types of color spaces are needed for different situations.

- In the case of HSV, its V parameter allows the user to choose the maximum brightness color inside the RGB gamut with the same chromaticity as a previously selected color. This cannot be done with a perceptually uniform color space.

The V parameter also allows artists and graphic designers to color shadows correctly. In cases like this one, the L dimension of a perceptually uniform color space may result misleading, because the notion of shadows being just "darker versions of the color of the object" is intuitive, but wrong.

Again, saying that these color spaces "should be abandoned" just because they don't satisfy an arbitrary criterion that they weren't designed to accomplish, and because they may be confusing for inexperienced users (ignoring their advantages over other color spaces), seems, in my opinion, quite entitled; and despite coming from a quote, I think that it biases the article even further.

I see a similar notion of "HSL and HSV spaces should be abandoned" on the Wikipedia:WikiProject Color/Normalized Color Coordinates page. I might add a topic to the talk page regarding this biased point of view later. 8-leaf clover (talk) 15:39, 13 February 2025 (UTC)