Skip to content

The New RGB to RGBW Algorithm with Temporal Dithering - powered by Infinite Color Engine

The Inspiration: Eliminating the "Pumping" Effect

The development of this new RGB to RGBW algorithm was sparked by a frustrating visual glitch: the "pumping" effect. This phenomenon was highly visible during rapid transitions from near-full brightness (white screen) to near-black scenes in a short time - something you can observe, for example, at around 21 seconds in the intro of anime "Lord of the Mysteries", which irritated me immensely.

The issue didn't lie within standard smoothing algorithms or color temperature calibration via my HyperSerial. The real problem was the way the dedicated white diode was managed - specifically its power output, not just color calibration, which classic algorithms simply didn't take into account.

After many experiments lasting since the beginning of 2026, I think I have finally found the solution.

The 3 strategic pillars of the algorithm's success

Here is exactly what changed to fix this issue:

  • 1. Float-Based Infinite Color Engine (ICE): First, the ideas of classic calibration from my HyperSerial were translated into the extended spectrum world of the Infinite Color Engine. The core difference is that while HyperSerial worked on 24-bit integer colors, ICE operates entirely on high-precision floats.
  • 2. Soft Mixer for the White Channel: Second, a soft mixer was added to the white channel. The logic is simple: in darker scenes, we want to rely less on the W diode, whereas in bright scenes, we want to use it much more.
  • 3. Temporal Dithering: The third element is dithering, which allows the algorithm to remember the accumulated quantization error from previous frames.

All of this combined effectively minimizes the aforementioned pumping effect.

Hardware Support & Network Requirements

We have added support for this new algorithm across all drivers: HyperSerial, HyperSPI, ArtNet, DDP, Hyperk, and RPI5 GPIO.

Important Note for Updating: Network drivers (like Hyperk, ArtNet or DDP) will handle this new protocol automatically. However, for HyperSerial and HyperSPI, we had to add a new protocol version that supports sending "direct-32-bit" (RGBW rendered straight to the LED strip). You will need to update your device firmware if you want to take advantage of this new feature.

This is necessary because such advanced calibration must now be performed directly on the HyperHDR unit, which then sends the ready-to-render RGBW frame to the device. Naturally, sending a 4-channel RGBW stream will cause a 33% overhead in data transfer. However, if you are using the long-recommended Raspberry Pi Pico - which realistically achieves speeds of several Mbps thanks to its CDC (USB) connection - you probably won't even feel it. It's even less of an issue with HyperSPI which uses over 20Mb speed.