Datasheet

ManualsBrandsAdafruit ManualsAdafruitAdafruit NeoPixel Shield for Arduino LED Pixel Matrix



If you just want a “pure color” (fully saturated and full brightness), the latter two arguments can be left off:

In either case, the resulting RGB value can then be passed to a pixel-setting function, e.g.:

There is

corresponding function to go the other way, from RGB to HSV. This is on purpose and by design, because

conversion in that direction is often ambiguous — there may be multiple valid possibilities for a given input. If you look

at some of the example sketches you’ll see they

keep track of their own hues

…they

don’t

assign colors to pixels and

then try to read them back out again.

…and Gamma Correction

Something you might observe when working with more nuanced color changes is that things may appear overly bright

or washed-out. It’s generally not a problem with simple primary and secondary colors, but becomes more an issue with

blends, transitions, and the sorts of pastel colors you might get from the ColorHSV() function.

Numerically

the color

values are correct, but

perceptually

our eyes make something different of it, as explained in this

guide (https://adafru.it/w2B).

The gamma32() function takes a packed RGB value (as you might get out of Color() or ColorHSV()) and filters the result

to look more perceptually correct.

You might notice in strandtest and other example sketches that we

never

use ColorHSV()

without

passing the result

through gamma32() before setting a pixel’s color. It’s that desirable.

However, the gamma32 operation is

not built in

to ColorHSV() — it must be called as a separate operation — for a few

reasons, including that advanced programmers might want to provide a more specific color-correction function of their

own design (gamma32() is a “one size fits most” approximation) or may need to keep around the original “numerically

but not perceptually correct” numbers.

There is no corresponding reverse operation.

When you set a pixel to a color filtered through gamma32(), reading back

the pixel value yields that filtered color,

not

the original RGB value. It’s precisely because of this sort of decimation that

advanced NeoPixel programs often treat the pixel buffer as a

write-only

resource…they generate each full frame of

animation based on their own program state,

not

as a series of read-modify-write operations.

Help!

I’m calling setPixel() but nothing’s happening!



uint32_t rgbcolor = strip.ColorHSV(hue, saturation, value);

uint32_t rgbcolor = strip.ColorHSV(hue);

strip.fill(rgbcolor);

uint32_t rgbcolor = strip.gamma32(strip.ColorHSV(hue, sat, val));