S_HSV_LIGHT + V_HSV Sensor type

[soif]

I'm proposing to add an S_HSV_LIGHT type for controlling Led Strips.

Why

• HSV is way more intuitive for humans to set a color than RGB. ie you can easily set a Hue (rainbow color), a Saturation (Color strength) and a brightness Level, rather than fighting against RGB values.
• Dimming a RGB color, is at least complicated, if not impossible, while setting a HSV.v level is SO simple.
• Controllers colors palettes are most often build from a HSV palettes, then APPROXIMATELY converted to RGB (ie Domoticz)
• using the amazing arduino FastLed library makes converting HSV datas to RGB leds Strips (whatever the LedStrip technology) really simple, fast, precise and efficient.
• converting on the node from HSV to RGB is precise (using FastLed) while the opposite is always approximate.
• FastLed IS the library to use when you're talking to advanced/modern RGB chipsets, and internally talk HSV before converting to RGB.
• some Hardware manufacturers did undertsood the interest of HSV and already implemented it this way in their products (ie Philips Hue Lights )
• this does not prevent to use the S_RGB_LIGHT format when needed

How

• Define an S_HSV_LIGHT type
• The S_HSV_LIGHT type could use the exact same payload format as the V_RGB format (3 byte of datas, encoded as a hexadecimal string): ie instead or RGB(0-255,0-255,0-255) , we would have HSV(0-255,0-255,0-255). This means that instead of having V_RGB + V_HSV , they could be merged into a shared "V_3HEX" format.

FYI : I already have developed an (almost finished) sketch/proof-of-concept that controls a RGB led strip from HSV messages , and/or RGB messages, using the FastLed library. Obviously, the HSV messages are more intuitives and precises than the RGB messages.

[hek]

Are the losses you talk about when converting HSV->RGB visible for a (normal) human being when you actually use them on a led strip? I mean would i matter much for the end result as the diods aren't calibrated agains transistors used etc.

Not saying it's a bad idea, just if it's worth the troubles of having to support two message types in RGB actuators?

[soif]

I'm not worried about any losses while converting HSV->RGB : in this direction, it work pretty well (whenever the software is well written). This is in the opposite direction that conversion is happening bad. (FastLed note about this)

I mean from the node, if I would like to work internally in HSV (in order to be able to support SMOOTH and easy dimmimg of any colors). Geting data from the controller in RGB, then converting in HSV is both approximative and adds some uneeded processing.

Being able to easely DIM any color (ie just changing HSV.v), is one of the main argument to use HSV against raw RGB. In HSV mode you can aslo easily fade between colors (just changing the hue). This is both easy, and really intuitive.

IMHOThese 2 features are importants to well suport RGB strips.
Doing this in HSV, is just a few lines of code (ie using FastLed) while doing this in RGB is a nightmare and absolutely not intuitive.

Anyway my test node works in both modes, but receiving HSV datas, would be a must and thus allow the controller so expose an HSV parameters in the API/script/GUI.

Just imagine creating a LUA script ie, in Domoticz (or any controller) to dim an RGB strip in raw RGB mode, vs doing this in HSV.... One is very complicated while the other is really easy. and dimming a RGB strip should be as simple as dimming a single color bulb, isnt it?

[mfalkvidd]

I have created a HSL selector sketch, using a 3.2" touch screen. I find HSL intuitive when selecting colors, especially since the palette can be drawn in 2D. Haven't gotten around to posting it here yet though.

In that sketch, I convert to/from rgb. The conversion is quite simple, but if the value is converted back and forth a lot of times it can drift away a bit. I don't see any cases where multiple rounds of conversion is required though, so I'm not sure a new color model would help. But if a new color model was added, I would prefer HSL over HSV.

[soif]

The problem is not really concerning RGB to HSV or vice-versa (BTW if you have a working-well RGB to HSV code, i'm interested. I'm currently using the FastLED one ...)

The idea (and this is the main reason why HSV ever existed) is to get a easy and natural way to describe colors.
For anyone in the world it is easyer to say "I want a red, pale, not so bright" light, instead of a" #FFAA11" light!

When you are from a controller point of view, talking directly in HSV, allows to easily set a dim level (which is a major feature for a light, isn't it?), and a color (Hue). Devs like the Domoticz ones even dropped the Saturation at this time, but they are currently receiving (and could easily send) H(S)V values.
Also most (if not all) javascript color pickers are natively talking HSV.

About HSL vs HSV I think this not really important because it is just a story of different gamma correction / color space (if i understand well), and for devices intended as a Light (not as screen), color deviation is not a big issue. I just vote for the most used in related software (arduino lib + Javascripts color pickers), to try to match the requested color as accuratly as possible.