Arbitrary Beautiful Colors
Unfortunately, colors generated like this look really bad. They often come out muddy and ruddy, and generating more than one color doesn’t come with any pattern or structure. The colors are all over the place.
This is a structural problem with RGB. RGB is focused on how color is produced, rather than how it’s perceived.
Fortunately, the solution to this problem is well documented. There are a few blog posts out there (warning: JavaScript) that lay out an approach. The idea is this: by using a hue based color space, like HSL, you can hold two parameters constant (saturation and lightness), and modify only the hue, giving you multiple colors that live in the same “family”.
[…]
It turns out that the answer I was looking for was in a YouTube video I watched over 10 years ago. The remarkable Vi Hart published a series of videos (one, two, three) about how plants need to grow their new leaves in such a way that they won’t be blocked by the leaves above, which lets them receive maximum sunlight.
5 Comments RSS · Twitter · Mastodon
[facepalm]
I spent years in art school studying color systems and color harmonies/interactions by artists like Itten, Albers, Rood, Cezanne, Hayter, Munsell, Werner, etc etc. and decades since then working with pigments and on screens, this is by far the worst approach I have ever seen. In particular, I notice that his algorithm created colors that are almost indistinguishable from each other, you can only tell them apart because they are non-adjacent in his grid and have a contrasting color between them. God forbid you should use these colors in a line chart! Also it makes no accommodations for color blindness.
Please please consult artists about color rather than programmers. We know things. For example, we know the mnemonic "Red Cadillac BY General Motors," Red/Cyan, Blue/Yellow, Green/Magenta. This would immediately solve this fellow's confusion about RGB color spaces: it is the inverse of CMY colors as used in additive vs. subtractive colors. There are pairs of Red/Cyan, Blue/Yellow, Green/Magenta.
Yukes, yukes… HSL is absolutely not the format that can satisfy any need as is is just as limited to the RGB colour space. Saving grace for HSL is that it is more or less “human readable”. Luckily for that article, lower done in the article he mentions LCH / Lab colours. That should be your base space.
See for example, for the ease fo reading, more web related (but the theory behind apply to any app): see Lea Verou: LCH colors in CSS: what, why, and how?, it has a very good example of what is wrong with HSL.
I can thoroughly recommend Johannes Itten's book "The elements of color" for anyone interested in color theory.
Which is a well studied and understood field. Even among some programmers.
@Philippe
This 1000%. Our perceptual models have advanced dramatically since the naïve model used in HSL/HSB. The only caveat with using LCH is the need to coordinate with images, all of which will be in RGB. While it would be nice if images were in L*a*b, it's never going to happen.
But image standards on the web are still a mess with a mishmash of support for ICCv4, bitdepth, etc.
Kristoffer: Johannes Itten's 1970 book is interesting (I've got it on my shelf) but I haven't found it to be helpful in choosing colors, much less programming my HDR display. There's no algorithms, no color spaces, and hardly even any numbers. Most of the information is black-and-white stick diagrams with names of simple (ROYGBIV) colors written around geometric shapes. There's lots of "try this yourself with paint and see what happens" type exercises.
Charles/Philippe: You seem to be attacking HSL, but missed the last section where he says "HSL has some some serious drawbacks" and continues with a better solution. It's understandable -- most web browsers today don't support them yet, so the inline demo is unavailable. That in itself could be a great reason to avoid LCH for now: of the color spaces that are available in most web browsers, HSL is the best one.
