WS2812 datasheet(59/98 Pages) RASPBERRY-PI

59 / 98 page

setPixelColor() and fill() both still want RGB values though, so we convert to these from HSV by using the ColorHSV()

function:

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

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

uint32_t rgbcolor = strip.ColorHSV(hue);

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

strip.fill(rgbcolor);

There is

no 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.

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

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!

https://learn.adafruit.com/adafruit-neopixel-uberguide

Page 62 of 101

WS2812 bảng dữ liệu(PDF) 59 Page - Raspberry Pi Holdings PLC

WS2812 bảng dữ liệu(HTML) 59 Page - Raspberry Pi Holdings PLC

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

bảng dữ liệu tải về

Link URL