Generating UI colors palettes, like Radix Colors, Open Color, etc.?

[hyperknot]

I'd like to ask, in your opinion, what is the right way of generating UI color scales from a single, custom hue?

I mean similar to the 12 levels offered by Radix Colors, Open Color, Tailwind, Open Props, etc.

Radix has a custom palette generator, looks nice on the surface, but doesn't generate nice colors for some hues.

I'm storing the colors in oklch, and I've seen that Open Props does simple L and C manipulation like this:

  '--color-0':  'oklch(99% .03 var(--color-hue, 0))',
  '--color-1':  'oklch(95% .06 var(--color-hue, 0))',
  '--color-2':  'oklch(88% .12 var(--color-hue, 0))',
  '--color-3':  'oklch(80% .14 var(--color-hue, 0))',
  '--color-4':  'oklch(74% .16 var(--color-hue, 0))',
  '--color-5':  'oklch(68% .19 var(--color-hue, 0))',
  '--color-6':  'oklch(63% .20 var(--color-hue, 0))',
  '--color-7':  'oklch(58% .21 var(--color-hue, 0))',
  '--color-8':  'oklch(53% .20 var(--color-hue, 0))',
  '--color-9':  'oklch(49% .19 var(--color-hue, 0))',
  '--color-10': 'oklch(42% .17 var(--color-hue, 0))',
  '--color-11': 'oklch(35% .15 var(--color-hue, 0))',
  '--color-12': 'oklch(27% .12 var(--color-hue, 0))',
  '--color-13': 'oklch(20% .09 var(--color-hue, 0))',
  '--color-14': 'oklch(14% .07 var(--color-hue, 0))',
  '--color-15': 'oklch(11% .05 var(--color-hue, 0))',

But then I read that oklch is actually not "symmetric" in this way, you cannot just change the hue and keep the rest as it'd get out of gamut.

The other interesting phenomena I've noticed is that the hue values skew slightly both in Tailwind and in Radix Colors, when converted from p3 -> oklch.

For example this is Radix's slate color converted from p3 -> oklch:

slate1: 'oklch(99.12% 0.00148 286.37)',
slate2: 'oklch(98.239% 0.00296 286.35)',
slate3: 'oklch(95.574% 0.00448 281.88)',
slate4: 'oklch(93.144% 0.00601 282.96)',
slate5: 'oklch(91.009% 0.00755 283.59)',
slate6: 'oklch(88.762% 0.00913 281.79)',
slate7: 'oklch(85.336% 0.01155 280.85)',
slate8: 'oklch(79.387% 0.01577 278.12)',
slate9: 'oklch(64.557% 0.01621 277.83)',
slate10: 'oklch(60.975% 0.01583 273.24)',
slate11: 'oklch(50.265% 0.01374 263.44)',
slate12: 'oklch(24.125% 0.00978 249.52)',

Does this skewing mean that the hue model used in oklch is not reflecting the human visual "hue" perception?

[facelessuser]

The example you've provided doesn't really provide information on the seed hue or how they post-process the color after, but I can give you a rough idea as to what is likely happening.

1. OkLCh is not a symmetrical color space, it is a perceptual color space.

   Usually the colors in a perceptual color space are manipulated such to have consistent JND (just noticeable difference) between the colors. The actual success of this can vary from perceptual color space to perceptual color space, but generally, they do a better job at keeping lightness and hue constant than something like HSL which does so quite poorly.

   Colors at different wavelengths don't always have the same chromatic response and when adjusted to be perceptually consistent, the space is not symetrical. Take a look at the Oklab color space rendered within the sRGB gamut.

   

2. So why does the lightness and hue shift? It depends on what they are doing after they create the color. We've noted that the space is not symetrical, so lets try to interpolate colors at various lightness keeping hue and chroma constant.

   

   Colors are all out of gamut. So what happens when we clip them? Well, the colors are now in gamut, but the hue and lightness shifts around a lot.

   

   While CSS has still not decided on a definitive gamut mapping approach, the one currently listed in the spec does a much better job reduces the chroma to get the color back in gamut. It should be noted that it doesn't purely reduce chroma, but also checks the color distance and once it is within the JND range it then clips. This allows for a very small amount of lightness shifting and some hue shifting, usually in very light or very dark colors where it is generally harder to tell there is a shift.

   

   If we reduce the JND requirement to a very small number, we hold hue and lightness more constant, but it may be difficult to see the difference as much in a plot of this kind, but hue would be held much closer across all colors along with lightness. Though, if you can't visually tell the difference, between the other approach, more shifting may be fine.

   

   Instead, you can compare approaches here. You can see less lightness and hue shifting with low JND, but it is hard to tell the difference visually.

   

In short, it would be important to know exactly what approach they are using to get those colors back into gamut. Some approaches do much better than others.

[hyperknot]

Thank you for your reply. Since, I've started reading about Leonardo and it's JS package contrast-colors.

By out of gamut, can you explain what do you mean? Do you mean these are generated by putting out-of-gamut colors back into gamut? And if so, which one, sRGB?

slate1: 'oklch(99.12% 0.00148 286.37)',
slate2: 'oklch(98.239% 0.00296 286.35)',
slate3: 'oklch(95.574% 0.00448 281.88)',
slate4: 'oklch(93.144% 0.00601 282.96)',
slate5: 'oklch(91.009% 0.00755 283.59)',
slate6: 'oklch(88.762% 0.00913 281.79)',
slate7: 'oklch(85.336% 0.01155 280.85)',
slate8: 'oklch(79.387% 0.01577 278.12)',
slate9: 'oklch(64.557% 0.01621 277.83)',
slate10: 'oklch(60.975% 0.01583 273.24)',
slate11: 'oklch(50.265% 0.01374 263.44)',
slate12: 'oklch(24.125% 0.00978 249.52)',

I mean this is a UI library targetting wide range of users/devices so I'm sure they have to target sRGB, or at least a way that makes browsers fall-back to sRGB if the source color would fall out-of-gamut. I don't know if browsers automatically do this when using oklch color spaces.

So do you think these are generated from just a single hue, and then interpolated somehow?

[facelessuser]

Keep in mind that I am making a number of assumptions right now as I don't know exactly what they are doing. I'm only sharing what I think they may be doing.

By out of gamut, can you explain what do you mean?

Like I showed in the diagrams. Monitors and such have a range of colors they can display (a gamut). If a color is outside that range, it is out of gamut. Some popular gamuts for monitors are sRGB and Display P3.

Do you mean these are generated by putting out-of-gamut colors back into gamut?

I would assume so. To display the color on your screen, they would have to be getting the colors back into gamut, or the browser will do it if it isn't using whatever approach they choose. Right now, browsers clip as a final gamut mapping approach has not been decided.

And if so, which one, sRGB?

Again, I don't know, but I would assume sRGB as it would be the safest gamut to target, as most screens support this; otherwise, they are letting the browser clip or gamut map the colors.

So do you think these are generated from just a single hue, and then interpolated somehow?

Again, I don't know exactly, as I haven't dug into what they are doing, but I would assume the easiest way is to start with a seed color and modify the lightness to different levels. Once the new color is created, gamut map it back to the your display gamut. Similar to what I demonstrated.

[hyperknot]

You are right, the oklch looks the best on your demo, and possibly ictcp, but that has a strange gamma.

So what you are saying is that fixing H in oklch is actually "visually stable" for palettes?

About gamut, from what I'm reading browsers automatically do a display-specific fallback in oklch and similar modern modes, so maybe there is no need for gamut mapping when using oklch in CSS?

[facelessuser]

You are right, the oklch looks the best on your demo, and possibly ictcp, but that has a strange gamma.

Yep

So what you are saying is that fixing H in oklch is actually "visually stable" for palettes?

As long as your method of bringing it back into gamut keeps it stable, but yeah, it has pretty good consistency for hue.

About gamut, from what I'm reading browsers automatically do a display-specific fallback in oklch and similar modern modes, so maybe there is no need for gamut mapping when using oklch in CSS?

Not really. Browsers currently just clip colors that are out of gamut, and that does an terrible job of keeping hue constant, but it does keep colorful colors more colorful.

More advanced gamut mapping is still being discussed here: w3c/csswg-drafts#10579.

[hyperknot]

Then I don't understand. Evilmartians write this:

The CSS Colors 4 spec requires browsers to use the OKLCH method for gamut mapping. But still, right now, Chrome and Safari use the fast, but inaccurate, clipping method. That’s why we currently recommend manual gamut mapping and adding both sRGB and P3 colors to CSS:

And the specs say this:

CSS gamut mapping occurs in the OKLCh color space, and the color difference formula used is deltaEOK. The local-MINDE improvement is used.

Draft says that gamut mapping should be done in a given way, but practically speaking every browser does it in a different way, as discussed in your linked thread?

[hyperknot]

In the meanwhile, I found how Radix generated those palettes. They used color.js, with what I see are some hand picked bezier curves and interpolated over lch.

https://github.com/radix-ui/design-system/blob/master/custom/ColorTools.tsx

[facelessuser]

Draft says that gamut mapping should be done in a given way, but practically speaking every browser does it in a different way, as discussed in your linked thread?

CSS made a suggestion, but browsers did not agree, and so they never implemented it. That's why the discussion is happening. Browsers are just doing what they've always done, simple clipping, until a more advanced algorithm for gamut mapping is decided.

[LeaVerou]

Ah, the holy grail of dynamically producing color tints. I've been working on this on and off for at least two years and still haven't cracked it. Caution fellow travelers, I nearly lost my mind trying to figure this out.

First, gamut mapping is an area of active work in the CSS WG right now. Here are the most recent updates: w3c/csswg-drafts#10579

But the topic of generating tints from a single key color with aesthetics comparable to tints hand-tweaked by a designer goes way beyond gamut mapping. It's one of those things where getting close is easy, but beyond a certain point, getting closer is exponentially harder.

You can see some of my research data here: https://palettes.colorjs.io/
It plots colors from popular palettes in any color space you pick. The data is getting old at this point, e.g. I know Tailwind now has a new palette. You can send a PR and add more.

My hope was to find a color space with sufficient regularity that creating tints would be a simple matter of tweaking a coordinate (or at least where the math would be straightforward). So far, I have not succeeded in finding such a space.

OkLCh seems to be the best color space for this work, but the math is still far from straightforward. We were sold the idea that perceptual color spaces will solve all our color scale problems and finally realize the promise of dynamic color scales. After studying designer-created color palettes, I have come to the conclusion that color scale generation is fundamentally an activity involving multiple perceptual color components. It's not that the color spaces are problematic, it's that we don't really want perceptual uniformity.

When designers see what only tweaking lightness does, it doesn't look good, even after gamut mapping.
E.g. this is an OkLCh chart of the OpenProps color scales:

Gamut mapping is usually sufficient for darker tints, but not lighter tints.
Tints often involve a drop in chroma, especially for lighter tints.

The drop varies depending on what tint your key color sits at, and what your key color chroma is, but I have not found a good formula for predicting it. It even varies by hue. Gamut mapping does bring you a lot closer, but not close enough.

Some people use color-mix() and mix with white or black. That produces washed out colors. It's basically an attempt to control lightness and chroma at the same time, but you have no control over the progression. As you can see in the charts, you need linear-ish L, but the C looks more like a power curve (that is even different for darker vs lighter tints).

Even hue is not constant! Certain hues involve hue shifts, with dark yellows having the strongest shifts, to make them warmer and avoid the diarrhea aesthetics that cooler dark yellow can have:

Blues often have some degree of shift, to avoid purpling (yes, even in OkLCh, whose main premise was to avoid this kind of purpling).
But different palettes differ for their hue shifts, and I think often hue shifts are used as a way to create visual interest.

The thing is, aesthetics != perceptual uniformity. An idea I've heard from time to time is what if we could create a color space optimized for this work. But there are certain colors you pretty much never want in a color scale because they just …look ugly. Cool dark yellow being the poster child. So the gamut of such a color space would be very weird.

At this point, I think what we need is a) more data and b) someone with a background in numerical analysis just producing a model…