Talk:HSL and HSV/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

RGB -> HSV :: Clarification

Which conversion method is more accurate? The piece-wise function definition over the hexagon, or trigonometric cartesian-polar transformation? —Preceding unsigned comment added by 74.105.42.220 (talk) 06:30, 17 June 2010 (UTC)

It’s not clear what you mean by “accurate”. Those result in two different color spaces. Both of them are pretty awful as estimates of the perceived attributes “hue”, “saturation”, and “lightness”, but neither of the two is much better or worse than the other. Typically “HSL”/“HLS” implies the hexagon definition. –jacobolus (t) 23:07, 17 June 2010 (UTC)

By the way, if you have a specific purpose in implementing one of these models, I can probably give some advice if you explain the context. –jacobolus (t) 23:12, 17 June 2010 (UTC)

Thanks, I was implementing RGB<->HSV conversions and I wasn't sure if I should use the hexagon model or the circular model. —Preceding unsigned comment added by 74.105.42.220 (talk) 02:54, 18 June 2010 (UTC)

What are you planning to use it for, if you don’t mind my asking? –jacobolus (t) 06:26, 19 June 2010 (UTC)

As part of a bash script to modify the prompt (lol), the haskell program would chain several operations given an input color, including converting ansi<->web<->rgb<->hsv and/or lightening/darkening —Preceding unsigned comment added by 74.105.42.220 (talk) 05:35, 22 June 2010 (UTC)

If you decide to get a bit more ambitious, you’d get more human-relevant results by using a different color space than RGB or its derivative HSL/HSV (for example, CIELAB). Maybe for a simple tool though it’s not worth the effort. –jacobolus (t) 17:30, 22 June 2010 (UTC)

Saturation Calculations

In the image http://upload.wikimedia.org/math/4/0/b/40baec3ba585782daac778ead5d6a437.png used in the Saturation section, the first condition in both equations is unnecessary. Since C is the top value in each fraction, if C is 0 then the result will always be 0 without a special-case test for it. While this may be a programmatic shortcut, it adds nothing to the mathematical definition. GalacticCowboy (talk) 14:22, 23 June 2010 (UTC)

That condition is an easy way to guarantee that the result is defined when the denominator in the other equations could be zero. Dicklyon (talk) 03:46, 24 June 2010 (UTC)

As Dicklyon says, this is just the shortest way to write it. It could also be an explicit check for V = 0 in HSV, or for L = 0 or L = 1 in HSL. I think the way it’s currently written is also clearer and easier to understand (that is, the rationale) than the other versions. –jacobolus (t) 21:09, 24 June 2010 (UTC)

Image and image caption changes in use/history section

SharkD, I’m going to revert your image and caption changes. A few points:

0) I’d really like to at least hear a motivation along with such changes, perhaps on the talk page, if it won’t fit in edit summaries. Preferably it could be discussed first, since the prior version was fairly stable and there are several people actively interested in this article, but in general it’s also good to Be Bold, etc., so that’s okay.

1) You should make a new image if you want to cram a whole bunch of extra things in, instead of just adding stuff to the previous image; otherwise it’s confusing to discuss (can’t see both versions on a talk page, for example), and difficult to adjust/change/revert, because it requires altering image descriptions in multiple places, etc., and it’s impossible to effectively trace the history of the article, because the image shows something different than the prior version. If nothing else, I’d appreciate if you revert the image (& if applicable its description) and make a new one; if you don’t I will. (Also, the image filename no longer reflects the content.)

2) The previous image of color pickers compared and contrasted several color pickers. The article text, caption, and image description all made it extremely clear to readers what the image was about. The new version sticks different kinds of things into one image, and in general is much more confusing.

3) The color modification interfaces are now rendered so small that they are impossible to see, and thus essentially useless.

It’s off the subject, but are you ever planning to actually respond to the discussion from a few months ago about your 3-d rendered images?

–jacobolus (t) 21:19, 24 June 2010 (UTC)

The image description should cover the scope of the image now. SharkD  Talk  10:39, 25 June 2010 (UTC)

Okay, since that’s pretty much a non-response, I’m going to revert your changes. –jacobolus (t) 17:49, 25 June 2010 (UTC)

I think the English in the image captions is poor, and needed revision for clarity. A lot of the image captions were poorly worded, and used poor grammar - for instance the usage of the "identifies" in the first image caption. The article said that performing some action "identifies" a particular shape or geometric object. Performing an action cannot "identify" anything. Things identify stuff, not actions. I also don't think that the images of color pickers and color adjustment tools need to be separated, or that the text in the section requires that they be handled individually. SharkD  Talk  18:18, 28 June 2010 (UTC)

Specifying the value of one coordinate identifies a particular cross-sectional slice. I don’t understand how that is confusing. The main reason that the color pickers and color adjustment tools need to be separated in my opinion is that the color adjustment tools are impossible to understand unless shown at a much larger size than the color pickers. The three color adjustment tool interfaces could probably be combined into one image, and then there would be 2 images overall, but I don’t really think it’s necessary.–jacobolus (t) 20:23, 28 June 2010 (UTC)

I disagree. That is improper use of the word "identifies", and the legibility issues WRT the images are not that great. They're perfectly legible if you click on them and view them in another window. In fact, the images are even more legible since the version I uploaded renders as twice the size by default. SharkD  Talk  02:06, 30 June 2010 (UTC)

Okay, well I think your rewrite of the "identifies" sentence is wordy and unclear. If it really must be different immediately, go ahead and put back the change to that one caption; either way, I can try to rewrite the whole caption tomorrow to avoid the word "identifies". Stop bulk reverting the rest though. As for the images, they are png screenshots, so I don't understand how they could render at twice the size on the image description page. But on the article page, your version renders much too small to be useful, and no, "just click it" is not an adequate response. Especially since there is plenty of room next to otherwise just big blocks of plain text to put color modification UI images with visible details. I don't understand what you mean by "legibility issues WRT the images are not that great". –jacobolus (t) 07:15, 30 June 2010 (UTC)

The images are no less legible than the color selection images. Are they really that important to the article? I don't think so. SharkD  Talk  18:02, 2 July 2010 (UTC)

The color selection images are useful to have in a consolidated image for a few reasons: (1) It demonstrates the relative sizes os the interfaces, which is relevant to understanding their differences, (2) The model being used and shape used for it is clearly visible at reduced dimensions, (3) The purpose is more high-level comparison than detail. The color-adjustment images, by contrast (and especially the one about xv), depend much more on the details. The purpose of including them is precisely the details. –jacobolus (t) 00:24, 3 July 2010 (UTC)

Dear SharkD, this edit war, and your unwillingness to discuss and edit in a cooperative manner, is pointless and tremendously frustrating. If you continue to revert/revert/revert, I will try to find a admin of some sort to temp-ban you. I hope you’ll stop so that step is unnecessary. –jacobolus (t) 00:24, 3 July 2010 (UTC)

In case you weren’t reading them, some of the last several edit summaries have gone like this:

SharkD: No, this wording is not good

jacobolus: listen, we can do the 3-step "be bold" (you), "revert" (me), "discuss". But rv/rv/rv/rv doesn't work

jacobolus: combine images into a table. does that help any?

SharkD: I just don't think the wording is any good.

jacobolus: rv. that's completely non-specific. I adopted several of your changes, rewrote parts of other captions again, changed around the image arrangement, etc.; you bulk reverted w/ one phrase of summary

SharkD: I still don't think it reads well

jacobolus: RV. Per 3RR, if for no other reason, PLEASE STOP the revert/revert/revert/revert. Go fix that particular "identifies" sentence if it’s urgent.

SharkD: I don't think the changes are good

jacobolus: RV: This is longer than 24 hours, so WP:3RR doesn't technically apply, but edit warring is really tedious, and I feel like you're not reading my edit summaries or the talk page. STOP.

jacobolus: remove "identifies" from this caption. SharkD, is that okay?

SharkD: I don't think this wording is any good.

jacobolus: RV. If you revert without discussion one more time I'll go find a moderator to temp-ban you. This is really getting obnoxious. Please stop.

Cheers, jacobolus (t) 00:33, 3 July 2010 (UTC)

I left this message at SharkD's talk page: Hey SharkD, I agree with you that some of the captions you have been reverting to your re-write aren’t ideally worded, and can use some work. I adopted several of your changes, but in other cases I think that your version either changes the meaning, or is wordier or less clear than the original. Instead of just reverting, I've been trying to make some compromises or further improvements, but if you just revert every one of my tries with a short and non-descriptive summary, we can’t really make any effective progress. I welcome your discussion at the talk page; I think we should be able to iron this out amicably and find text we can all agree on. That can only happen if you take part in the discussion though. –jacobolus (t) 05:35, 5 July 2010 (UTC)

Well, I don't think the wording of the English is very good. For instance, you say, "Below: two-dimensional plots showing two of a model’s three parameters at once, holding the other constant..." I don't think anything is being "held" here, or that someone is "holding" something. I'd think that "keeping" would be more in tune with what is going on. You also say that, "Such diagrams often claim to represent HSL or HSV directly, with the chroma dimension deceptively labeled “saturation”." Which sounds questionable to me, since "deceptively" sounds a lot like an accusation. You also say, "The definitions of hue and chroma in HSL and HSV have the effect of warping hexagons into circles." However, only some hexagons are being warped, not all hexagons everywhere. Thus it would be better to be specific. Maybe you would care to ask for a third opinion in these circumstances? SharkD  Talk  22:53, 7 July 2010 (UTC)

First, all of these are grammatical, and perfectly understandable in context. “Holding constant” is widespread usage (that is, is the idiomatic way to say this) in english-language math writing; see for instance this google search (or better perhaps this google scholar search) which provides many examples of such usage in context from a wide variety of fields and countless reliable sources. “Deceptively” implies that readers could be deceived (which is indeed what happens, we can see, because these usages are perpetuated). It is obvious from context (there is a diagram right next to the text) that the hexagons referenced are regular hexagons centered at the origin, in planes perpendicular to the central axis, and oriented so that one corner is at 0°. Writing all of that would be dramatically unnecessarily wordy. Second, your suggested alternatives are in my opinion clearly worse in every case (in the cases where I thought they were better or equivalent, I adopted your wording): hexagons are always two-dimensional; perimeter is a more complex synonym of edge which additionally implies measurement (which we don’t want to imply here); “the hexagons” and “hexagons” are effectively identical in meaning since precisely which hexagons are specified in the picture rather than the text; your substitution of “them” for “those” is unnecessary since the two have identical meaning in context, and I find “those” reads better, and similarly for changing my colon to a parenthetical, and swapping “instead of” for “rather than”; I believe that “mistakenly” makes this is a not-necessarily-correct statement (the usage of “saturation” is not especially well standardized, and so it could be argued that this use of saturation is not necessarily a “mistake” per se... it does deceive or mislead readers though, because it confuses what this article (and some of the earliest and most precise sources) calls "chroma" with HSL or HSV "saturation", and from context it is quite clearly not implying any malicious intent, which wouldn’t even make sense); in the fig. 14 caption my version is IMO clearer and more concise; re: fig 15, this was discussed above, and I suggest you try to get a consensus before changing this back (since it involves changes to images as well as to the article, meaning your revert only of the article text removes several explicitly referenced images – confusing to say the least); gamut is not the area of the plot, but is linked earlier to the article on gamut for readers unfamiliar with the term, and your “according to” here is unnecessarily verbose. Your “Further Reading” → “Further reading” change is proper, and I’ll put it back (I didn’t notice it before). –jacobolus (t) 01:12, 8 July 2010 (UTC)

I’d appreciate it, SharkD, if you responded to discussion here instead of running to Wikipedia:Administrators' noticeboard/Incidents#Ownership of HSL and HSV full of accusations. I spend a great deal of time and effort trying to work towards consensus, and your approach here has been not only frustrating, but also, quite frankly, disrespectful in the extreme. –jacobolus (t) 15:46, 11 July 2010 (UTC)

unfinished discussions archived?

I don’t think setting a bot to archive all the discussions older than 3 months was/is a good idea, given that those discussions from March/April really weren’t close to a conclusion, and their subjects are still rather relevant. This page does not have enough editors/content turnover to justify the short archive time. –jacobolus (t) 07:49, 11 July 2010 (UTC)

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}})=(60h^{\prime })\;{\bmod {3}}60={\begin{cases}360+60h^{\prime },&{\mbox{if }}h^{\prime }<0\\60h^{\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 2L-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 2L-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)

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, that: R=C, G=X, B=C. This is not included anywhere in this formula. Edit: nevermind - the converters were buggy for H=360 and it wraps to 0, at least I guess so. -- 124.148.36.155 (talk) 04:30, 4 January 2013 (UTC)

It should wrap around to zero. –jacobolus (t) 19:36, 30 January 2013 (UTC)