Misplaced Pages

Talk:HSL and HSV: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 06:08, 11 July 2010 editDatumizer (talk | contribs)Extended confirmed users, Pending changes reviewers42,788 edits archive 6 was missing← Previous edit Latest revision as of 16:46, 26 March 2024 edit undoJacobolus (talk | contribs)Extended confirmed users35,676 edits Section 3.6 Examples 
(317 intermediate revisions by 60 users not shown)
Line 1: Line 1:
{{American English|date=September 2017}}
{{WikiProject Color|class=B|importance=high}}
{{WikiProject banner shell|class=B|vital=yes|1=
{| class="messagebox standard-talk"
{{WikiProject Color|importance=high}}
| ]
| '''HSV color space''' has had a ] by Misplaced Pages editors which is now ''']'''. It may contain ideas you can use to improve this article.]
|}

{{archives|auto=no|search=yes|bot=MiszaBot|age=90|index=Talk:HSL and HSV/Archive index|
* ] <small>from “Talk:HSL color space” (March 2005–April 2007)</small>
* ] <small>from “Talk:HSV color space” (Dec 2002–Sept 2007)</small>
* ] <small>(Oct 2007–Nov 2009)</small>
* ] <small>Jan 2009-Feb 2010</small>
* ] <small>Mar 2010</small>
* ] <small>Mar 2010-Apr 2010</small>
}} }}
{{oldpeerreview|HSV color space|archive=1}}

{{User:MiszaBot/config {{User:MiszaBot/config
|archiveheader = {{talkarchivenav}} |archiveheader = {{talkarchivenav}}
|maxarchivesize = 70K |maxarchivesize = 70k
|counter = 6 |counter = 6
|minthreadsleft = 3 |minthreadsleft = 6
|minthreadstoarchive = 1 |minthreadstoarchive = 2
|algo = old(90d) |algo = old(180d)
|archive = Talk:HSL and HSV/Archive %(counter)d |archive = Talk:HSL and HSV/Archive %(counter)d
}}{{User:HBC Archive Indexerbot/OptIn
}}
{{User:HBC Archive Indexerbot/OptIn
|target=Talk:HSL and HSV/Archive index |target=Talk:HSL and HSV/Archive index
|mask=Talk:HSL and HSV/Archive <#> |mask=Talk:HSL and HSV/Archive <#>
|leading_zeros=0 |leading_zeros=0
|indexhere=yes}} |indexhere=yes
}}
{{archives|bot=Lowercase sigmabot III|age=180|index=Talk:HSL and HSV/Archive index}}

{{Broken anchors|links=
__TOC__
* <nowiki>]</nowiki> The anchor (#Specifications) has been ] before. <!-- {"title":"Specifications","appear":{"revid":175404972,"parentid":175359404,"timestamp":"2007-12-03T03:31:59Z","removed_section_titles":,"added_section_titles":},"disappear":{"revid":928396417,"parentid":928392559,"timestamp":"2019-11-28T21:18:16Z","removed_section_titles":,"added_section_titles":},"very_different":false,"rename_to":"Specifications with RGB primaries"} -->
{{Clear}}
}}

== 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? <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added by ] (]) 06:21, 17 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

: 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? –] ] 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)"
:: <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added by ] (]) 02:52, 18 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

::: 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:
::: <math>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}</math>
::: –] ] 22:34, 18 June 2010 (UTC)

:::: huh good point, I wasn't aware of how modulus worked with negative numbers <span style="font-size: smaller;">—] (])</span>

::::: Yup, it works just the same on every interval. You can think of modulus as describing ]es 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. –] ] 17:28, 22 June 2010 (UTC)

::: I don’t understand the point of your “other clarification”. –] ] 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. <span style="font-size: smaller;">—] (])</span>

::::: 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. –] ] 17:28, 22 June 2010 (UTC)

== RGB -> HSV :: Clarification ==

Which conversion method is more accurate? The piece-wise function definition over the hexagon, or trigonometric cartesian-polar transformation? <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added by ] (]) 06:30, 17 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->


== please explain ==
: 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. –] ] 23:07, 17 June 2010 (UTC)


The article says both {{tq|The HSL color space was invented in 1938 by Georges Valensi}} and {{tq|computer graphics pioneers at PARC and NYIT developed the HSV model in the mid-1970s, formally described by Alvy Ray Smith in the August 1978 issue of Computer Graphics}}.
: 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. –] ] 23:12, 17 June 2010 (UTC)


What does this mean? Is this contradictory, or if not, why? ] (]) 06:56, 16 June 2018 (UTC)
:: Thanks, I was implementing RGB<->HSV conversions and I wasn't sure if I should use the hexagon model or the circular model. <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added by ] (]) 02:54, 18 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:Judging only by your quotes, there doesn't seem to be a problem, since HSL and HSV are different things. &#x27A7;<span style="border:1px dotted #2e4272;padding:1px;border-radius:3px;">]&nbsp;]</span> 04:06, 27 August 2018 (UTC)
:per ] and ] 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. ] (]) 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 @] 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. ] (]) 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. <b style="color: #0000cc;">''North8000''</b> (]) 20:50, 13 June 2023 (UTC)
::: What are you planning to use it for, if you don’t mind my asking? –] ] 06:26, 19 June 2010 (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. –] ] 09:53, 10 January 2024 (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 <span style="font-size: smaller;" class="autosigned">—Preceding ] comment added by ] (]) 05:35, 22 June 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->


== Color space where full saturation ignores intensity/lightness/luma/luminosity/value ==
::::: 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. –] ] 17:30, 22 June 2010 (UTC)


Is there a color space similar to HSL/HSV/HSI such that 0% saturation ignores hue and 100% saturation ignores intensity/lightness/luma/luminosity/value? Notice the bottom of the example: solid yellow.
== Saturation Calculations ==


] <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 02:54, 5 February 2019 (UTC)</small> <!--Autosigned by SineBot-->
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. ] (]) 14:22, 23 June 2010 (UTC)


== Color conversion formulae: HSL to RGB ==
:That condition is an easy way to guarantee that the result is defined when the denominator in the other equations could be zero. ] (]) 03:46, 24 June 2010 (UTC)


There is a discrepancy in the formula for <math>(R_1,G_1,B_1)</math>.<br>
: 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. –] ] 21:09, 24 June 2010 (UTC)


<math>{ H\in }</math>. H is cyclic, so the same results should occur for H=0 and H=360.<br>
== Image and image caption changes in use/history section ==
<math>H^\prime = \frac{H}{60^\circ}</math>, but H'=0 when H=0 and H'=6 when H=360. The six cases for <math>(R_1,G_1,B_1)</math> cover ⌈H'⌉ from 1 to 6, but H'=0 yields (0,0,0), but H'=6 is (C,0,X).
When H'=0, you should get the same result when H'=6. <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 20:28, 8 June 2020 (UTC)</small> <!--Autosigned by SineBot-->


: I have changed the piecewise function back to the previous version, at some point someone changed it from inequalities to a ceiling function, but it was not correct as written because ceil(0) != 1 --] (]) 13:46, 16 July 2020 (UTC)
SharkD, I’m going to revert your image and caption changes. A few points:


== Issues with HSI to RGB formulas ==
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.


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). ] (]) 16:17, 1 March 2021 (UTC)
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.)


== "HSV, V for light" -- ? ==
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.


It says that HSV represent { "how the object appear under light" / amount of reflected light, by the V value } . This is not true .?
3) The color modification interfaces are now rendered so small that they are impossible to see, and thus essentially useless.


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 .
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?


For preview,
–] ] 21:19, 24 June 2010 (UTC)
* HSV -- https://www.getpaint.net/download.html ,
* HSL -- https://www.w3schools.com/colors/colors_hsl.asp .


] (]) 16:52, 11 March 2021 (UTC)
:The image description should cover the scope of the image now. <span style="border:1px solid #f57900;padding:1px;">] ]</span> 10:39, 25 June 2010 (UTC)


:: Okay, since that’s pretty much a non-response, I’m going to revert your changes. –] ] 17:49, 25 June 2010 (UTC) :I reverted to an older version of the lead section. That was nonsense. –] ] 08:29, 10 January 2024 (UTC)


== Formula section poorly written ==
: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. <span style="border:1px solid #f57900;padding:1px;">] ]</span> 18:18, 28 June 2010 (UTC)


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.
:: 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.–] ] 20:23, 28 June 2010 (UTC)


--] (]) 11:04, 15 April 2022 (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. <span style="border:1px solid #f57900;padding:1px;">] ]</span> 02:06, 30 June 2010 (UTC)


:It was clear and carefully written a decade ago. unfortunately entropy is generally not kind to wikipedia articles. –] ] 08:29, 10 January 2024 (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". –] ] 07:15, 30 June 2010 (UTC)


== Section 3.6 Examples ==
:::::The images are no less legible than the color selection images. Are they really that important to the article? I don't think so. <span style="border:1px solid #f57900;padding:1px;">] ]</span> 18:02, 2 July 2010 (UTC)


Is it just me, or are some of the examples wrong? Or maybe they're using some idealized values?
:::::: 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. –] ] 00:24, 3 July 2010 (UTC)


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.
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. –] ] 00:24, 3 July 2010 (UTC)


A couple seem to give the results I'm expecting (different from the examples on this page). So, what am I missing here?
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, ] ] 00:33, 3 July 2010 (UTC) ] (]) 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. –] ] 07:40, 26 March 2024 (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. –] ] 05:35, 5 July 2010 (UTC)
::So, how would you go about converting the hexadecimal values to these canonical RGB values? ] (]) 15:05, 26 March 2024 (UTC)
::Well, I don't think the wording of the English is very good. For instance, , ''"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? <span style="border:1px solid #f57900;padding:1px;">] ]</span> 22:53, 7 July 2010 (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 {{code|0x00}} and {{code|0xFF}}. For example,
::: 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 (or better perhaps ) 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). –] ] 01:12, 8 July 2010 (UTC)
:::: <math>0.750 \times 255 = 191.25 \approx 191 = 11\cdot 16 + 15 \cdot 1.</math>
::: So the number 0.750 corresponds (approximately) to {{code|0xBF}}. If instead you treated 191/255 as the canonical value, then the decimal fraction for that is 0.749... –] ] 16:37, 26 March 2024 (UTC)

Latest revision as of 16:46, 26 March 2024

This article is written in American English, which has its own spelling conventions (color, defense, traveled) and some terms that are used in it may be different or absent from other varieties of English. According to the relevant style guide, this should not be changed without broad consensus.
This  level-5 vital article is rated B-class on Misplaced Pages's content assessment scale.
It is of interest to the following WikiProjects:
WikiProject iconColor High‑importance
WikiProject iconThis article is supported by WikiProject Color, a project that provides a central approach to color-related subjects on Misplaced Pages. Help us improve articles to good and 1.0 standards; visit the wikiproject page for more details.ColorWikipedia:WikiProject ColorTemplate:WikiProject Colorcolor
HighThis article has been rated as High-importance on the project's importance scale.
HSL and HSV received a peer review by Misplaced Pages editors, which is now archived. It may contain ideas you can use to improve this article.

Archiving icon
Archives
Archive 1Archive 2Archive 3
Archive 4Archive 5Archive 6


This page has archives. Sections older than 180 days may be automatically archived by Lowercase sigmabot III when more than 6 sections are present.
Tip: Anchors are case-sensitive in most browsers.

This article links to one or more target anchors that no longer exist.

Please help fix the broken anchors. You can remove this template after fixing the problems. | Reporting errors

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 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)

Color space where full saturation ignores intensity/lightness/luma/luminosity/value

Is there a color space similar to HSL/HSV/HSI such that 0% saturation ignores hue and 100% saturation ignores intensity/lightness/luma/luminosity/value? Notice the bottom of the example: solid yellow.

Fixed hue of yellow.

— Preceding unsigned comment added by Sollyucko (talkcontribs) 02:54, 5 February 2019 (UTC)

Color conversion formulae: HSL to RGB

There is a discrepancy in the formula for ( R 1 , G 1 , B 1 ) {\displaystyle (R_{1},G_{1},B_{1})} .

H [ 0 , 360 ] {\displaystyle {H\in }} . H is cyclic, so the same results should occur for H=0 and H=360.
H = H 60 {\displaystyle H^{\prime }={\frac {H}{60^{\circ }}}} , but H'=0 when H=0 and H'=6 when H=360. The six cases for ( R 1 , G 1 , B 1 ) {\displaystyle (R_{1},G_{1},B_{1})} cover ⌈H'⌉ from 1 to 6, but H'=0 yields (0,0,0), but H'=6 is (C,0,X). When H'=0, you should get the same result when H'=6. — Preceding unsigned comment added by Chelmite (talkcontribs) 20:28, 8 June 2020 (UTC)

I have changed the piecewise function back to the previous version, at some point someone changed it from inequalities to a ceiling function, but it was not correct as written because ceil(0) != 1 --Alextgordon (talk) 13:46, 16 July 2020 (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,

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 × 255 = 191.25 191 = 11 16 + 15 1. {\displaystyle 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)
Categories: