Added support for the CIE 1931 xyY chromaticity-luminance color space.

[glennsweeney]

This adds support for conversion to and from the x-y chromaticity space, while preserving luminance information for the reverse transform (as per CIE 1931 xyY).

I have a few concerns with this pull request:

This is the first Color type that is not in block caps. However, I felt that XYY would produce even more ambiguity. One of the fields within the type is case sensitive (c.y vs c.Y), but I honestly wasn't sure what else could be done.

[m-lohmann]

XYY looks rather like a chromosomal anomaly than like a color space ;) I would prefer the official nomenclature, even if it would be an exception to the block caps rule. It’s certainly less ambiguous as anyone who is used to color metrics immediately recognizes it for what it means. The same would be necessary and sensible for some device color spaces like sRGB, if RGB will get extended.

[StefanKarpinski]

It's a bit odd for capitalization to be so significant in color space naming, but fortunately, Julia doesn't care about capitalization, so you're free to choose what's most intelligible to humans here.

[dcjones]

I agree that it'd be best to eschew the julia convention here and stick with standard names like xyY and sRGB. It's a slightly unfortunate situation, but I think you made the right choice.

[glennsweeney]

@StefanKarpinski - Colorimetry only seems capable of using a pool of 3 letters - x, y, z. We use uppercase, lowercase, with a bar on top, with a tilde on top... The possibilities are endless! ;)

But seriously, this causes enough confusion in the color science world; I think it's best not to add more by changing conventions here. Thanks for the consideration.

This does open up the debate for a few other spaces - LAB would "more" correctly be written as Lab. One other possibility right now is that in XYZ we use c.x, not c.X. It's a little inconsistent with capitalization across the board. But, should we really fix what ain't broke?

[dcjones]

Good point about Lab and Luv. Maybe we can excuse that since those also get referred to as CIELAB and CIELUV, resp, but we're a little internally inconsistent since I did use lowercase in LCHab and LCHuv.

It'd be easy to change the type name and add aliases or deprecations for backwards compatibility, but changing the the type parameter's case to be consistent with notation would be a little painful.

[StefanKarpinski]

My main takeaway from this is that it reinforces my belief that the language shouldn't attribute significance to the case of names.

[glennsweeney]

Sounds like a good takeaway to me.

@dcjones - I don't have too much opinion on handling Lab and Luv. Whatever seems best for you. If you don't have time to make the changes (if any) just let me know and I can go through them.