Skip to content

Advanced RGB to RGBW Conversion with Temporal Dithering (ICE)

Problem Statement: Eliminating Luminance "Pumping"

The development of this algorithm was driven by the need to eliminate the "pumping" effect—a visible luminance instability occurring during rapid transitions between high-brightness and near-black scenes. This artifact is particularly noticeable in high-contrast content (e.g., the 21-second mark in each of the Lord of the Mysteries episodes intro), where standard smoothing and color temperature calibration fail to maintain consistent output.

The root cause was identified as the management of the dedicated white diode's power output. Conventional algorithms typically do not account for the non-linear relationship between the white channel and overall scene luminance during these sharp transitions.

Technical Implementation

High-Precision Floating-Point Processing (ICE)

The Infinite Color Engine (ICE) replaces standard 24-bit integer workflows with a high-precision floating-point pipeline. While previous iterations (such as HyperSerial) operated within integer constraints, ICE performs all internal color calculations using floats to preserve data integrity across the extended spectrum.

Dynamic White Channel Scaling

A "Soft Mixer" has been implemented for the white channel. The algorithm dynamically adjust the white diode's weighting based on the scene's brightness. In low-light environments, the reliance on the W diode is minimized to preserve black levels; in high-brightness scenes, its utilization is increased to maximize output efficiency.

Temporal Dithering and Error Accumulation

To mitigate quantization artifacts, the algorithm employs temporal dithering. This process tracks and carries over quantization errors from previous frames, distributing the error across the time domain to ensure smoother gradients and transitions. To avoid the risk of unnecessary flickering, we disable temporal dithering when the LED color remains unchanged. Thus, temporal dithering is used exclusively to ensure maximum smoothness in animation transitions, accounting for 8-bit quantization errors from previous frames.

Hardware Requirements and Constraints

Important: The effectiveness of Temporal Dithering is strictly dependent on the LED refresh rate.

Users utilizing hardware with low update frequencies—such as large Neopixel LEDs setups without multi-segment optimization, limited or unstable WiFi connection in case of wireless LED controllers or Arduino-based setups limited to ~25Hz —should not expect significant visual improvements. For the dithering to function as intended and eliminate visible flickering, a high-frequency refresh rate is mandatory. Otherwise, dithering might actually make things worse by introducing its own visible flickering on low-frequency setups.

Warning

Due to the nature of dithering, the minimum required FPS when rendering to LEDs is around 50Hz, with 60-80Hz being recommended. And we're talking about the actual refresh rate — not just you setting the smoothing refresh rate to that value, only for your controller to fail at displaying it because of a NeoPixel bottleneck or controller's slow communication. However, since we've been recommending an optimal build with fast communication thanks to HyperSerial & HyperSPI and the possible use of multi-segmenting for years, if you've followed those guidelines, you'll be reaping the rewards right now

Firmware and Driver 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 to version v11 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.

Setup

ice

  • ICE white mixer threshold:
    Defines the activation point for the soft-mixer. It triggers a linear transition of the common RGB component to the white channel based on color brightness. A value of 1.0 completely disables the mixer taking all the common RGB into account (significantly increases the white diode's contribution), while lower values determine the starting point for the gradual ramp-up e.g. 0% transfer at the threshold, 50% halfway to maximum.
  • ICE white led intensity:
    Defines the physical brightness of the typically higher-intensity white diode relative to the combined RGB diodes. Setting this value higher than your hardware's actual output will cause the engine to underdrive the white channel, resulting in lower overall utilization of the white diode.
  • ICE white temperature: Defines the color temperature (white point) of the dedicated white LED. Default values are empirically calibrated for SK6812 Cold White. If using warmer variants, such as SK6812 Neutral White, you may need to lower the Blue channel value to protect the light of physically weaker blue diode present in those models.

Tip

For testing: to enable the white diode for the full common RGB part, set the mixer to 1.0 and temperature to (1.0, 1.0, 1.0).
To disable the white diode and produce white color from RGB diodes, set the temperature to (0.0, 0.0, 0.0).