-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[hue] OH binding should use same color Gamut as Hue App #16482
Comments
@jlaur any thoughts? |
Just a further feedback: It seems that the Hue App is smarter than I originally thought. When you use the app to set a color that is outside the gamut of the lamp, it initially shows the color that you selected. However after about 30 seconds, it 'pops' to show the actual color which the lamp has been able to achieve. See video below .. watch it until the end! Screen_Recording_20240307_174720_Hue.mp4 |
@andrewfg - I don't have detailed knowledge about color gamut etc. But from the explanation you have given, my immediate feedback would be that we should probably accept Gamut C input and send that to the bridge. Can you try that, and see how that will work now that we have #15984 in place? I would expect the channel state to be "auto-corrected" to be within the allowed gamut. |
@jlaur thanks for the feedback. This issue is not directly connected to core #4124 and addons #16436 .. but it is somehow all part of the bigger picture. I am going to do some Wiresharking on the Hue App to see what it is sending to bridge, and if it sends Gamut C to the bridge, then I would suggest we do the same. (But otherwise not..) Current behavior is as follows..
C914E27B-D0AE-45D4-94CE-1DCE4FC81E22.MP4 |
Just to be sure, doesn't this mean that when trying to select a color within the Gamut C colorspace for a lamp supporting Gamut C, this will be "corrected" to Gamut B? |
Each lamp declares its own gamut triangle; it doesn’t actually say A or B or C, but rather it gives the actual XY coordinates of its particular gamut triangle in the color space. Currently the binding receives user color commands (from HSBType) and first converts those to ‘raw’ XY, and then secondly adjusts the ‘raw’ XY to a ‘clean’ XY that lies within the particular lamp’s self declared gamut triangle. The hypothesis is that if we would NOT apply the second cleaning adjustment, then the Hue bridge (or the lamp itself) would do the cleaning adjustment for itself; and report the subsequent ‘clean’ XY back to the OH binding via the state change event message; whereupon the returned clean XY is converted back to HSB for the OH UI. I think it would certainly be neater if the Hue bridge or lamp would do its own cleaning (avoiding double cleaning, and possible conflicts). But we just need to check in real life if the Hue bridge or lamp will not be upset if it is given a non clean XY coordinate.. |
@jlaur I tested a version of the binding that does not apply any gamut cleaning, and just sends the raw XY values directly. The response is not what I expected before making the test, but having done the test, I am not at all surprised by the result!
I am not sure if this an improvement or not -- in the binding release version the OH UI immediately updates to the gamut corrected XY, whereas in the test version the OH UI updates after 4 seconds. => WDYT?
EDIT: the code tested is here |
The advantage of leaving this calculation/feedback entirely to the bridge/lamp is that the logic on OH side would be simpler (there wouldn't be any) and we will be less prone to errors if a lamp would report wrong gamut, or none at all. We would remove all assumptions. For example, if a lamp reports gamut B, but actually supports gamut C, we would not be able to utilize the full color space. So I think the device support would be better by sending the raw XY - like I understand the Hue app also does. On the other hand, the advantage of applying our own correction before sending the command is almost immediate feedback on final target value, as opposed to having to wait a few seconds for that. IMHO the advantage of better device compatibility and eliminated risk of miscalculations on our side outweights the benefit of this slightly faster update. |
@jlaur I agree with you. However just one minor clarification comment..
According to the Philips specifications, in order to NOT do gamut correction (in the case where the lamp specifies none) then one must actually apply the so called 'Default Gamut' correction (see below). In other words, according to Philips, even if 'no' gamut correction shall be applied, we must still apply the default correction. I think the purpose of this is to ensure that XY values cannot exceed 1.0 (??) But if one overlays the 'Default Gamut' on the CIE chart, one can see that it does actually still clip the far right (red) corner of the chart. So in order to really really eliminate gamut clipping within OH (i.e. to actually not correct any raw XYs) we need in fact to apply a 'Revised Default Gamut' as shown below. (I know this sounds convoluted, but please bear with me..) => So today I shall make another change to achieve the above, and test it ASAP.
|
^
|
To be honest, I am not sure if this is a bug or a feature. And/or if it requires any action in the binding. Therefore I am simply recording this issue as a place holder for the time being..
The issue is as follows..
Note: this is particularly noticeable when the App sends a deep green color.
The text was updated successfully, but these errors were encountered: