Closed jounathaen closed 5 years ago
cc @thezoq2
This was discussed briefly in #6. The reason its wrong is that the current code emulates what FastLED does, which wraps around for values over 192.
I believe this is because the hue value has to be separated into 3 different branches consisting of 120 degrees each. However, division by 3 is slow, so they have opted to use 0..192 because they can then use division by 4.
Keep in mind, this is just speculation as their docs seem to suggest that the hue values is between 0 and 255, but running the code suggests otherwise.
Perhaps the performance penalty from division isn't that bad and we can use that instead?
I'd personally rather have a correct and simple to use general purpose library (and that's what smart-leds seems to be) and optimize for speed only if necessary 😛. ("Premature Optimization is the root of all evil" - D. Knuth).
I mean, If for some project or hardware the algorithm is indeed not fast enough, it can easily be exchanged by a custom and optimized one.
Yep, I think I agree, and the only reason I didn't extend it to 255 in that PR is that I couldn't be bothered to figure out the required changes to the algorithm for that to work. In this case, I just used the same algorithm that FastLED does
I've overlooked that fastled scales the hue value from 0-255 to 0-191 before using it (https://github.com/FastLED/FastLED/blob/dae69768c643f69a8856dfc1b769d62ae051b624/hsv2rgb.cpp#L259). Their implementation is pretty simple (https://github.com/FastLED/FastLED/blob/6af86cea6cbe110b0ec9432c52db9e74d1704717/lib8tion/scale8.h#L20), so hue = (hue * 192) / 256
should work and be equivalent.
Hi,
I think the HSV to RGB conversion is wrong. It also panics for hues above 190.
Testcode:
Output:
Depending on how you interpret the hue type (degree as u16 or 360°/255) the values should be: Degree:
Fraction: