XYZ representation

[rennis250]

My previous comment was removed after reading a bit on the sRGB space.

We should add some documentation on the meaning of the scaled XYZ values and their relation to the sRGB representation that this package uses. The normalization of each component to D65 isn't standard in any of the color labs that I have worked in, for instance, causing some initial confusion for me.

I might have a chance to do it a bit later today.

Best,
Rob

[rennis250]

Also, I would argue that the color type's fields should be labeled as X, Y, and Z, not x, y, and z.

[timholy]

It is a little confusing that we call this RGB but it's really sRGB. Not quite sure what to do about that.

[rennis250]

Yes, if we tried to generalize on the RGB concept, then it would be appropriate to also include at least some of the other variants: https://en.wikipedia.org/wiki/RGB_color_space#Specifications

Perhaps we could make an RGB type that by default is the sRGB space (possibly the more common variant that one expects) and which could be optionally parameterized to implement the other variants? That could become a bit messy with respect to code, though... I'll need some sleep before I can think about it better.

I can start a separate issue to centralize the RGB discussion.

[kimikage]

xref: JuliaGraphics/Colors.jl#453 (comment)

[kimikage]

I do not fully understand the arguments of this issue, but I will update the README.md with ColorTypes v0.12 and then close this issue.
In other words, for now, I don't plan to change the XYZ's fields from x, y, and z. Also, metadata such as color gamut will be handled in higher level packages than ColorTypes.