For those just learning about perceptual colour spaces, I’d recommend exploring OKLab which is simpler to implement and overcomes some of the problems of CIELab.
If you ever need to generate a gradient between colors in any of your code, interpolating colors in the Lab color space is an awesome option. A simple linear interpolation of the components gives impressively beautiful results.
(Although, like several other commenters, I do recommend OKLab.)
I right away admit that I am an absolute novice in this space, but I have a few questions. The question I always had is why do we not model it closer to the actual tangible Physics and Biology going on ?
For example, the Physical reality is the different frequencies of light. The Biological reality is that different types of cells on our retina respond with differing intensity to each of those frequencies.
So to my naive mind, a way of modeling color is to have (i) a forward model that map light frequencies to response intensities of the different types of cellular light receptors and (ii) an inverse model that estimates the frequency mix of light from the cellular responses.
That is, have two spaces (i) the light frequencity space (a list of tuple of frequency and intensity/power at that frequency) and the (ii) cellular response space.
Once we have these, we can go from a pigment or excited phosphor to a biological response in a two step process.
From (a) pigment/phosphor (+ frequency mix of illuminating light) to output light frequencities (b) from those frequencities to cellular response.
For all processing, make frequencities the base space to work in (allowing us to change/personalize the forward model).
Yes, the inverse model leads to an ill posed inverse problem, but we are now very knowledgeable about how to solve these.
The frequencies may need to discretized for convenience.
I am obviously a novice and don't know much about modeling color, but this way of modeling seems more grounded in the tangibles. This also gives a way to model how a color-blind person might perceive a picture.
Is the reason that we do not do it this way it's complexity ?
Interesting, I wanted to have random distribution of colors for small flower pixel art generator, also chose to use other color spaces, including Lab, so my colors would be more similar to human world perception, and not machine color representation
It probably sounds silly, but this minecraft youtuber did a nice job of explaining color spaces and Oklab in particular in a way that clarified things for me: https://youtube.com/watch?v=nJlZT5AE9zY
I'm a fan of HSLuv (https://www.hsluv.org/comparison/) for design work (when sRGB is fine and you don't need P3 colors). It's perceptual uniformity like Lab, but has familiar looking hue, saturation and lightness sliders instead like you'd see in a regular HSL color picker.
I've used HSLuv for an accessible palette editor (https://www.inclusivecolors.com/), so you get the familiarity of an HSL color picker, but unlike with HSL, when you change hue or saturation, the lightness and WCAG contrast stay the same, which makes HSLuv a great for exploring accessible color combinations without breaking the contrast you've set up already between your existing color pairs.
OKLCH is becoming a popular choice if you need P3 colors and perceptual uniformity because it's built into CSS now, but I find the colors pickers for OKLCH tend to look really complex and unfamiliar to use so I'm skeptical it's going to get popular with designers (it's mostly developers recommending OKLCH that are interested in the technical/coding part rather than the design part?). What are good choices if you want P3, perceptual uniformity, and an intuitive color picker UI?
I'm building a color separation engine for screen printing that operates entirely in CIELab — Photoshop is hardwired for it, so while OKLab is mathematically superior for hue linearity, the constant translation overhead isn't worth it when you're doing surgery on 16-bit photography into discrete spot-color plates.
The real proof of moving away from Euclidean RGB distances isn't in the composite — it's in the separated plates. Look at the individual channels of a complex texture like weathered terracotta through a Lab-aware engine, and the structural integrity of the gradients is night and day compared to legacy indexing. Even 1976-era Lab is a massive leap from RGB heuristics.
11 comments
[ 4.0 ms ] story [ 30.2 ms ] threadsRGB like Lab* is device independent so a transformation between the two is possible.
RGB on the other hand is device dependent, and would therefore require a device ICC Profile to convert to Lab*.
* https://repo.autonoma.ca/repo/delibero/blob/HEAD/source/xsl/...
* https://repo.autonoma.ca/repo/delibero/blob/HEAD/source/xsl/...
An example pie chart is on page 33, section 9.2.3:
* https://repo.autonoma.ca/repo/delibero/raw/HEAD/docs/manual/...
* https://i.ibb.co/ymDLcPNj/pie-chart.png (screenshot)
The colours are harmonious, visually distinct, and not hard-coded to a fixed number of slices.
https://bottosson.github.io/posts/oklab/
(Although, like several other commenters, I do recommend OKLab.)
For example, the Physical reality is the different frequencies of light. The Biological reality is that different types of cells on our retina respond with differing intensity to each of those frequencies.
So to my naive mind, a way of modeling color is to have (i) a forward model that map light frequencies to response intensities of the different types of cellular light receptors and (ii) an inverse model that estimates the frequency mix of light from the cellular responses.
That is, have two spaces (i) the light frequencity space (a list of tuple of frequency and intensity/power at that frequency) and the (ii) cellular response space.
Once we have these, we can go from a pigment or excited phosphor to a biological response in a two step process.
From (a) pigment/phosphor (+ frequency mix of illuminating light) to output light frequencities (b) from those frequencities to cellular response.
For all processing, make frequencities the base space to work in (allowing us to change/personalize the forward model).
Yes, the inverse model leads to an ill posed inverse problem, but we are now very knowledgeable about how to solve these.
The frequencies may need to discretized for convenience.
I am obviously a novice and don't know much about modeling color, but this way of modeling seems more grounded in the tangibles. This also gives a way to model how a color-blind person might perceive a picture.
Is the reason that we do not do it this way it's complexity ?
Eager to be illuminated (pun intended).
I've used HSLuv for an accessible palette editor (https://www.inclusivecolors.com/), so you get the familiarity of an HSL color picker, but unlike with HSL, when you change hue or saturation, the lightness and WCAG contrast stay the same, which makes HSLuv a great for exploring accessible color combinations without breaking the contrast you've set up already between your existing color pairs.
OKLCH is becoming a popular choice if you need P3 colors and perceptual uniformity because it's built into CSS now, but I find the colors pickers for OKLCH tend to look really complex and unfamiliar to use so I'm skeptical it's going to get popular with designers (it's mostly developers recommending OKLCH that are interested in the technical/coding part rather than the design part?). What are good choices if you want P3, perceptual uniformity, and an intuitive color picker UI?
The real proof of moving away from Euclidean RGB distances isn't in the composite — it's in the separated plates. Look at the individual channels of a complex texture like weathered terracotta through a Lab-aware engine, and the structural integrity of the gradients is night and day compared to legacy indexing. Even 1976-era Lab is a massive leap from RGB heuristics.