> I typically use hsl instead of hex codes because it is easier to understand and modify. You can quickly build up a palette by just modifying the lightness scale on each color by a constant percentage. (This is where I disagree with the author, all of design is just math)
Unfortunately, the “math” of color models like HSL is only very loosely related to the science of human color perception. It was a model developed by computer graphics researchers of the 1970s who were not very knowledgeable about 20th century color science and dealing with very limited hardware capabilities compared to today, roughly based on outdated ideas from the 17th–19th century... and frankly not very well designed even within those constraints. As a result, leaning too heavily on HSL (especially for novices) typically leads to garbage results. An experienced artist picking colors visually will do much better than someone largely relying on HSL numbers.
If you want to pick colors based on numbers, look up the Munsell color system (a big lookup table from the early 20th century; the “modern” version was developed by the leading American color scientists of the 1940s), CIELAB (from the 1970s, an inferior but based-on-a-simple-formula Munsell clone), or CIECAM or IPT models (more recent and more complicated formulas).
But let's not throw away the baby with the bath water...
A huge value of HSL is being able to verify that you're keeping hue constant. Or, to change hue everywhere slightly (when you decide you want a 214 blue instead of 217).
The second value of HSL is that it's easy to look at a code and understand its brightness and saturation semantically.
But I agree that you absolutely need to manually pick appropriate lightness and saturation values to match what you want perceptually, and that changing lightness often requires changing saturation as well.
You can also use the better-implemented color picker for the HSLuv color space at http://www.hsluv.org/. HSLuv is just like LCH except that it stretches the saturated colors for each hue so that any saturation coordinate represents a valid color, unlike LCH’s chroma coordinate. The downside is that the color’s chroma (colorfulness) can change when you drag the hue slider.
To be clear, HSLuv, is based on CIELCHuv, the cylindrical transformation of CIELUV [0]; the LCH in David Johnstone's colour picker is CIELCHab, the cylindrical transformation of CIELAB [1].
Of course, that doesn't contradict your comment about the pros and cons of HSLuv's "saturation" component.
I think it still has some value. A few years ago I was building my color palette, and discovered through trial and error that if I keep saturation and luminosity constant, and just change hue to cover the color space, I get a pretty good looking set of colors. I'm not sure if there's science behind it, but it works in practice, at least for me.
That's awesome. It makes me think, though, that we could do a lot better than RGB given accurate values for actual human cone sensitivity and better subpixel colors. We should be able to get a digital gamut that fully spans the visible spectrum.
Yes we could get much better results with more primaries in our displays. It would take some fancier digital signal processing, and more importantly would only be especially useful for images designed with the wider gamut in mind (or potentially even multispectral images), but is possible using current technology, and probably not impossibly expensive.
Personally I would love to see displays made grids of hexagonal pixels, and maybe 7 primaries. Since almost every image that goes to displays today already needs to be rescaled at runtime, the processing shouldn’t need to be impossibly much more expensive than current square-grid resampling.
I would also love to see digital camera sensors with more primaries in a better pixel arrangement.
7 seems like overkill, but ok. :D Is that helpful for being able to display the full gamut of visible color more than 4 primaries, or even just 3 that are closer aligned to our eyes?
I picked 7 because it works nicely with hexagonal pixels. :-)
But the primaries can be relatively close together in color. It’s fine if we have e.g. 2 reds, 2 blues, and 3 greens instead of 1 of each.
Or for an LCD, some of them could be broader-spectrum primaries which were brighter but less colorful, while others could be more intense narrow-spectrum primaries. This would make the display more color accurate for various observers (more robust against “observer metamerism”), and would make the display overall brighter for the same intensity of backlight.
Or I dunno.. I’m not an expert in display technology, I’m sure the engineers could come up with many ideas.
Unfortunately, the “math” of color models like HSL is only very loosely related to the science of human color perception. It was a model developed by computer graphics researchers of the 1970s who were not very knowledgeable about 20th century color science and dealing with very limited hardware capabilities compared to today, roughly based on outdated ideas from the 17th–19th century... and frankly not very well designed even within those constraints. As a result, leaning too heavily on HSL (especially for novices) typically leads to garbage results. An experienced artist picking colors visually will do much better than someone largely relying on HSL numbers.
If you want to pick colors based on numbers, look up the Munsell color system (a big lookup table from the early 20th century; the “modern” version was developed by the leading American color scientists of the 1940s), CIELAB (from the 1970s, an inferior but based-on-a-simple-formula Munsell clone), or CIECAM or IPT models (more recent and more complicated formulas).