Hi!
I am using FastLED in combination with the hsv2rgb_spectrum() function. While cycling a rainbow pattern, I noticed a blue dot running across the LEDs.
After further investigation it turned out that when CHSV(255, 255, 255) (red) is passed to hsv2rgb_spectrum(), consistently results in 0, 0, 251 (blue). Regardless of the saturation or value, if the hue is 255, red remains 0 and blue changes accordingly. With a hue of either 254 or 256, the result will again be red, going round as expected.
CHSV hsv = CHSV(255, 255, 255);
CRGB rgb;
hsv2rgb_spectrum(hsv, rgb); // 0, 0, 251
Am I misunderstanding how to use this function? Since CHSV(255, 255, 255) is indeed red when used on its own, I would expect a result that approaches that when converted to spectrum RGB. Thank you for your reply!
Thanks for the report and the code. I’ll take a look at it and let you know!
A few subtle math bugs crept in about a year ago and we’re fixing them when they show up like this. Thanks again and stay tuned.
Opened issue 412 for this https://github.com/FastLED/FastLED/issues/412
Hi @The_Pendulum – Thanks for the bug report and the video. The problem was, in fact, an off-by on resulting from “the scale8 change” a while back. I’ve committed a fix for this to the github repository; pulling down the very latest code from github should solve the problem.
Two other quick items. First, hue=255 isn’t red; hue=0 is red. hue=255 is almost all the way around the spectrum (back) to red, but it will have some blue in it, and it does now.
Second, I’m curious what your application for the ‘spectrum’ color space is instead of the default ‘rainbow’ color space. I’m always curious to see what applications different people have for the different color mappings. What are you working on for which you chose ‘spectrum’ over ‘rainbow’?
Thanks again for the bug report; it seems fixed now from my end, anyway.
Thank you, I’ll see if I can get the fix installed to test it!
I should’ve been clearer. I expected a strong shade of red at 255, instead of blue, but indeed not pure (255, 0, 0) red.
I haven’t used FastLED for too long so maybe my reasoning is off, but I opted for the spectrum mapping because the primary/secondary color ‘peaks’ are not evenly distributed in the rainbow mapping, which would require me to use more explicit functions for a lot of basic effects.
For example, if I want to light up my pixels a solid red, green, blue, red, green blue, etc. in sequence, I would normally calculate index * 85 as the hue (1/3rd of 255). In the rainbow mapping, there is more distance between red and green than there is between green and blue, which would cause a similar function to start shifting the colors. I have several of such patterns, and often there are too many variables involved to simply cycle through hard-coded color positions.
On the LEDs I use, the difference between the two mappings didn’t seem all that perceivable, hence writing more complicated and explicit functions to accommodate for the rainbow mapping didn’t seem worth it.
I can confirm the fix seems to have resolved the issue! 
Thanks again for the quick action!
