Both, OkHSL and OkHSV, are bad, they’re limited to sRGB gamut and made up of approximations. I’ve tried to implement both as part of my library but it required pre-computed LUTs, and in general was filled with magic numbers (polynomial coefficients) all over the place that you wouldn’t understand in the very next morning. Also for the picking itself they’re flawed in the 260 and 261 degrees that do odd drifting etc. I wouldn’t recommend them for anything generally.
Perceptual colour spaces in general are horrible for colour picking because of their irregular shapes. (I say “horrible” deliberately. Seriously, try picking a nice bright yellow in your chosen gamut with one, and then try adjusting it at all. You’ll fall out of gamut with almost any adjustment.) The way Okhsv and Okhsl get around that is specifically by forcing it into a regular shape. And you can only do that if you pick a gamut. And sRGB is almost certainly the best choice for normal applications.
The article I linked is particularly good at revealing the trade-offs, especially in its interactive comparison. Yes, at high saturations you end up with sharp gradients from adjusting hue like just above okhsl(264deg 100 24), but there’s really not anything you can do about that in this sort of colour picker. That’s just how colour works. You can’t have a neat shape and perceptual evenness, you have to give up on at least one of them to at least some extent. Overall, I’d say that the Okhsv, Okhsl circle and Okhsl with hue range and saturation/lightness square are about as good as you’ll ever find for general use.
As for magic numbers… well, yeah, what did you expect? Colour stuff is pretty much entirely magic numbers. There’s nothing else it could be.
Tbh this explanation is also completely flying over my head. Realistically, in my apps I just want to pick a few primary colours and then have some algorithm compute the related colours—pressed state, hovered state, dark mode, and so on. And I want the colour scheme to have a good contrast (WCAG). I don’t need to know all the theoretical stuff—maybe a designer does.
the triangle could be replaced by a weirder shape, for this sort of picker
the greyscale side of the "triangle" is always a straight line, but the rest of the shape depends on the hue. it's usually still vaguely triangle shaped, but it'll be a bit bent or rounded, and its tip will be further or closer to the greyscale side, depending on hue
i do like the visualization of the hue wheel getting thinner. i made one once where the hue wheel had gaps in it, but making it thinner lets you know when you're getting close to a chroma+lightness pair that has missing hues
chrismorgan | 10 days ago
Oklab/Oklch are really bad for colour picking. Fortunately, Björn Ottosson went on from inventing Oklab and Oklch in 2020 to inventing Okhsv and Okhsl: two new color spaces for color picking in 2021.
heavyrain266 | 9 days ago
Both, OkHSL and OkHSV, are bad, they’re limited to sRGB gamut and made up of approximations. I’ve tried to implement both as part of my library but it required pre-computed LUTs, and in general was filled with magic numbers (polynomial coefficients) all over the place that you wouldn’t understand in the very next morning. Also for the picking itself they’re flawed in the 260 and 261 degrees that do odd drifting etc. I wouldn’t recommend them for anything generally.
chrismorgan | 9 days ago
Perceptual colour spaces in general are horrible for colour picking because of their irregular shapes. (I say “horrible” deliberately. Seriously, try picking a nice bright yellow in your chosen gamut with one, and then try adjusting it at all. You’ll fall out of gamut with almost any adjustment.) The way Okhsv and Okhsl get around that is specifically by forcing it into a regular shape. And you can only do that if you pick a gamut. And sRGB is almost certainly the best choice for normal applications.
The article I linked is particularly good at revealing the trade-offs, especially in its interactive comparison. Yes, at high saturations you end up with sharp gradients from adjusting hue like just above okhsl(264deg 100 24), but there’s really not anything you can do about that in this sort of colour picker. That’s just how colour works. You can’t have a neat shape and perceptual evenness, you have to give up on at least one of them to at least some extent. Overall, I’d say that the Okhsv, Okhsl circle and Okhsl with hue range and saturation/lightness square are about as good as you’ll ever find for general use.
As for magic numbers… well, yeah, what did you expect? Colour stuff is pretty much entirely magic numbers. There’s nothing else it could be.
bitshift | 9 days ago
What would be a good color space for a picker, then? (Or least-bad if they're all flawed in their own ways?)
yawaramin | 9 days ago
Tbh this explanation is also completely flying over my head. Realistically, in my apps I just want to pick a few primary colours and then have some algorithm compute the related colours—pressed state, hovered state, dark mode, and so on. And I want the colour scheme to have a good contrast (WCAG). I don’t need to know all the theoretical stuff—maybe a designer does.
What’s a good strategy for this?
hc | 10 days ago
the triangle could be replaced by a weirder shape, for this sort of picker
the greyscale side of the "triangle" is always a straight line, but the rest of the shape depends on the hue. it's usually still vaguely triangle shaped, but it'll be a bit bent or rounded, and its tip will be further or closer to the greyscale side, depending on hue
i do like the visualization of the hue wheel getting thinner. i made one once where the hue wheel had gaps in it, but making it thinner lets you know when you're getting close to a chroma+lightness pair that has missing hues