Hacker News Reader

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.

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

FYI the + button doesn't work for me on Android Fennec (Firefox) 91.2.0 (Build #912020), though the rest seems to

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.

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

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.

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.

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.

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.

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

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

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.