Refactor XYZ color space into its own module.

[DCtheTall]

For #51

Refactors the implementation of the XYZ color space (i.e. CIE XYZ D50) out of src/lab.js into its own module, src/xyz.js.

[mbostock]

This looks like a worthwhile refactoring and I’m in favor of exporting d3.xyz. 👍

[DCtheTall]

@mbostock the PR is ready for review

[mbostock]

Per @danburzo’s comment #51 (comment), what do you think about the choice of illuminant (D65 vs. D50)? One possibility is that the XYZ class has a field which stores the illuminant ("d65" or "d50"), and we export constructors for both (d3.xyzd65 and d3.xyzd50).

Also, does this PR affect the performance of converting between Lab and RGB because it now makes explicit the extra chromatic adaptation step rather than combining it into the matrix multiplication?

[DCtheTall]

what do you think about the choice of illuminant (D65 vs. D50)?

See my comment on #51

Also, does this PR affect the performance of converting between Lab and RGB because it now makes explicit the extra chromatic adaptation step rather than combining it into the matrix multiplication?

Is there a benchmark you use for this? How have you tested performance impact in the past?

[DCtheTall]

@mbostock friendly ping

[danburzo]

In a recent addition to the css-color-4 spec, @svgeesus has made the following adjustments as per w3c/csswg-drafts#6722:

• xyz refers to XYZ with the D65 white-point;
• xyz-d50 refers the D50-relative XYZ;
• xyz-d65 is an alias for xyz.

These are all predefined color profiles for the color() syntax and are expected to show up as identifiers in the upcoming Color API.

xyzd50 and xyzd65 sound reasonable as method identifiers on the d3 object. (In Culori, I opted a while back for xyz65 and xyz50 and will maintain it for backwards compatibility, although now I prefer the inclusion of the full illuminant name)