Closed sajattack closed 4 months ago
Does RGBW behave differently than RGBA, or is this just a matter of renaming .a
to .w
?
If you could define your Color
as an alias to RGB<u8>
, it'd be nicely interoperable.
But colors exist only in a color space, and I'd like to keep this crate color-space agnostic, so I'd rather not have definitions of specific colors.
Is it a possibility to add rgbw
to the alts or does that mess everything up?
It should be possible. I can't simply reuse existing RGBA-defining macros for this since methods like alpha()
would be silly.
For 1.0 of this crate I want to move more methods to traits, so it's a nice case to consider.
I think the question when integrating Rgbw
into the 0.9
traits will be whether it should act as a HomogeneousPixel
or a HeterogeneousPixel
with regards to the w
component. Since it seems the main use-case is with RGBW led strips and in that scheme W
is technically the color White it sees to me it should be Homogeneous.
Therefore supporting it is as easy as defining an Rgbw
struct:
struct Rgbw<T> {
r: T,
g: T,
b: T,
w: T,
}
Yes, I think W should count as a color component. AFAIK in the hardware the W subpixel is merely a different color, but still driven in the same way as other primary colors. Color management in RGBW color space is more complicated, but just like gamma of RGB leds, it's beyond the scope of this crate.
I think this issue can be closed as completed in #107?
Hello from smart-leds-rs. We're doing a bunch of work on RGB LEDs (ws2812/apa102/et al) for microcontrollers, and evaluating using your crate for our RGB type. One thing we have a need for is an RGBW type, which isn't quite the same as RGBA, it's more like brightness instead of transparency. Another thing I was wondering was if you'd like to take ownership of our mass of colour constants. Personally, I don't feel like defining a bunch of colours should be the responsibility of our crate, and I was wondering if it would fit better in yours. I hope we can find a good compromise. Cheers.