Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Color Theory for People Who Code

tallys.github.io

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Practical Color Theory for People Who Code

#51

Post by amelius »

boronine wrote: post #49
amelius wrote: post #41

Earlier quoted context omitted.

I'm not convinced. Picking one fresh-looking color, and sliding the "H" slider, I'm running into non-fresh (dull) looking colors. Or is that somehow supposed to happen?

In a sense, yes. The true "freshness" of a color is shown on the color picker as the distance from the center of the circle. This is equivalent to the chroma component of CIELUV, the color space that HSLuv is based on. The problem with that component is that the maximum chroma is different for different hues, so if you were to move the hue slider while keeping true chroma static, you would run into impossible colors…

> You gave an idea that it would be useful to show another slider on the picker called "C", showing the chroma component with gaps.

Yes, that would be nice. But as I understand it, fixing C would cause the H slider to show gaps too (?) Also, if you show sliders for H, S, L and C, then I think it would not be clear from the interface which sliders are fixed.

Re: Practical Color Theory for People Who Code

#52

Post by boronine »

amelius wrote: post #51
boronine wrote: post #49

Earlier quoted context omitted.

In a sense, yes. The true "freshness" of a color is shown on the color picker as the distance from the center of the circle. This is equivalent to the chroma component of CIELUV, the color space that HSLuv is based on. The problem with that component is that the maximum chroma is different for different hues, so if you were to move the hue slider while keeping true chroma static, you would run into impossible colors…

> You gave an idea that it would be useful to show another slider on the picker called "C", showing the chroma component with gaps. Yes, that would be nice. But as I understand it, fixing C would cause the H slider to show gaps too (?) Also, if you show sliders for H, S, L and C, then I think it would not be clear from the interface which sliders are fixed.

Good points. Hmm. Needs more thought :)

Re: Practical Color Theory for People Who Code

#53

Post by zzzcpan »

justinpombrio wrote: post #15

If you want to do something meaningful with colors, don't use RGB, and don't use HSL (which is based on RGB). These spaces are problematic. For instance, pure blue and pure green in RGB space have very different lightness. Here's a picture of the region of colors covered by RGB: https://en.wikipedia.org/wiki/HSL_and_HSV#/media/File:Srgb-i... If RGB space corresponded to what our eyes saw, that would be a perfect hexa…

The article is about subjective design choices. Any color space is fine for that as it's only used to pick colors.

Generally, though, what to use working with colors greatly depends on what you are doing and I'm pretty sure most of the time where you think you need CIELAB, HSL with luma for Lightness would do just fine, heck, even jpeg's native YCbCr or RGB might do. It's just not a good advice to avoid RGB or HSL simply because it doesn't work well on rather rare occasions.

Re: Practical Color Theory for People Who Code

#54

Post by andreareina »

justinpombrio wrote: post #15

If you want to do something meaningful with colors, don't use RGB, and don't use HSL (which is based on RGB). These spaces are problematic. For instance, pure blue and pure green in RGB space have very different lightness. Here's a picture of the region of colors covered by RGB: https://en.wikipedia.org/wiki/HSL_and_HSV#/media/File:Srgb-i... If RGB space corresponded to what our eyes saw, that would be a perfect hexa…

The issue with CIELAB is that a* and b* are poor fits for most peoples' mental models of color. HCL still gives perceptual uniformity while also giving the knobs most people are interested in turning.

Re: Practical Color Theory for People Who Code

#55

Post by jcranmer »

bluetwo wrote: post #19
justinpombrio wrote: post #15

If you want to do something meaningful with colors, don't use RGB, and don't use HSL (which is based on RGB). These spaces are problematic. For instance, pure blue and pure green in RGB space have very different lightness. Here's a picture of the region of colors covered by RGB: https://en.wikipedia.org/wiki/HSL_and_HSV#/media/File:Srgb-i... If RGB space corresponded to what our eyes saw, that would be a perfect hexa…

RGB and HSL are related, but I wouldn't say HSL is based on RGB. From a design point-of-view RGB actually has some problems, as it is difficult to manipulate in a reliable manner. However, from a data point-of-view if is useful because it can scale up or down depending on how much room you have to store information. Also, it relates to the way TV and many video standards transmit information. In HSL, you have saturat…

> RGB and HSL are related, but I wouldn't say HSL is based on RGB.

HSL is explicitly defined as a transformation from RGB space, so each RGB triangle has a corresponding HSL space.

RGB is absolute garbage for doing anything other than displaying pixels. It's so bad, that the (piecewise) linear transformation to HSL is perceived by many to be good, when it's still equally terrible.

The main problem is that not all wavelengths of light contribute equally to perceived brightness in our color vision. Any color space that puts red, green, and blue on equal footing for a transformation is going to produce bad results. If you really want a linear transformation from RGB, you'll want to use something like luma instead (Y = .21R + .72G + .07B, according to Wikipedia)--you'll go from bad to acceptable, as luma is only a few percent off from the accurate results.

If you want to do color interpolation, you'll absolutely want to use CIELAB, which was explicitly designed for this purpose. Any good toolkit should provide CIELAB--d3 does, for example. If not, it's not hard to find snippets to do the conversion for you on places like stack overflow.

Re: Practical Color Theory for People Who Code

#56

Post by andreareina »

jacobolus wrote: post #9
scribu wrote: post #8

Earlier quoted context omitted.

Someone making a color scheme for a chart needs to be very rigorous indeed, because color is actually how the data is represented, in some cases. The tutorial seems to be aimed at front-end developers that want to put together a color scheme for a website. In this case, color is more like decoration, so it doesn't need to be as rigorous, IMHO.

My basic claim is that contrast in perceived lightness (a.k.a. value, in Munsell’s terminology) is the most salient color attribute in graphic design. This is based on the architecture of human vision. When light comes into the retina, it is measured by three different types of detectors called cone cells (“long” L, “medium” M, and “short” S). But the independent signals from these cone cells are not directly passed…

HCL keeps the perceptual uniformity and I think is friendlier than L\a\b\*.

    Almost any color scheme you choose which has enough 
    lightness contrast will tend to look okay, especially if 
    you avoid picking colors which are outrageously colorful.
Solarized[1] is a color scheme that did that and I think it's great.

[1] http://ethanschoonover.com/solarized

Re: Practical Color Theory for People Who Code

#57

Post by acjohnson55 »

b3rry wrote: post #25

This is pretty flawed. First off, never, ever use complementary colors as the foundation for your design. A red green color scheme (for example) will produce a result that "vibrates." Open your image editor of choice and look at green text (#00FF00) on a red background (#FF0000). Illegible. Painful to the eye. Don't do it. Read more here: https://webdesign.tutsplus.com/articles/why-you-should-avoid... Secondly, rotat…

> First off, never, ever use complementary colors as the foundation for your design. A red green color scheme (for example) will produce a result that "vibrates."

Depending on color model and individual visual anatomy, red and green aren't necessarily complementary [1].

[1] https://en.wikipedia.org/wiki/Complementary_colors

Re: Practical Color Theory for People Who Code

#58

Post by acjohnson55 »

jacobolus wrote: post #2

Ugh. This is well meaning, but because based on a color model with a very tenuous relation to human color perception, with further decisions built on loose heuristics without rigorous support (and apparently ported from paint mixing advice), the choices made are pretty arbitrary, yielding poor results. This part in particular ... > Pick any color by selecting its hue (0-360) on the color wheel at full saturation (100…

I agree with you. I used to think of working with color mathematically, until I started researching how color perception actually works. I was working in an imaging science lab at the time. That made me realize how difficult it is to come up with any sort of mathematical approach to creating a color scheme.

It's much better to find color schemes that are recommended by experienced designers. And if you're working on a diagram, trying to design it to be effective with some large number of colors is probably futile, if color is going to be the sole visual discriminant. It's better to keep your number of elements small, if you can. And if you can't, pick a small number of colors, and combine them with textures to get a larger number of combinations.

Re: Practical Color Theory for People Who Code

#59

Post by cmurf »

Razengan wrote: post #13
cmurf wrote: post #11

Earlier quoted context omitted.

The problem is there's divergence from sRGB, and as yet no convergence on a new single standard. So all image content is rendered to sRGB still. Further, there's substantial inconsistency in various tools when it comes to compensation for the difference in color encoding between the image file, and the display. The technology to do this compensation is old, but it's weakly implemented on mobile outside of web browser…

Apple have made good progress on this. All of their devices (iPhones, iPads and Macs, with the last iMac having a 10-bits-per-channel screen) are now capable of accurately displaying DCI-P3, and their software supports it very well [1][2]. Other companies are also expanding outside sRGB, with Samsung's new phones, the Surface Studio from Microsoft, and Razer's Blade [Pro] also supporting wide color gamuts, although t…

This makes the problem worse. There's 20 years of legacy sRGB images that will not display correctly on wide gamut displays without display compensation in software. iOS and Android are basically repeating all the mistakes made in color management on the desktop, by allowing opt outs by apps and not taking a holistic color management approach. And where the content is created, on the desktop, again if you're using any sort of specialized tool there is a high likelihood the color space information is being ignored or is even stripped out of the image - making it impossible to render correctly downstream.

Changing image encoding from sRGB is change for the sake of change - the vast majority of real world image content fits in sRGB.

Post reply on HN