在 HSV/HSB 中淡入更自然的彩虹光谱
我正在尝试控制一些 RGB LED 并从红色渐变为紫色。我正在使用 HSV 到 RGB 转换,这样我就可以从色调 0 扫描到色调 300(超过该范围,它会返回到红色)。但我注意到的问题是,它似乎在光谱的青色和蓝色部分花费了太多时间。所以我查了一下 HSV 谱应该是什么样子,发现了这个L
我没有意识到超过一半的光谱位于绿色和蓝色之间。
但我真的希望它看起来更像这样:
与“标准”彩虹色。 我想象这最终会成为正常色调值的某种 s 曲线,但我不太确定如何计算该曲线。
一个在内部处理这个问题的实际 HSV 到 RGB 算法会很棒(实际上任何代码,尽管它是针对 Arduino 的),但即使只是解释我如何计算色调曲线,我也会非常感激。
I'm trying to control some RGB LEDs and fade from red to violet. I'm using an HSV to RGB conversion so that I can just sweep from hue 0 to hue 300 (beyond that it moves back towards red). The problem I noticed though is that it seems to spend far to much time in the cyan and blue section of the spectrum. So I looked up what the HSV spectrum is supposed to look like, and found thisL
I didn't realize that more than half the spectrum was spent between green and blue.
But I'd really like it to look much more like this:
With a nice even blend of that "standard" rainbow colors.
I'd imagine that this would end up being some sort of s-curve of the normal hue values, but am not really sure how to calculate that curve.
An actual HSV to RGB algorithm that handles this internally would be great (any code really, though it's for an Arduino) but even just an explanation of how I could calculate that hue curve would be greatly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
FastLED 做了一个版本: https://github.com/FastLED/FastLED /wiki/FastLED-HSV-Colors
HSLUV 是另一种选择:http:// /www.hsluv.org/。他们拥有多种不同语言的库。
另外,这是一个有趣的技术:https://www.shadertoy.com/view /4l2cDm
另请参阅:
https://en.wikipedia.org/wiki/Rainbow#Number_of_colours_in_spectrum_or_rainbow了解更多信息。
FastLED does a a version of this: https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors
HSLUV is another option: http://www.hsluv.org/. They have libraries in a bunch of different languages.
Also, this is an interesting technique: https://www.shadertoy.com/view/4l2cDm
Also see:
https://en.wikipedia.org/wiki/Rainbow#Number_of_colours_in_spectrum_or_rainbow for more info.
http://www.fourmilab.ch/documents/specrend/ 有相当详细的描述如何将波长转换为 CIE 分量(大致对应于您眼睛中三种锥体传感器的输出),然后如何将它们转换为 RGB 值(警告某些波长没有< /em> 典型 RGB 色域中的 RGB 等效项)。
或者:有各种“感知均匀的色彩空间”,如 CIE L*a*b* (参见例如 http:// /en.wikipedia.org/wiki/Lab_color_space);您可以选择其中之一,沿着连接该空间中的起始颜色和结束颜色的直线采取相同的步骤,然后转换为 RGB。
不过,对于您的应用程序来说,其中任何一个都可能太过分了,而且没有明显的理由说明它们应该比更简单和纯经验的东西更好(或任何更好)。那么为什么不执行以下操作:
这完全是临时的,根本没有任何原则性,但它可能会工作得很好,并且最终的代码基本上很简单:(
如果您不关心保存每个可用周期,则可以使代码更清晰)。
无论如何,我的眼睛将划分点设置为大约 (0)、40、60、90、150、180、240、270、(300) 的色调值。您的里程可能会有所不同。
http://www.fourmilab.ch/documents/specrend/ has a fairly detailed description of how to convert a wavelength to CIE components (which roughly correspond to the outputs of the three kinds of cone sensors in your eyes) and then how to convert those to RGB values (with a warning that some wavelengths don't have RGB equivalents in a typical RGB gamut).
Or: there are various "perceptually uniform colour spaces" like CIE L*a*b* (see e.g. http://en.wikipedia.org/wiki/Lab_color_space); you could pick one of those, take equal steps along a straight line joining your starting and ending colours in that space, and convert to RGB.
Either of those is likely to be overkill for your application, though, and there's no obvious reason why they should be much -- or any -- better than something simpler and purely empirical. So why not do the following:
This is totally ad hoc and has nothing principled about it at all, but it'll probably work pretty well and the final code will be basically trivial:
(you can make the code somewhat clearer if you don't care about saving every available cycle).
For what it's worth, my eyes put division points at hue values of about (0), 40, 60, 90, 150, 180, 240, 270, (300). Your mileage may vary.