[HN Gopher] New alternatives to HSL and HSV that better match co...
___________________________________________________________________
New alternatives to HSL and HSV that better match color perception
Author : bjornornorn
Score : 341 points
Date : 2021-09-12 10:49 UTC (12 hours ago)
(HTM) web link (bottosson.github.io)
(TXT) w3m dump (bottosson.github.io)
| junon wrote:
| > The main drawback of using these models directly for color
| picking is that the sRGB gamut has a quite irregular shape in
| these color spaces. As a result, changing one parameter, such as
| hue, can easily create a color outside the target gamut, making
| them quite tedious to use.
|
| Yes, and since we use color models in development primarily to
| model RGB light as displayed by machines, these are less than
| useful indeed.
|
| For anyone looking for a neat color model that is novel and is a
| bit more intuitive (arguably), look up HCG.
| bloopernova wrote:
| HCG
|
| https://github.com/helixd2s/hcv-color
|
| HCG = Human Chorionic Gonadotropin, which will dominate your
| search results.
| junon wrote:
| Thanks, seems they renamed it recently.
| ianbicking wrote:
| My personal complaint with color pickers is that they make it
| hard to find many normal environmental colors. Where is brown?
| I've learned to find it around red, a little toward orange, and a
| dark saturation. It's not intuitive, and I don't feel like I just
| pick _some_ brown because I can't easily explore the space of
| browns through beige and tan. Flesh tones are similarly
| difficult.
|
| I'm not sure what the solution is. A purely algorithmic color
| picker probably isn't the answer because it's not just our color
| perception that matters, but also the way colors are formed in
| our environment (which is what gives us so many browns).
| kortex wrote:
| Brown is weird [1]. It's basically dark orange. Flesh tones
| fall into that same category - people are orange-hued [2].
| Oranges/reds are mostly produced by various unsaturated
| molecules, such as carotenes, lignins, phenols, and tars, and
| browns are just dark collections of many kinds red-orange
| pigments. It does not map well to any of the common color
| spaces because its inherently heterogeneous.
|
| The solution would probably be pallettes that let you pick
| arbitrary axes to move through color space.
|
| 1 - https://youtu.be/wh4aWZRtTwU
|
| 2 - According to Neil Harbisson, the guy with the color-sensing
| antenna, in-person conversation, but you can also verify with
| photoshop.
| chrisseaton wrote:
| I don't understand that video. Can't all colours be described
| differentially to another colour? And don't we have lots of
| names for different shades? Why does this make brown unusual?
| ThatCaio wrote:
| In English, pink and brown are very specific colors which
| the brains of native speakers might not associate with
| their true hue values.
|
| That's why the original commenter was having difficulty
| finding brown, because we do not necessarily associate it
| with a dark orange or flesh color with de-saturated red or
| orange.
|
| But if we were trying to paint something like dark teal
| water. The brain would immediately go straight to
| blues/greens.
|
| These "color categories" that we form in our brains can be
| different in every culture or language. That is issue with
| what was suggested.
| chrisseaton wrote:
| > That's why you were having difficulty finding brown
|
| Not sure if you're replying to the right person? I didn't
| say anything about finding brown being difficult.
|
| I don't even know what that would mean for it to be
| difficult to find a colour?
|
| > because you do not necessarily associate it with a dark
| orange
|
| That's what brown is - a dark orange. The same way navy
| is a dark blue. But nobody makes videos claiming that
| navy is a weird colour because it's actually dark blue.
| kortex wrote:
| I think what makes brown unique in this regard is its
| ubiquity in nature, partial desaturation, and lack of
| obvious mapping to a saturated color.
|
| Emergence of names of colors in languages usually goes
| black, white, red, yellow, grue, then blue forks from blue,
| brown, orange, then "specialty" colors like pink, purple,
| indigo, teal. It's the only partially saturated shade that
| gets a name before its saturated variant (orange). Being
| able to name things brown is more important than orange, so
| that mental link is weaker. Hence why we have "dark blue"
| but brown is not "dark orange." (though I think some
| languages call it "dark red"? I'm a bit hazy on that
| detail)
|
| https://en.m.wikipedia.org/wiki/Color_term
| chrisseaton wrote:
| > lack of obvious mapping to a saturated color
|
| 30 degrees hue, 50% value, 100% saturated, looks exactly
| brown to me?
|
| > brown is not "dark orange."
|
| I think it is. In fact, take my 30 degrees hue, 50%
| value, 100% saturated, then gradually increase the value
| and see where you get to!
| jobarion wrote:
| For what it's worth, as someone who has deuteranopia (red-green
| color blindness) the resulting OKHSL color picker seems to be
| harder to use than the HSL one. The OKHSV one is fine since
| yellow separates green and red.
| kzrdude wrote:
| Did Bjorn do this work for the benefit of any particular app or
| project?
| Applejinx wrote:
| This is great work. I love how the result is a representation of
| maximally saturated colors that correctly depict perceptual
| lightness of what those maximum saturations are. You can get a
| little palette out of that which contains 'all colors' but which
| makes intuitive sense in a way that traditional representations
| don't.
|
| It's like fitting maximum saturation into a palette that's more
| linear. From canary yellow you don't HAVE a lot of room to go to
| pure white: there's very little difference. And it translates to
| very little linear space between the points. So nice.
| zeroimpl wrote:
| Any good explanation why HSV has the color distortion problem
| mentioned in the article? I thought hue was the main thing it got
| right. Is it due to a problem with sRGB itself?
| PaulHoule wrote:
| These days I would want a color picker that considers the
| lighting and surrounding colors.
|
| I have an office which has huge windows facing (mostly) away from
| the sun so I have bright light from either clouds or blue sky.
| Reproductions of renaissance paintings and photographs on 'bright
| white' paper look great, but at home the color temps are in the
| high 2000s usually and I need coated papers for the images to be
| compelling.
|
| So I am always thinking about what environment a print is in and
| would love to have more tools to tune up the appearance.
| numpad0 wrote:
| "Technically correct" way would be to control the surroundings
| than adapt representations. High CRI lightbulbs, display hoods,
| wallpapers, etc.
| jedimastert wrote:
| I think screen color space and print color space are just two
| entirely different considerations. They meet up in the middle
| somewhere, but you really can't look at both at the same time
| PaulHoule wrote:
| Either the screen or the print depends on the surrounding
| environment. The print also depends on how it is lit.
|
| To some extent one learns that something that looks like this
| in one environment will look like that in that environment.
| toastal wrote:
| Then get a colorimeter that can measure that ambient light and
| recalibrate your screen. The highest end monitors have hoods on
| them to prevent external light from having too much influence
| on your screen.
|
| If your desk doesn't move, you could always have a cron job
| that loads different color profiles based on time of day and
| possibly weather if you really want to make a project of it.
| numpad0 wrote:
| Looking at the author's explanation for HSV and HSL, it sounds
| like they are designed for hypothetical programmable wavelength
| lights and paints. Hue would be wavelength, Saturation is either
| output filter bandwidth or conversion element efficiency,
| Value/Lightness is either output current or amount of ink.
|
| RGB is likewise for fixed wavelength three-color lights/filters,
| and CMYK is for prints. I think it's the same situation as units
| of measurements in aviation[1] being all over the places; the
| measurements are tied to specific devices, principles and usages
| of them.
|
| 1: Altitude in feet measured by pressure altimeters, distances
| measured in nautical miles defined as one minute of latitude,
| fuel in pounds and dimensions in inches, but never altitudes in
| miles or distances in feet, except for runway lengths which is
| always feet or meters.
| arthur2e5 wrote:
| The whole HSL and HSV business has never been about
| hypothetical light sources. HSL and HSV are created from
| monitor CRT RGB using piecewise functions for the hue. No
| colorimetric considerations are given at all: it's all about
| how to mix an algebraic mean.
| p1mrx wrote:
| > Hue would be wavelength
|
| This doesn't work, because
| "https://en.wikipedia.org/wiki/Magenta is an extra-spectral
| color, meaning that it is not a hue associated with
| monochromatic visible light."
| bitL wrote:
| How is color distance computed for these? Still Euclidean or a
| different measure? Euclidean on RGB leads to "grayification" of
| colors.
| arthur2e5 wrote:
| On the original OKlab Euclidean will do. Perceptually-uniform
| color spaces are designed for that (at least for close colors).
|
| On these slightly squished and stretched ones... I think
| converting back to OKlab is the better idea. You can just turn
| the polar stuff into Cartesian directly too, but it will be
| distorted.
| danzk wrote:
| Craig Blackwell on YouTube has a great series of videos about the
| fundamentals of color vision. https://youtu.be/iDsrzKDB_tA
| lettergram wrote:
| There's some really cool features about lab-like color spaces.
| Particularly, the ability to quickly find, localize and transmit
| data (from with lower error rates):
|
| https://austingwalters.com/chromatags/
|
| In almost every computer vision class I took, switching to the
| LAB color space and rerunning algorithms also still always led to
| improvement.
|
| The real trick in my mind is trying to do this via sensors and /
| or hardware.
| arthur2e5 wrote:
| The OKlab definition is probably a bit easier to implement in
| hardware than CIELAB since there's no funny "if" branch. Still,
| the number representation will be more complicated than YUV and
| such... fp16 maybe?
|
| IIRC author of the TFA has retweeted some shader implementation
| of OKlab for color interpolation.
| woofie11 wrote:
| I think the real story is subjective, not quantitative. Color
| pickers:
|
| https://bottosson.github.io/misc/colorpicker/
|
| OKHSL works a lot better than the alternatives. It's really nice!
|
| OKHSV doesn't seem as good, and neither do the other new ones.
| sabellito wrote:
| Oh that really helped me understand this whole thing.
| JKCalhoun wrote:
| And speaking subjectively, I have always preferred HSV because
| I came to color from the background of mixing pigments
| (painting). Adding white to a pigment to desaturate it (make it
| more _pastel_ ) is intuitive with paints ... as is adding black
| to darken a pigment.
|
| HSV (and Okhsv) more closely match my painterly intuition.
| dasyatidprime wrote:
| HSV and not HSL for that mental model? That's surprising to
| me--I thought the tint/shade system would lead to wanting to
| put max-chroma in the middle.
| wolframhempel wrote:
| I'm fascinated by this field - ultimately all 2D color pickers
| show a slice of a 3D structure and we use one dimension (usually
| brightness) to navigate through the Z axis of this structure. A
| while ago I built this experiment to show how true 3D color
| pickers would work: https://wolframhempel.github.io/skeeem/
| ziml77 wrote:
| Why does it flood my navigation history? I couldn't use my back
| button to return to here after playing around a bit.
| arthur2e5 wrote:
| Apparently it saves what you do to the address bar. Which is
| good on its own, but messes up history when you use
| href.assign() instead of .replace().
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Location/re...
| spicybright wrote:
| This is ridiculously cool, thank you for sharing :)
| eyelidlessness wrote:
| I've used HSLuv a fair bit, and while it's great for e.g.
| programmatically ensuring good contrast... it produces some
| unpleasant colors especially in the yellowish range. I'm going to
| try out Okhsl as a replacement because it sure looks nicer to my
| eyes, at least on my phone.
| codedokode wrote:
| What I don't like in standard HSV color picker [1] is that the
| colors are distributed non-uniformly. For example, there is a
| wide area of same looking green color, but just a thin line of
| yellow and orange. I didn't understand if new models solve this
| issue.
|
| [1] https://bottosson.github.io/img/colorpicker/hsv-picker.png
| anderskaseorg wrote:
| You can try it out in the interactive color picker comparison
| page linked from the article.
|
| https://bottosson.github.io/misc/colorpicker/
| rauhallinen wrote:
| I had a project where I had to convert absorption spectrum of a
| liquid sample into a colour. It was one of those "Just do this
| quick, it doesn't have to be perfect" type of things where I
| didn't get a chance to really understand it. I was baffled how
| many standards and technicalities there is behind a seemingly
| simple thing.
| aaaaaaaaaaab wrote:
| Take the dot product between 1 - your spectrum and the CIE XYZ
| color matching functions, then convert it to sRGB or any other
| color space of your choice.
| chrismorgan wrote:
| Good related reading:
| https://raphlinus.github.io/color/2021/01/18/oklab-critique....,
| with some analysis of various colour spaces of different types,
| focusing especially on their behaviour in gradients, to do with
| interpolation.
|
| My biggest complaint about perceptual colour spaces has been that
| they make working with colours near gamut boundaries _really_
| hard. For example, with #ff0 (yellow) in LCH, you can't tweak
| _any_ of the three parameters in _either_ direction without going
| out of gamut (play with it at https://css.land/lch/ to get a
| vague idea of what I mean, though it doesn't handle going out of
| gamut well). Yet such colours have plenty of practical value, and
| it's a shame that many things eschew them because they've drunk
| _too much_ perceptual uniformity kool-aid. Colour palettes often
| just don't have any decent yellows _at all_. (To be sure, you
| _do_ need to use such colours with care, but to remove them
| altogether is distressing.) For colour pickers especially,
| perceptual colour spaces have just been no good, because of their
| weird shapes and because you're more likely to want to pick
| interesting colours nearer gamut bounds.
|
| So I'm really glad to see this, because it's just what I've been
| grumbling about the absence of. Thank you Bjorn, I continue to
| enjoy your work!
| nerdponx wrote:
| IMO perceptual uniformity isn't even necessarily desirable in
| all (or even most) cases.
|
| The only time I think it's really necessary is making color
| palettes for data visualizations.
|
| Otherwise, if you're e.g. designing a color palette for a
| webpage, you probably _do_ want some variation in perceived
| brightness. Heck, I could think of plenty of valid data
| visualization scenarios where you 'd want this.
| jstummbillig wrote:
| I want to be able to have variation in perceived brightness,
| but not as a side effect while browsing for a hue. I doubt
| most designers would argue otherwise.
|
| Compare it to waiting for a compiler: Sure, you can use the
| time off to stretch and take a sip of tea but there would be
| no serious opposition to compilers working at double speed
| tomorrow. It's simply better to not _have_ to wait (all else
| being equal). But it 's something you accepted and you deal
| with it, so wait you will.
|
| The current color pickers are an annoyance that we have lived
| with since, well, always, but an annoyance nonetheless. Happy
| to adopt these pickers if they gain adoption. OKHSL and OKHSV
| look spiffy.
| atoav wrote:
| Another application that might not be as rare as one would
| like to think is color-interpolation. Interpolating colors in
| a way that doesn't make them perceptually brighter or darker
| is hard.
|
| As someone who deals with color pickers a lot, it is just
| nice to have multiple options. Sometimes I just wanna punch
| in a hex number, sometimes I want a SV+H square, sometimes
| HS+V works better, etc.
|
| I see value in having a color picker that allows you to pick
| colors without changing brightness. E.g. imagine you let
| users pick colors that should work on a background that you
| designed. giving them a color wheel that stays perceptually
| at the same brightness has value here, because no matter
| which color they choose the brightness-contrast on your
| background will work.
| amluto wrote:
| Wow, you're not kidding about the LCH picker working poorly
| near the gamut boundary. Changing hue is especially poorly
| behaved.
|
| Hint to people trying to reproduce this: start by clicking the
| input button at the top and typing #ff0
| user-the-name wrote:
| Perceptual colour spaces are basically great if you want to
| pick an exact colour for the mud you are drawing.
|
| They really, really aren't good for picking useful colours.
| People don't keep using HSV because they are idiots, and have
| remained idiots for the last thirty years, they are using HSV
| because it lets you pick usable colours.
|
| The article goes through a lot of deep, thoughtful work only to
| arrive at an end result of this:
| https://bottosson.github.io/img/colorpicker/okhsl_circle.png
|
| A circle of different muds and a little bit of hot pink.
| Chris_Newton wrote:
| _My biggest complaint about perceptual colour spaces has been
| that they make working with colours near gamut boundaries_
| really _hard._
|
| I agree, this can be awkward. I like using perceptual spaces
| because they are self-evidently a "neater" starting point for
| colour work than something artificially distorted like HSL or
| (horror!) RGB, but it's important to recognise that they offer
| an incremental improvement and don't magically solve all
| problems. In particular, producing a useful and/or
| aesthetically pleasing result still isn't necessarily as simple
| as varying one axis in isolation, because you can quickly fall
| outside the available gamut that way.
|
| As a practical example of this, I recently needed a scheme for
| a variation of syntax highlighting in a structured document. My
| requirements were:
|
| 1. around 10 clearly distinct hues
|
| 2. all colours maintaining good contrast with a white
| background
|
| 3. no colour appearing too bright relative to the near-black
| unhighlighted text
|
| 4. all colours at a similar level of perceived lightness to
| avoid unintentional bias or emphasis.
|
| My starting point was to choose evenly spaced hues within a
| perceptually uniform colour space, pick a medium-to-low value
| and look for maximum chroma in each case. This wasn't a bad
| start, but it still needed significant practical adjustments
| like increasing the value for colours around the yellow/green
| area and dropping a hue entirely so I could space others around
| the blue/purple area more widely. Otherwise, however
| perceptually uniform the scheme might theoretically have been,
| in practice it would have ended up with the yellow/green area
| colours looking washed out and the blue/purple ones not
| distinctive enough under some realistic viewing conditions.
| neolefty wrote:
| I played around with a perceptual color space and made an
| interactive doodle that you can see here:
| https://hexpansion.io/ - click on "Colors".
|
| The blobs attempt to spread out in a perceptual color space.
| You can add more blobs with + and remove them by clicking on
| their pie slices or on a blob directly.
|
| Code is based on an older perceptual color space:
| https://github.com/neolefty/hexerals/tree/master/src/color
| jimmygrapes wrote:
| FYI the + button doesn't work for me on Android Fennec
| (Firefox) 91.2.0 (Build #912020), though the rest seems to
| jboy55 wrote:
| Very interesting, but I had a question about the background
| color on the page. but first some ... background. A long
| time ago, I worked at a digital printer manufacturer and I
| was building a equal perceptual gradient target for a
| backlit transparency material, Ilfochrome, at a customer
| site. One thing I found interesting was how much the
| perception of how 'linear' the gradient looked depended on
| how bright the background was.
|
| A 'target' was a set of densities we would calibrate the
| machine to reach for a particular RGB value. 0,0,0 = 3.4D
| and 255,255,255 = .04D (for transparent material).
|
| One group in the company insisted on a simple cube root
| density drop off, based on a reading of the L* formula.
| However, when the customer printed a large gradient with
| it, they rejected it. It looked like the 'linear' gradient
| on your site. However, when we put the test pattern (a
| small 4x8") pattern on the light board, it looked perfect.
|
| So we tried an experiment, we printed 3 gradients on a full
| sized sheet, (50 inchesx50 inches), one with a 'clear'
| background, one with a 50% grey and one with a black
| background.
|
| I was in the field, so I found a gradient that looked good,
| but did a bunch of study when I got back, I felt that some
| of the newer CIE models at the time did take into account
| background.
|
| Tldr; I was curious is your page and those models included
| into its gradient calculation what the surround is? Also,
| it would be interesting to display these with an adjustable
| background. (dark, light, grey), or with colors.
| deltron3030 wrote:
| What's interesting is that the HSL/HSV wheel in Adobe programs
| has a slightly different disribution compared to the rest of the
| industry, they've basically tweaked it perceptually. This yields
| different results in their color grading tools within camera raw
| and premiere.
| NGRhodes wrote:
| It gets even worse when you go from human eye to screen (eg sRGB)
| to print (eg Pantone).
| danzk wrote:
| I think what you are seeing is the effect of optical brighteners
| that are used in paper. They absorb UV light to and emit blue
| light to make the paper look whiter. The amount of UV light in
| the environment changes the color of the paper.
| herf wrote:
| I love this work - the OKLab model is really wonderful.
|
| But I think for color pickers, there are cases where "constant
| lightness" is not the most important constraint. For instance,
| you might really mean "the most saturated primary in each hue"
| and then - you may want the most saturated colors to appear on a
| line (saturated red, saturated blue, etc.). A constant lightness
| constraint makes these appear in a really unpredictable pattern.
|
| In less saturated colors, this constraint is very useful and
| feels right, but I think at the extremes it may reduce usability.
| armchairhacker wrote:
| I really like the de-saturated color wheel / hue slider in this.
| It makes it very noticeably easier to pick good de-saturated
| colors.
| caturopath wrote:
| Great conference talk with a brief recap of color perception
| https://www.youtube.com/watch?v=xAoljeRJ3lU
| toastal wrote:
| My phone and laptop, and browsers support DCI-P3. Is there a
| color picker for wider gamuts? Because the article keeps talking
| about sRGB and picking in that color space, but I feel like is
| limiting the capabilities of current technology.
| zamadatix wrote:
| I had the same question looking into HSLuv recently. Came
| across this https://github.com/hsluv/hsluv/issues/73 but it
| didn't really gain much traction. Maybe it'll be more popular
| once Chrome finishes CSS Color Module Level 4 color space
| support.
___________________________________________________________________
(page generated 2021-09-12 23:00 UTC)