d3-color
d3-color copied to clipboard
d3
LUV and XYZ.
Per https://github.com/d3/d3-color/issues/33#issuecomment-506914712, d3-color should support CIELUV in addition to CIELAB, and for compatibility with R, should redefine d3.hcl as polar CIELUV, but preserve d3.lch as polar CIELAB. We should also expose CIEXYZ for completeness.
should redefine
d3.hclas polar CIELUV
Please don’t do this; it is horrendously confusing. Use names like d3.cieluv_hcl or d3.cielab_lch if you want. Personally I would strongly recommend using the same input order for both. Just because R has picked a bad convention doesn’t mean it should be widely copied.
The names ‘HCL’ and ‘LCH’ have no standard meaning. (Aside: usually the “h” is written in lower case in color science literature; it’s not exactly clear why. So people often write LCh or similar.)
(It IMO also doesn’t really ever make sense to use CIELUV or XYZ in data visualizations. If you add these, you might want to warn people away from using them.)
Aside: While CIELUV doesn’t really have any practical purpose nowadays, the (u′, v′) chromaticity diagram does continue to be useful, superior to the (x, y) chromaticity diagram.
I’m leaning towards the names d3.lab (CIELAB), d3.luv (CIELUV), d3.xyz (CIEXYZ), d3.lchab (CIELCh_ab), d3.lchuv (CIELCh_uv), and the corresponding d3.interpolate* methods (though I’m not sure I’ll bother with d3.interpolateXyz, as I’m only exposing d3.xyz for people that are interested in the internals of the CIE color spaces).
This would deprecate both d3.lch and d3.hcl in favor of d3.lchab.
How does that sound?
Wouldn't it be easier for everyone if d3.lch would just continue to exist as d3.lchab alias?
I’m only planning on deprecating, not removing. We could keep d3.lch (non-deprecated) as CIELCh_ab, but the point is that it would be ambiguous and inconsistent if we also have CIELCh_uv as d3.lchuv. Though if CIELCh_ab is the “recommended” CIELCh, then it might make sense to leave it as d3.lch…
That sounds clearer. If you use lch as an alias for CIELAB LCh that is also generally not too bad, as CIELAB is very widely used. I was mostly worried about is confusion of lch vs. hcl meaning totally different things.
Okay. I think I’ll just keep everything existing as-is, improve the documentation, and introduce:
- d3.luv = CIELUV
- d3.lchuv = CIELCh_uv
- d3.xyz = CIEXYZ
@mbostock
Okay. I think I’ll just keep everything existing as-is, improve the documentation, and introduce:
- d3.luv = CIELUV
- d3.lchuv = CIELCh_uv
- d3.xyz = CIEXYZ
Please also include the d3.lchab (CIELCh_ab) alias that you mentioned in your earlier proposition.
This will provide explicitness & result in more easily understandable code for those who use both lchab and lchuv spaces, without requiring knowledge of the historical implementations/defaults of the library.
Per #84 and #51, sounds like we’d want two or possibly three for XYZ due to the choice of illuminants.
So, I think this is the latest list?
- d3.luv = CIELUV
- d3.lchab = CIELCh_ab
- d3.lchuv = CIELCh_uv
- d3.xyzd65 = XYZ D65
- d3.xyzd50 = XYZ D50
- d3.lch = alias for d3.lchab
- d3.hcl = alias for d3.lchab with arguments in reverse order
- d3.xyz = alias for d3.xyzd65?
Sorry, only just noticed this. @jrus wrote:
(Aside: usually the “h” is written in lower case in color science literature; it’s not exactly clear why. So people often write LCh or similar.)
This is because h is an angular measure, and in color difference formulae which start from LChab (starting with ΔE CMC, then ΔE 94 and ΔE2000) h is turned into a length measure H by calculating the length of the angular arc, which involved the (mean) Chroma and the hue angle. It then makes sense to add it's square to the squares of the Chroma and Lightness lengths.
So h vs. H solves the "which H are we talking about here" and is mainly interesting to people discussing the implementation details of color differences; for everyone else (especially people already using H in HSL to mean an angular measure) LCH seemed just fine, which is why CSS Color 4 used that.
