Frankly this is more of a color roulette than a guide—it doesn't explain any principles of the system. You could do better by knowingly tuning RGB values—or, even easier, HSV.
E.g. ‘abcdef’ turn out to be pastels because they produce light colors with low contrast between the RGB values (i.e. saturation)—since the a-f range is pretty low.
And, of course I can generate the rainbow by shuffling the numbers, but what do I then do with those colors?
> You could do better by knowingly tuning RGB values—or, even easier, HSV.
Yes, I've been doing generative art (e.g., https://i.redd.it/1tuvtfuwsfz11.png, https://i.redd.it/ymg1ix4t8qu01.png), and one of the challenges has been learning to think about colors differently. At the beginning, I would add a bunch of colors randomly to the art. Recently, I've learned some things about what makes colors look good together.
Basically, colors have three "axes": hue (is the color red? blue? yellow? green? purple? etc), saturation (how _much_ of the hue is there? low (but not 0) means pastel; high means neon), and brightness (low is black, high is bright). Play around with the axes here: https://codepen.io/HunorMarton/details/eWvewo (not mine)
If you're going to have different colors that conceptually are on the same level (e.g., four colors for tiles in a grid; three colors for different generated trees), keep two of the axes the same, and vary the other. You can see one example I've done (https://imgur.com/dFGu9Wg) where I vary the hue, but keep the saturation and brightness the same. In another example (https://i.redd.it/ymg1ix4t8qu01.png), I believe there are two colors, but each one keeps the hue the same and I vary the brightness.
> Basically, colors have three "axes": hue (is the color red? blue? yellow? green? purple? etc), saturation (how _much_ of the hue is there? low (but not 0) means pastel; high means neon), and brightness (low is black, high is bright).
Not quite. Or, to be more accurate, the naive HSV is a poor approximation of the perception process.
The visual process is dominated by a luminance scale--the perceived amount of total light. Not all wavelengths contribute equally to it (which is where HSV goes wrong). L is devoid of color information; grayscale images would only have an L channel. Then there is hue, which is essentially a mix of red-versus-green and yellow-versus-blue but is generally described as an angle. There is also a colorfulness property, which is roughly how much the spectrum departs from a flat spectrum.
Except the visual process is more complicated: these values are both considered in absolute and relative terms. A grey that's surrounded by dark greys looks lighter than if it were surrounded by light greys. So you can't look at a color in isolation, you have to consider its context; CIECAM maps colors not to 3 dimensions but to 6 dimensions. This makes accurately mapping a numeric range to colors very difficult.
Finally, there's an added complication when trying to represent colors of physical objects rather than computer screens: there's a difference between specular and diffuse reflections.
Correct! RGB and HSV do not capture how bright colors look to humans, or the contrast that colors appear to have. And the discrepancies are pretty major. This is fixed by LAB space:
I’m not a designer but one thing I’ve noticed is that greys look seem to look better if their tint matches the overal tone the site. For instance a site with many blue colours should use a blue tinted grey. Adding a grey with a green tint for instance would subtly clash.
I think this may have to to do with the imperfect nature of our screens.
If you do the opposite, for example, mix in some red with a mostly blue palette - it looks bad. On some monitors, grey may have a shade of red. And it looks bad.
Yeah whenever I’m putting together the CSS for a side project I’ll spend literally forever going back and forth between greys only to find the look isn’t consistent between my dev machine and my phone.
When I said 'may have' I should have said 'definitely'
Screens definitely differ and colour profiles do differ.
So - there is nary such a thing as 'neutral' - in 2019!
Meaning, a little 'screen red' may make your blue-tone interface look 'off'.
Ergo, tweak your greys a little to match the design.
I'm not a Jobs fan, but only someone like him, i.e. who 'cares' about the experience at that level, and who has the tremendous power to influence / fix this might be able to make a difference.
Bluetooth is an utter mess in the real world, as are colour profiles. There are 'big apps' like Sketch with some awful situations, and the other one's are almost as bad, and there's no way out.
We need a 'user Stalin' to set a simple, clear and unambiguous standard for this that kind of forces and industry outcome. I mean - we're shooting for 'General AI' but we can't even make grey screens ...
Think about it in terms of hue. Warm (red/orange) vs cool (blue/green). Your neutrals (like beige, whites, and greys) should match the temperature of the main colors.
> I think you already know that a color is represented by a 6 digit code (hex code) containing any permutation of the the six alphabets a,b,c,d,e,f and the nine numbers, 1,2,3,4,5,6,7,8,9.
I went to a dataviz seminar for mathematicians and the thing the professor told that stuck with me was "you guys don't understand colors. pick some art work you enjoy and put it through adobe kuler to get a palette".
Yeah... I've never heard VIBGYOR. I did a double-take because this was supposed to be "easy to remember" and that didn't strike me as such, but then I realized it was just ROY-G-BIV backwards. Is this a cultural thing?
EDIT: I find multiple Wikipedia articles[1][2] for Indian organizations/events with the VIBGYOR name, which suggests it's cultural. Some guy's/gal's blog[3] also suggests VIBGYOR is from India.
While I can't speak for the entire nation of India (I moved to the US as a child), I clearly recall being taught VIBGYOR by my father, and then later learned it as ROY-G-BIV in school in the US. So I'd bet it is a cultural thing.
It’s not all about light and dark but really about contrasts in your colors. Excuse the link but the accompanying imagery is required to describe what I’m talking about; picking pretty colors is mostly about understanding and picking contrasts.
Proper color filters would only work on the image on the way to the video card, and not affect what other software sees. E.g. Flux works this way in MacOS, and, I think, Windows.
The difference is probably due to the application of color profiles in one of the programs.
On Moc OSX with my native color picker set to sRGB, for the color labeled #abcdef I get #accfef. Set to AdobeRGB I get #b6cded. With the Chrome Dev Tool's color picker I get #acceef.
I think this is just a result of the wonderful world of color profiles.
Well, that is interesting. For some colors (e.g. ff6666) I get the same value but for some others, it seems to depend on the application. For example, the ffcc66 color appears as ffcd66 in Firefox and Chrome but as ffcc66 in Gwenview and Gimp. And it doesn't seem to make a difference which color picker I use (tried Gimp, Plasma color picker, and the Firefox dev-tools).
It looks like the browsers interpret the images differently.
Something that would help me is an example implementation based on color palette selections. I'm am expert at selecting colors I like :) But I don't necessarily know how to apply color palettes to the elements of a site. What should be primary, secondary, etc?
Here's an interesting article about how a colorblind designer reads color hex codes. He shares how he can look at a hex code and tell you what that color is.
E.g. ‘abcdef’ turn out to be pastels because they produce light colors with low contrast between the RGB values (i.e. saturation)—since the a-f range is pretty low.
And, of course I can generate the rainbow by shuffling the numbers, but what do I then do with those colors?