Unlocking Colors
bkardell.com
bkardell.com
Our eyes are very sensitive to color shades and we'll easily notice if something is off. Colors are carefully picked by designers to fit together in quite subjective and non-mathematical manner. From observing some well constructed palettes, I derived the basic process used to create them. Pick the approximate colors you want, arrange them so they are all visible, and then tweak color shades so that all of them could exist under same lightning conditions in physical world. If some color seems jarring or wrong, that's because it could only exist under different lightning from rest of palette.
The text seems to neglect the vast amount of information lost when we use just a single point in color space to represent the whole light spectrum. For example, magenta signifies presence of both bluish and reddish wavelengths. If your math is not based on spectrum components, how do you hope to arrive to correct color when mixing two spectrums? Linear interpolation between two points in color space?
I think HSL is huge improvement over RGB model for designers, but other color spaces aren't really worth the effort. If you need light and dark theme for your UI, both will need to be hand crafted. Shifting hues by 5% or calculating complementary color won't be good enough.
For another, its ranges are pretty bizarre. It's been a while since I hand-wrote the conversion, but if I recall correctly, the a and b axes had different minima and maxima, and the default conversion without any scaling ends up leaving you with ranges that are something like 0-200 for one axis and 0-500 for the other. You can scale these to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software.
Its shape is also non-intuitive. The range of visible colors it represents is not a cube or cylinder or sphere. It's a multi-lobed 3D object that's hard to reason about.
To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on. Users rarely have this information, and operating systems are pretty spotty on supplying it. (And users often misconfigure it.)
I agree it's a good color space for the uses it was designed for. Unfortunately, there are a lot of confounding factors that make it difficult for typical users, even technical ones, to use.
> You can scale [a and b axes] to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software.
Please don’t rescale the a* and b* coordinates. These are standardized and have remained consistent since the model was introduced in the 1970s.
> Its shape is also non-intuitive [...] hard to reason about
The gamut of RGB displays is not intuitive. That’s the whole point. If you squash it into a regular shape then people using it end up misled into thinking they are dealing with a regular shape.
In fact they are still dealing with the same weird irregular shape in terms of human-perceived color attributes, it’s just now their coordinates have been obscenely warped so they match the gamut but now have nothing to do with human perception.
So e.g. changing the HSL “H” parameter will not only inconsistently affect perceived hue, but will also dramatically distort lightness and chroma relationships between colors.
Anecdotally, having watched artists of various skill levels at work, this causes significant amounts of confusion. Pretty much everyone who uses HSL/HSV type models has no idea what they are dealing with, and the result is gross misunderstanding. When artists work with it long enough they can learn to work around it, but they end up with hilariously incoherent rationalizations and explanations for their heuristic techniques.
Believe it or not, working with perceptually relevant coordinates is more rather than less intuitive, even for complete novices, after just a tiny bit of explanation. This is because the model matches their first-hand experience. Moreover, because the model is consistent, formal knowledge aligns with experience and grows over time. It helps if the UI reveals what they are dealing with though. (For example, Photoshop’s CIELAB mode is not ideally integrated, and not very obvious to non-experts. But once understood it still makes the image editing process much smoother and more predictable.)
> To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on.
You always need this information to ingest an image from a specific camera or display an image on a specific display. If you [either you personally as an artist, or the software system you are working with] aren’t aware of the basic attributes of your system you’re going to end up with bad results.
There is no one “RGB”; every camera and every display is different. With some systems artists can let the software automatically make all of the choices along the way from image capture to display, but that would still be true under some change of working color space.
> uses it was designed for
The use CIELAB was designed for was colorimetric specification of surface colors, so that e.g. your plastic toy factory, paint mixing shop, or magazine printer could produce reliable results. It was designed to be simple enough that it could be computed in real time by hardware spectrophotometers of the 1960s–1970s.
But it also works as a pretty decent color space for judging human perceptual attributes. There are some better alternatives (IPT, CIECAM02, ...) but they are more complicated and less widespread.
The point is not really “mathematical manipulation” per se.
It’s helpful to have human-relevant coordinates anywhere humans are making the decisions, because it dramatically reduces human confusion, and leads people to make better informed decisions.
“HSL” and “HSV” (i.e. the RGB cube arbitrarily squashed into a cylinder) are bad models for human use, because despite their names the coordinates have little to do with human perception, and as a result create tremendous amounts of confusion and bad results, especially from anyone who isn’t an expert artist.
It was very intuitive and fast to find a good shade using this design. The key was modifying colors directly on design instead on separate UI panel, and using relative tweaking model for incremental approach to correct shade. HSL was great choice here.
Maybe other color spaces like CIE would be more successful if they were less CS- and math-heavy and simpler to understand for designers.
For the software developer, the only additional bit of trickiness is that some color changes will push a color out of gamut, so you need to implement some method of bringing those back into gamut. As a simple first method to try let me recommend preserving hue/lightness and clipping the chroma so the result fits within the gamut.
When it was just a parameter conifg file, there was only the need to check lexical and grammatical consistency. Now we've got to have functional regressions and computations standards... and everything that comes with a compiler verification suite. Ugh.
On the one hand, I think it absolutely makes sense to keep color management in the CSS, but I also see a big ol' slippery slope.
Not true, hdr just means a better contrast ratio.
It still isn’t going to help you show a very intense dark teal color outside the capabilities of typical mix of RGB “G” and “B” primaries.
(1) The latest generation of displays (and presumably most displays in the future) use more colorful [spectrally spikier] “R”, “G”, and “B” primaries, with the result that they can display a wider range of chromaticities than an sRGB display.
(2) If you make the brightness of a diffuse white reference less than the maximum which can be produced by your display then you have more headroom in each primary, and you can produce a much wider gamut of bright colors. The possible dark colors which can be produced don’t change. This makes it possible to accurately display e.g. very colorful flowers – with linear RGB coordinates of say (2.0, 0.0, 1.5) relative to (1.0, 1.0, 1.0) meaning diffuse white – which could not otherwise be shown if diffuse white were set to be the brightest combination of primaries for the display, because then the flower would necessarily get clipped to (1.0, 0.0, 1.0).
[Sorry, this is a lot easier to see if you start looking at some graphics. It is not easy to clearly describe/understand with text alone.]
But for the second point, how is that relevant? I'm not sure how this helps, because a) this has nothing to do with the display, i.e. we could modify an image to show the same effect on all displays, and b) gamut has not become wider at all.
Instead of reaching a luminance of 80 of 100 nits, they can now reach 1000 or even 5000 nits.
What this means is that it is now possible to set the target “diffuse white” luminance to be something like 200 nits, but then still be able to produce colors in which any (or all) of the primaries is 5x more intense than that.
Until recently, it has been assumed that display white is (100%, 100%, 100%), whether the maximum display brightness happens to be 50 or 500 nits. But when displays can get to 1000 nits or beyond, that is no longer a tenable assumption.
* * *
If you have a conventional display (say a non-HDR TV or smartphone) you could still crank the display brightness all the way up but only show images or video where diffuse white was set to 20% of maximum (or whatever), and thereby achieve an expanded gamut for bright colors. But in practice few people if any ever did that.
You can even do the same thing with a painting: if you make your painting overall darker than usual, place it on a dark gray wall, and then shine a very intense light on it, you can give your painting more dynamic range and a larger color gamut than you would otherwise be able to achieve with the same materials. This technique has been used to good effect by some (but relatively few) master painters, photographers, etc.
The big rainbow has some problems too. It should be obvious by looking at the transition line from color to black-and-white that brightnesses are inaccurate. There's another problem that I don't ever see discussed - the yellow, cyan, and magenta colors really are brighter than the rest of the colors because of the way our monitors work, they have twice as many photons because they emit two different primary colors.