Should the default distance method for cylindrical color spaces use polar coordinates? #493
Replies: 3 comments · 20 replies
-
|
I'm not sure I understand the concern. The default ∆E is 76, and it uses Lab, not a cylindrical space, to perform the distance calculation. https://github.com/color-js/color.js/blob/main/src/deltaE/deltaE76.js#L6. > new Color('red').deltaE(new Color('blue'))
184.01904862099684
> new Color('red').to('hsluv').deltaE(new Color('blue').to('hsluv'))
184.0190486209965 |
Beta Was this translation helpful? Give feedback.
-
|
Do you have a particular use case where you feel it is more helpful to use euclidean distance in an unsupported cylindrical space instead of just using a more appropriate cartesian coordinate system? Or are you mainly suggesting that if people do so, we should try to provide more sane defaults? Normally, if I want distance in HSL, I would use sRGB which represents its gamut, I wouldn't use HSL directly. I could see value in maybe throwing a warning or error if a cylindrical space is used. I guess the alternative would be to convert to a cartesian system to try and return more sane results. In order to do so, we'd need a way to determine in every color space where hue and some colorfulness/saturation/chroma component lies. Not all LCh spaces place hue at the end (HCT as an example), etc. Is it worth all the effort to provide such behaviour, or is it better to just guide users to not try and do distance in cylindrical spaces? |
Beta Was this translation helpful? Give feedback.
-
|
There's a few cases where I like working in a cylindrical space — specifically, hsluv, though I've also been using okhsl a bit lately too. Those spaces hit a sweet spot between computational simplicity and approximate perceptual uniformity; I can go into more detail if you'd like. In hsluv, euclidian distance agrees pretty closely to deltaE2000, so you can use it as a heuristic instead of converting to another color space (ie converting to lab to do deltaE2000). Today, if I'm working in a cylindrical space and want to avoid doing conversions, the As for implementation: each color space declares the type for each of its coords; could we check that to determine if we're in a cylindrical space, and if so, which coordinate is angular? |
Beta Was this translation helpful? Give feedback.
-
|
@ilikescience, I understand that working in hsluv, and okhsl can be great, I am not trying to discourage that, but why not use the appropriate space for distancing, Luv and Oklab respectively? > let c1 = new Color('hsluv', [0, 0, 0])
undefined
> let c2 = new Color('hsluv', [360, 0, 0])
undefined
> c1.distance(c2, 'luv')
0
> let c3 = new Color('okhsl', [0, 0, 0])
undefined
> let c4 = new Color('okhsl', [360, 0, 0])
undefined
> c3.distance(c4, 'oklab')
0Hopefully, this makes things a bit more clear at what I'm driving at. Is it more helpful to you to get distancing within the actual HSL cylindrical space? Or do you actually want the Luv or Oklab distancing which actually gives you the results closer to ∆E2000? Distancing in the distorted HSL space will not give you what you want I imagine. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it's correct to say that oklab is more appropriate for making distance measurements than okhsl; they're useful in their own rights. In my case, okhsl has some really useful properties. For example, I can calculate a "maximally different color," because there's an easily derived "furthest point" in okhsl space, which is guaranteed to be in the srgb gamut. Before okhsl and hsluv were added to colorjs.io, I was supplying my own method for doing these kinds of distance calculations in those spaces. That's ok, and I'm sure folks have opinions on whether or not colorjs.io should support this use case. For now, maybe it's sufficient to focus on the fact that if the |
Beta Was this translation helpful? Give feedback.
-
So we aren't talking about perceptual distance, that is what I was getting at, and it is fine if that is not what you are looking for. You specifically want distancing in okhsl and hsluv. That clears that up, and that is okay. How would you propose HWB would get handled? I think spaces like this may still be an exception, but that is probably okay. As it seems you truly do want distancing in these cylindrical spaces, I will defer to others for an actual decision on the matter. I think the problem could be solved if a decision is made to do so, but there may or may not need to be a little framework put in place to generically identify saturation/chroma/colorfulness and hue in spaces. Hue is easy enough as I believe they identify as angles. Maybe you can safely assume the center component is always saturation/chroma/colorfulness. I'm not aware of a specific space that doesn't follow this convention, but I can confidently say that currently supported spaces follow this convention. So maybe no additional infrastructure is needed? |
Beta Was this translation helpful? Give feedback.
-
Yup, I'm just talking about the geometric distance in the color space. To be pedantic, this is a kind of perceptual distance, in the same way that geometric distance in jzazbz or lab is meant to be perceptually meaningful.
Since it's cylindrical, it should be handled the same way; distance should be calculated using cylindrical coordinates.
It looks like there's already a method on ColorSpaces that identifies spaces as being polar or not! eg, > Color.space.srgb.isPolar
false
> Color.space.hsluv.isPolar
trueBehind the scenes it's just checking if a given coord has is of type this.coords[id].type === "angle"So, the distance method could just sort coords into angular and cartesian, then do the distance calculation appropriately. The "right" way to do this would be to also allow for spherical color spaces, ie spaces where two out of the three coordinates are angular — while I don't think any color spaces fit this description today, it's not outside the realm of possibility. It'd be extremely right to also allow for arbitrary numbers of coordinates (2, 3, 4, ...n), and I'm sure there's a generalized formula for distance in n-dimensions (where some of them can be angular), but I'm not a mathematician so I think we'll have to punt on that one :) |
Beta Was this translation helpful? Give feedback.
-
Let's not confuse things, it does matter whether you take W or B when calculating cartesian coordinates for HWB. 
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, sorry, you're absolutely right, these things are pretty unintuitive! Ok, given that the choice of radial dimension is meaningful, you would need a way of correctly assigning the coordinate. That does seem more involved, as it requires adding extra information to each color space. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, hence my slight concern about locating chroma. Assuming such things were in place, and it was decided that this project wanted to support polar Euclidean distance, I think it would be fine. HWB handling, which I imagine is the only "special" case that would need consideration, would have to be decided then: pick a convention, or throw an exception. |
Beta Was this translation helpful? Give feedback.
-
|
I was just doing some research into HWB and it looks like in the original proposal, W is akin to Saturation and B is akin to Value. So, W would be the radial dimension. http://alvyray.com/Papers/CG/HWB_JGTv208.pdf
|
Beta Was this translation helpful? Give feedback.
-
|
That was my memory, or at least what I settled on. That's how I plot them: 
|
Beta Was this translation helpful? Give feedback.
-
|
@LeaVerou @svgeesus what do y'all think? Should the |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely!! The question is who will implement it 😅 Any chance you may be up for it? 🙏🏼 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
When when working in cylindrical color spaces like hsl, hsluv, lch, etc (essentially anything with a "hue" component that goes from 0 → 360) the default "euclidian" distance$\sqrt{(x_1 - x_2)^2 + (y_1 - y_2)^2 + (z_1 - z_2)^2}$ doesn't make much sense. For example, the euclidian distance between hsl(0, 50%, 50%) and hsl(360, 50%, 50%) is calculated as $\sqrt{(0 - 360)^2 + (0.5 - 0.5)^2 + (0.5 - 0.5)^2} = 360$ , even though hsl(0, 50%, 50%) and hsl(360, 50%, 50%) are the same color!
Instead, I think we should first convert the polar coordinates to cartesian ones before calculating the euclidean distance:
where r and z are the normal/orthogonal coordinates — in hsl, for example, they would be s and l — and θ is the radial coordinate, in radians — in hsl, this would be$h*\frac{\pi}{180}$ .
This would mean that the euclidian distance between hsl(0, 50%, 50%) and hsl(360, 50%, 50%) would be correctly calculated as 0.
I think the key concern here is that for each cylindrical space, we'd need to indicate which coordinate is the radial one and which are the normal ones. But with that information, euclidian distances would be much more logical.
Beta Was this translation helpful? Give feedback.
All reactions