Someone emailed me recently about a tool he was building using an HUSL-based color picker. Here was part of my response:
As for the color space, I can understand the idea, but personally I think both HuSL and HuSLp are quite far from human friendly in practice, either for manual color selections or programming heuruistic color choices. In the case of HuSL, the numerical values for “saturation” are useless for comparisons across lightnesses or hues, and in the case of HuSLp, the very limited gamut of RGB displays in certain hues ends up leaving the majority of display colors outside of the HuSLp gamut, while still leaving the saturation numbers somewhat useless for comparisons across lightnesses.
I think end users would be better served by just using a cylindrical representation of CIELUV directly (or actually CIELAB, IPT, or CIECAM02 would be better still for most UI purposes I think, even in the context of computer displays, or perhaps NCS for certain use cases). HuSL is better than HSL/HSV, but that’s a very low bar.
It was, indeed, originally based on HuSL, but I later realized I could get a more meaningful picker by just constraining the chroma component not to go beyond the maximum in-gamut chroma for the given lightness and hue.
Not sure if I actually understand what is it about. I'd like to see HUSL colorpicker beside the rival ones (including HSV) to understand if it's really more useful. Random generated colors are nice indeed, but I'm always having a struggle with defining what I want from random, so I want to neglect this use-case.
I mean, I never can trust any studies that say "70% of respondents told us that these colors have brightness of 60%, although, technically speaking, this color is brighter that that, so it's a property of human eye to perceive these shades brighter than these" for several reasons. I can trust a physical definition of brightness, or as simple definition of color as RGB. There's real meaning to that. But what one actually means, when he says "this color is 60% bright"? It is totally a matter of his learning experience, that made his definition of "bright" to be what it is. If one spends enough time working with RGB, he can guess hex-codes closely enough, for him it would be intuitive, as his mental model of color was developed with RGB as a guide. But I doubt any newcomer can say RGB is "intuitive". Intuitive understanding of any tool comes with real experience of using it. So it's not about how intuitive tool looks, but how effective it is after you learn how to use it.
So, yeah, at a first glance HUSL looks "intuitive", but I cannot say if it's a good thing or a bad one, without actually trying to pick colors using that scheme.
This talk introduced me personally to various ‘alternate’ color palettes and why they might be useful (though the talk is more specific to data visualization domain): https://www.youtube.com/watch?v=DjJr8D4Bxjw, Subtleties of Color by Robert Simmon at OpenVis 2014.
Does anyone know why HUSL is based on CIELUV rather than CIELAB?
It seems that, although CIELUV and CIELAB were considered equally good when adopted in 1976, CIELAB has generally been preferred more recently (e.g. for the 1994 and 2000 "Delta E" formulae [1]).
The CIE 1976 (u', v') UCS chromaticity diagram is a somewhat better chromaticity diagram than the standard 1931 (x, y) version for e.g. showing chromaticity of the primaries on a computer display: it reduces some of the dramatic perceptual distortions of xy. CIELUV is supposed to be a full 3D color space made out of a combination of a (very bad) chromatic adaptation method, the same lightness L* from CIELAB, and color coordinates L* u* v* which are simply derived from L*, u', and v'.
In theory, CIELUV is a bit more directly relevant to colored lights or images on a television / computer display, whereas CIELAB is defined for surface colors. In practice, CIELUV just isn’t a very good uniform model of human color vision, and CIELAB is somewhat better (even for display colors) while still being quite easy to compute.
The reason color difference measures are defined with reference to CIELAB coordinates is that they are typically used for specifying tolerances on surface colors in industry. For instance, you might specify that a particular textile or paint color must be within a particular perceptual distance of a target color. CIELUV wouldn’t make any sense for such a use case.
Personally, I’d recommend people move on to use IPT or CIECAM02 or something similar instead.
This is just a first impression, so maybe after further reflection it won't be an issue, but: all of the examples of HUSL colors are drab and less interesting than their HSL counterparts. It seems like the benefits of using HUSL (which are still unclear to me) are not worth the cost of being unable to describe vibrant colors. Please tell me why I'm wrong.
I think the benefits of HUSL are kind of explained backwards, with technical details first and practical applications later. But once I saw their comparison of contrast (60% brightness random colors HUSL vs HSL) and the demo, it's pretty clear that HSL is way more difficult to depend on for random colors due to wildly varying contrasts.
I see. I guess I didn't really see much of a use case for random colors with constant variation of contrast. The demo does a pretty good job of demonstrating a compelling use case though.
The examples on the page are all at the same lightness, so you only see a slice of possible colors. The main point it's trying to show is that HSL's notion of lightness is rather useless. When it's trying to generate some background colors (with a fixed lightness of 60%), note that some of the HSL colors are much brighter than others, to the point that the white text becomes hard to read. By contrast, all of the HUSL colors at 60% are suitable for use as a background under white text. You can press the test buttons again to see more examples.
Those vibrant colors are not gone from the HUSL palette, they are there at the top. But they are not the only colors. There is more variation. The HSL palette is "over saturated" with saturated colors.
The interactive color picker is neat, but the irregularity of the space is hard to visualize in 2D. I'd love to see a 3D point cloud version of the color space.
The contrast is a little low for me, but I can still read it fine. I think a lot of the problem might be the amount of ambient light in the reader's room. My room is somewhat dimly lit.
I'd love to know this too: almost every article on HN has someone commenting about the contrast on some text. To me the difference between the black and grey is fine, and I wouldn't have even thought about it if you hadn't said anything.
I initially figured it was because of the MacBook Pro retina monitor is good, but I hear the same complaints from other people on the same (or similar) set ups.
Is it a world of difference between monitor calibrations, or human eyes, or both?!
The macbook pros tend to use more correctly calibrated colour than typical desktops with monitors, and typical non-apple laptops; This means that decisions made on non-reference monitors that have never been calibrated.. well, they can look completely wrong on a monitor with the correct calibration.
Get a Lenovo huey or a Colorhug, correct your monitor, and you'll see what I mean.
On the web, you don't really know what you'll run into. You should aim for a level of contrast so sharp that it borders on uncomfortable, so that when the contrast between your colour selections is less than you thought, it'll still at least be legible.
I work in an office full of Mac users, and I'm among maybe three people who don't use Macs for work at the company.
All of the non-Apple monitors in the company are not correctly calibrated and lack colour profiles (and are by default not configured correctly either).
I recently bought a colorimeter, and calibrated all of my displays(including my external displays); after doing this I realized that the colour on my monitors most closely resembled the default colour response on the MacBook Pros in the office.
My colleagues(who admittedly didn't understand colour calibration at all, even the designers) are under the impression that Apple profiles and calibrates the panels at the factory(and presumably ships custom profiles for the factory state of the panel).
I think it's probably cruder than that. It's likely that they ship one profile for an entire family of panels, which gets it closer but doesn't account for time and manufacturing variances.
Lots of things can influence text legibility. Different display characteristics, environmental factors, the font that ends up being rendered, view distance etc.
HUSL brings the perceptual uniformity of CIELab with the intuitiveness of HSL. Author has done something awesome with a solid theoretical foundation. I have used HUSL to generate pleasant color palettes in http://bezier.method.ac
I'm an artist and musician and generally horrified by the amateurish algorithmic noodling in both spaces.
When you pick a color you're picking it relative to one already on screen -- or something in your mind's eye. This color picker does not help solve either problem.
If you look at the paint chips in the store -- or the Pantone books -- you'll see they're organized a certain way. Often you pick the color and then you tweak the saturation and brightness. I do it all day every day. Even the dorkky CSS pre-processors have features for tweaking saturation and lightness. It's what artists do.
This tool makes a mess of saturation in particular.
Meanwhile nobody's demanding to do Delta-E crossfades on #ffffcc vs #ffccff in SASS. Hmm. I wonder why.
Color picking is often handled by swatches and fanning out real-world books of similar tones. Fiddling with a computer is great, and if you think it's important that your screensaver randomly pick cool colors -- hey, if this helps you, go for it.
You're likely far better off limiting the color cube a different way. Perhaps by popularity, or culture, or by simply typing in a couple dozen colors that don't look like shit and calling it done.
As for the color space, I can understand the idea, but personally I think both HuSL and HuSLp are quite far from human friendly in practice, either for manual color selections or programming heuruistic color choices. In the case of HuSL, the numerical values for “saturation” are useless for comparisons across lightnesses or hues, and in the case of HuSLp, the very limited gamut of RGB displays in certain hues ends up leaving the majority of display colors outside of the HuSLp gamut, while still leaving the saturation numbers somewhat useless for comparisons across lightnesses.
I think end users would be better served by just using a cylindrical representation of CIELUV directly (or actually CIELAB, IPT, or CIECAM02 would be better still for most UI purposes I think, even in the context of computer displays, or perhaps NCS for certain use cases). HuSL is better than HSL/HSV, but that’s a very low bar.