Color bug (Homie 5): xyz does not include brightness

[Tieske]

In the Homie 5 draft, there is "rgb", "hsv", and "xyz" for the color type.

• in "rgb" the brightness setting is included in the information; rgb(50,50,50) is the same color as rgb(100,100,100), but at half the brightness
• in "hsv" the brightness is independent in the "v" component, where "hs" determines the color
• in "xyz" (specifically if we define z = 1 - x - y) only the color is encoded, no brightness.

Problem: 2 of them encode brightness, the third doesn't. So they are not equivalent!.

In the "xyz" system (CIE 1931) there are actually 2 representations; "XYZ" and "xyz", which are different:

• "XYZ" (Tristimulus Values) encodes the color and the brightness. The values of X, Y, and Z do NOT add up to 1.
• "xyz" (Chromaticity Coordinates) encode only the color, and no brightness. In this case the values of x, y, and z do add up to 1.

The only solution I see to this is to either remove "xyz" as an option, or change the definition of "xyz" (currently Chromaticity Coordinates) to Tristimulus Values, meaning, the last value (z) must also be passed along, and they do not have to add up to 1.

@schaze this originated from you I think. And iirc mostly because some devices (Philips Hue and friends) seem to prefer the "xyz" system. So wdyt?

[schaze]

I would argue that hsv and rgb have the bug since this property is supposed to describe the color not the brightness. A light usually has a separate brightness value to adjust its brightness. Having said that, I don't really care about it. For me it was good enough the way it was. But feel free to change it if you like.

[Tieske]

I have been thinking about this as well. Maybe we can document this particular difference between the formats, and users should use rgb & hsv, if brightness is to be encoded in the values, or rgb, hsv, xyz if brightness is not to be encoded.