New alternatives to HSL and HSV that better match color perception

https://bottosson.github.io/posts/colorpicker/

by bjornornorn • 5 years ago

398 79 5 years ago

bottosson.github.io

junon2• 5 years ago

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• 5 years ago

HCG

https://github.com/helixd2s/hcv-color

HCG = Human Chorionic Gonadotropin, which will dominate your search results.

junon2• 5 years ago

Thanks, seems they renamed it recently.

rauhallinen• 5 years ago

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• 5 years ago

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.

PaulHoule2• 5 years ago

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.

jedimastert• 5 years ago

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

PaulHoule2• 5 years ago

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.

toastal3• 5 years ago

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.

numpad02• 5 years ago

“Technically correct” way would be to control the surroundings than adapt representations. High CRI lightbulbs, display hoods, wallpapers, etc.

nielsbot• 5 years ago

FTA: OKLab et al specifically excludes consideration of illumination environment for simplicity: "Should assume normal well lit viewing conditions"

https://bottosson.github.io/posts/oklab/

numpad02• 5 years ago

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.

arthur2e54• 5 years ago

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• 5 years ago

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

egypturnash2• 5 years ago

HSV/L are conceptually close to the way artists have been thinking about color for centuries, since the days when everyone ground their own pigments.

Hue is the angle on the color wheel. Which somewhat translates to wavelength if you ignore the fact that we see chords of high blue + low red as the colors we give names like purple, indigo, violet, and magenta.

Saturation is how intense the color is. Lower the saturation and it turns grey, or pastel. We have a few special names here; "pink" is a low-saturation red, for instance.

Value/lightness how dark/light a color is. Lower the value on that "pink" and you might get something you'd label "brick red": it's darker, it's still definitely reddish, but it's not the most intense red you can get while still being kinda dark.

Saturation collapses as you go to the extremes of value/lightness, it's just pitch black at one end and pure white light at the other.

bitL• 5 years ago

How is color distance computed for these? Still Euclidean or a different measure? Euclidean on RGB leads to "grayification" of colors.

arthur2e54• 5 years ago

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.

lettergram• 5 years ago

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.

arthur2e54• 5 years ago

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• 5 years ago

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• 5 years ago

Oh that really helped me understand this whole thing.

JKCalhoun• 5 years ago

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• 5 years ago

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.

chrismorgan• 5 years ago

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 Björn, I continue to enjoy your work!

nerdponx• 5 years ago

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.

atoav• 5 years ago

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.

jstummbillig• 5 years ago

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.

mark-r2• 5 years ago

I worked on software that had the ability to change the hue of an object. If you had a bright blue car and wanted it to be yellow, changing the hue to yellow worked perfectly. Then the perceptually correct zealots took over and mandated that all color manipulations would take place in the Lab color space. Now the intense blue 0,0,255 didn't turn into an intense yellow 255,255,0, it turned into what was considered a yellow of the same lightness - 31,31,0. This was too dark to be useful to anybody, and there was no way to compensate. Worse yet it wasn't even correct, because the lightness isn't accurate for intense saturated colors - if you look at 0,0,255 and 31,31,0 side by side you'll see what I mean, they're not even close to the same perceptual lightness.

amluto• 5 years ago

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

Chris_Newton• 5 years ago

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• 5 years ago

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

manceraio• 5 years ago

I created a tool that could help you on creating this type of palettes. It's based on CIELAB and you can see where all the colors are placed in the lightness, chroma and hue space. You can also see they boundaries for any family color so you know how much you can stretch chroma without shifting lightness or hue.

Tailwind.ink

user-the-name• 5 years ago

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.

jacobolus• 5 years ago

you can’t tweak any of the three parameters in either direction without going out of gamut

This is a good thing: it teaches you the shape of the gamut, and gets you working with colors consistently.

#FFFF0O does not have “plenty of practical value”. It is a very niche tool with an extremely small range of uses, and should be avoided almost all of the time.

For colour pickers especially, perceptual colour spaces have just been no good,

Just the opposite: for color pickers especially, using anything else makes it much much harder to get good results.

NGRhodes• 5 years ago

It gets even worse when you go from human eye to screen (eg sRGB) to print (eg Pantone).

toastal3• 5 years ago

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• 5 years ago

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.

toastal3• 5 years ago

Well, I gave it a +1 and a subscribe. Hopefully we can break the chains of sRGB soon.

wolframhempel• 5 years ago

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/

spicybright• 5 years ago

This is ridiculously cool, thank you for sharing :)

ziml77• 5 years ago

Why does it flood my navigation history? I couldn't use my back button to return to here after playing around a bit.

arthur2e54• 5 years ago

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

danzk2• 5 years ago

Craig Blackwell on YouTube has a great series of videos about the fundamentals of color vision. https://youtu.be/iDsrzKDB_tA

danzk2• 5 years ago

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.

deltron3030• 5 years ago

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.

herf• 5 years ago

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.

Applejinx• 5 years ago

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.

ianbicking• 5 years ago

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

kortex2• 5 years ago

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.

chrisseaton5• 5 years ago

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?

beckerdo• 5 years ago

Some color pickers allow you to load a palette of names and they locate those names and values in the color picker interface.

You can load common name sets (e.g. X11 color names, CSS names, Munsell names, Behr) and they map their values into your color pickers.

This works well especially with paint pigments as every manufacturer has their exotic names that they hype for that year. "Oh, 'Ice Blue' is really just a slightly blueish white."

kzrdude• 5 years ago

Did Björn do this work for the benefit of any particular app or project?

eyelidlessness3• 5 years ago

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.

eyelidlessness3• 5 years ago

It turned out… not good. That said the entire JS interface was unclear what numeric types it expected and I have no idea if I was using it correctly. I’ll take the yucky mustard yellow browns I have for now :shrug:.

eyelidlessness3• 5 years ago

When I did eventually produce colors I expected to be generally perceptually uniform, everything bluish was much much brighter than I expected. Drastically worse than HSL.

I don’t think this is a problem with the color space, I think the JS source wasn’t designed to be used by humans.

jobarion• 5 years ago

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.

codedokode2• 5 years ago

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• 5 years ago

You can try it out in the interactive color picker comparison page linked from the article.

https://bottosson.github.io/misc/colorpicker/

codedokode2• 5 years ago

Thank you for the link, very interesting. Now I see there's another problem: the colors on the hue bar (especially with OKLrCH model) look too blurred and mixed with each other. And there's almost no green, but mostly reddish and blueish tones.

caturopath• 5 years ago

Great conference talk with a brief recap of color perception https://www.youtube.com/watch?v=xAoljeRJ3lU

zeroimpl• 5 years ago

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?

armchairhacker• 5 years ago

I really like the de-saturated color wheel / hue slider in this. It makes it very noticeably easier to pick good de-saturated colors.

kdrag0n• 5 years ago

It's true that perceptual color spaces can be hard to work with, but they can help generate fairly good UI themes on-the-fly when used correctly. For UI, the ability to keep lightness constant regardless of chroma and hue is essential to preserve contrast. Likewise, hue is quite important to keep constant because it's the most prominent part of a dynamic theme. This leaves chroma as the remaining component that can be reduced to bring colors in gamut.

UI examples: https://twitter.com/kdrag0n/status/1427822417313898498 (using ZCAM, not Oklab or the new Oklab/Okhsv) / https://www.figma.com/file/ZeqPgO1RgA6eg8TMm7r8Ae/kdrag0n's-...

Full generated palettes: https://twitter.com/kdrag0n/status/1431100523894083589 / https://www.figma.com/file/mZ6VxvsC2yN4zD9rDR4S2I/kdrag0n's-...

Yes, it's very easy to create colors outside the sRGB gamut boundaries, and you have to compromise something in order to bring them back in gamut. However, when working with colors programmatically, I'd still recommend considering perceptually-uniform color spaces instead of HSL/HSV-style models that are made to simplify interactive color picking.

egypturnash2• 5 years ago

Damn, the way OKLrCH wiggles around as you drag the hue slider is kind of really unpleasant.

Daub• 5 years ago

Art teacher speaking. Hope the author is reading.

The figures directly under the sentence ‘Here is the sRGB gamut plotted for set of hues…’ have real utility which the author may have missed. They clearly show that the peak saturation value has a different lightness value for each hue. For example, a peak saturated yellow is required to be brighter than a peak saturated blue.

Explaining this to designers can be a real grind. These figures would make the task a lot easier.

I really wish for a color picker that did not normalize the color space (as in the figures that follow).

New alternatives to HSL and HSV that better match color perception

Related Stories