HDR with APA102/SK9822

I’ve read in several posts and docs that HDR is supported with apa102/sk9822 strips. Is there anything specific you need to have in your pattern or render functions to enable HDR output on these strips? Any specific syntax for hsv() or rgb()? Thanks.

Nope! It’s all automatic, but note that you need to use the hsv() call (not hsv24() or rgb()) to make use of the extra bits and get HDR out.

It really makes a big difference. It’s beautiful.

… does HDR mean that the v component accepts values higher than 1?

It means that the extra 5 bits of global brightness control on those pixels is used (each of the normal 8 bits of each R, G, B color is effectively multiplied by this value).

v values greater than or equal to 1 are still treated as full output. Since Pixelblaze internally uses 16.16 bit fixed point math, there’s 16 bits of resolution for each of H, S, and V. In HDR mode, those 16 LSBs to the right of the decimal are translated into the 5 + 3 * 8 bits of APA102; in WS281X mode, they’re translated into just 3 * 8 bits of RGB.

The end result is much smoother changes on the low-intensity end and in gradient color mixing. You might have noticed how neopixels seem steppy/blocky when animated to/from off.

Thanks Jeff, very helpful. Yeah patterns like these are where I notice it most…where colors subtly gradate to black or into another color. It looks amazing.

Why can’t that happen with the rgb() call? I could implement an RGBtoHSV() function but it seems like a direct rgb() to HDR call would be faster.

Far as I know, rgb() does work with the extra color bits. @wizard changed this a bit before v3.20, per this thread:


Yes, I can confirm that Pixelblaze now does HDR for both hsv() and rgb() when the LEDs support it.

If you do not want it, or are just curious what things would look like without it, you can switch an hsv() to hsv24() (the 24 is for 24-bit color). The only time this is really useful is if you have genuine APA102 (not SK9822 or any of the clones), and want to do persistence of vision type things (like poi, staves, etc), since the original APA102 implements global brightness as a ~400Hz PWM and it looks terrible. I didn’t add an rgb24() yet since this was a very niche use case.