# HyperHDR: a floating-point color pipeline for LED backlighting > HyperHDR analyzes video and audio on the host machine and pushes the result to addressable LED strips over USB serial or SPI. Its v22 Infinite Color Engine works in floating-point linear sRGB rather than 24-bit integers, and the real engineering sits in the RGB-to-RGBW conversion that keeps white LEDs from flickering. **awawa-dev/HyperHDR** — Next-gen open source ambient lighting system featuring a high-precision floating-point color pipeline breaking legacy RGB 24-bit limits. Includes advanced smoothing with inertia and adaptive temporal dithering for perfectly fluid, stable output to LEDs from any SDR or HDR video source. Supports Windows, macOS and Linux (x86/ARM). - Repository: https://github.com/awawa-dev/HyperHDR - Website: http://www.hyperhdr.eu/ - Stars: 2,163 · Forks: 220 - Language: C++ - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/awawa-dev-hyperhdr ## Ambient lighting computed on the host, not on the strip HyperHDR sits between a video source and a strip of addressable LEDs behind a television or a music setup. It analyzes video and audio streams in real time and turns them into light. The part worth understanding first is where the work happens: the analysis runs on the machine producing the picture, not on the microcontroller driving the LEDs. Frames are captured on the host, decoded and mapped there, and the resulting pixel stream is shipped to the strip. That split defines the project's shape. The host side is a C++20 CMake project with a web interface, a JSON API, MQTT and mDNS, and integrations for Home Assistant and zigbee2mqtt. The strip side is one of several controller firmwares, including the project's own HyperSPI, HyperSerial and Hyperk, or third-party firmware such as WLED and the Adalight protocol. A Raspberry Pi is a first-class target rather than an afterthought, and the README names both an Intel N100 class machine and the Pi as SoCs where CPU use stays low. Platform support is stated concretely: Windows 10 and 11, macOS on x64 and arm64, and Linux on x64 and ARM including the Pi. Capture is hardware accelerated on Windows through DirectX and on Linux through PipeWire and Portal, with USB grabbers as the portable path. So the audience is someone who owns an addressable strip and wants it driven by whatever is on their screen or playing, on hardware that already exists. It is not a lighting design tool and not a video player. ## The Infinite Color Engine and the 24-bit ceiling Version 22 brought the Infinite Color Engine, described as an in-house rendering pipeline that computes colour in floating point rather than in packed 24-bit integers. The argument is arithmetic. Every step in a chain of conversions rounds to eight bits per channel, errors accumulate, and the residue shows up as banding in a slow gradient, which is exactly the kind of content ambient lighting follows. The stated components of that pipeline are specific. Core transformations happen in linear sRGB space rather than in the gamma-encoded values most pipelines pass around. Interpolators come in three flavours, inertial-physics, exponential and perceptually-uniform, covering both YUV and RGB, and the point of the first is inertia: a light that keeps moving rather than snapping between sampled colors. Compatible devices, including Philips Hue lamps, LIFX and HD108 LEDs, can be driven beyond standard 24-bit depth. Read this as the project's own claim rather than a measured result. The README explains why 24-bit work loses precision, but nothing here publishes a banding measurement, a histogram, or a before-and-after comparison, so the improvement is plausible and unquantified. What is verifiable is the design commitment: floating-point arithmetic throughout, linear-space conversion at the core, and smoothers designed around physical continuity rather than nearest-neighbour blending. ## RGB-to-RGBW conversion is where flicker actually starts The more interesting subsystem is the RGB-to-RGBW conversion, which the project says it also wrote from scratch. An RGBW strip has a dedicated white LED alongside the three colour channels, which is how white light gets more output than mixing red, green and blue can give. Driving it badly is a common failure: reducing the three colour channels to add white changes the effective colour temperature, and any mismatch between the white channel and the colour mix shows up as flicker or as a tint that shifts over time. The listed countermeasures are all aimed at that. Extraction is energy-preserving, so the white channel is added without changing total output. Mapping is temperature-aware, so the white point is calibrated rather than assumed. Temporal dithering spreads the quantisation error across frames instead of holding it steady, and it is described as motion-adaptive, so the diffusion changes with how fast the underlying image moves. Anti-flicker hysteresis stops the conversion from oscillating between two near-identical outputs. For a reader deciding whether this matters, the honest test is a strip with a white channel and slow gradients on screen. That combination is where the compromises show, and it is the case the hysteresis and dithering are aimed at. A strip with no white channel, such as plain WS281x, skips this path entirely. ## Capture paths: DirectX, PipeWire and a wall of pixel formats Getting frames in is the part with the most moving pieces, and the README lists them explicitly. Hardware-accelerated capture means PipeWire with Portal on Linux and Wayland, and DirectX on Windows 10 and 11. HDR-ready DirectX grabbing supports the R16G16B16A16_FLOAT DXGI format and multiple monitors, which is what makes an HDR desktop drive the LEDs rather than a washed-out SDR version of it. Where hardware capture is unavailable, USB grabbers are supported on Linux, Windows and macOS across P010, NV12, YUYV, MJPEG, UYVY, I420 and RGB. Two of those deserve attention. P010, the 10-bit format that matters for HDR, is listed as supported on Windows and Linux but only through the project's patched Raspberry Pi OS image, because mainline does not support it. That is a genuine constraint rather than a footnote: a stock Pi OS install does not get you P010. And the grabber path has its own support tooling, including automatic LUT calibration that uses MP4 test files to pick the right lookup table for HDR versus SDR capture, latency benchmarking, and smart signal detection with adaptive learning. Content handling covers automatic tone mapping for SDR and HDR sources, and external tone mapping for flatbuffers and protobuf sources when you want the conversion done outside the pipeline. Dolby Vision is supported, with the caveat printed right next to it: only Low Latency Dolby Vision, and only if your hardware can do it. There is also a built-in audio visualiser driven by spectrum analysis for music setups, which is where the MQTT and Home Assistant integration earns its place. ## HyperSPI, HyperSerial, Hyperk, and what WLED does differently Strip compatibility covers WS281x, APA102, HD107, SK9822 and SK6812, plus three controllers this project maintains. HyperSPI talks to ESP8266, ESP32 and RP2040 over SPI. HyperSerialEsp8266, HyperSerialESP32 and HyperSerialPico use a USB serial port at 2Mb or more, which is the usual answer when the strip sits behind a TV and the host is a few metres away. Hyperk is the wireless option, covering ESP8266, ESP32 including the S2, S3, C2, C3, C5 and C6 variants, and Raspberry Pi Pico W on both RP2040 and RP2350. The real alternative to all of this is WLED, and the difference is architectural rather than a feature list. WLED runs the effect engine on the controller itself, so the ESP32 receives a colour buffer and generates the animation locally; HyperHDR keeps the analysis on the host and ships final pixels. That buys HyperHDR the floating-point pipeline, the linear-space conversions and the RGBW handling, since the controller never sees the video. It costs you a network or serial hop, and it means the Pi or PC is in the critical path for every frame. There is a third pattern in the same space. Adalight, also listed as supported, is an older host-to-strip protocol that predates both, useful when you want to drive a strip with something that is not HyperHDR. Adalight support matters mostly for compatibility with existing hardware setups. ## Where HyperHDR stops working The first boundary is hardware you do not have. This needs an addressable strip and a controller, or a USB grabber, or a host that can capture its own screen. Without one of those there is nothing for the software to do, and no part of it substitutes for the strip. The second is P010 on a stock Pi. The README is explicit that P010 is not supported in mainline OS and that HyperHDR's patched image is the route, so a user who wants 10-bit HDR capture on a Raspberry Pi has to adopt an unofficial OS image, which is a real maintenance commitment outside this project. The third is evidence. The README promises low-latency video processing, ultra-low CPU use on SoCs like the Pi and the Intel N100, and a pipeline that handles 1080p P010, NV12 and YUYV even on a Pi 4. None of those claims comes with a figure. There is a latency benchmarking feature for USB grabbers and a system diagnostics panel showing live CPU and RAM use, CPU temperature and undervoltage detection, which is the right way to measure it yourself, but no published numbers are given. The diagnostics matter more on a Pi than on a desktop, and the undervoltage detection is there because a throttled Pi changes what your latency looks like. The fourth is platform drift. A C++20 CMake project with an `external/` tree and a `.gitmodules` file needs its submodules initialised, and vendored third-party code is tracked separately in a 3RD_PARTY_LICENSES file, which is a fair warning that you are inheriting two licence trees rather than one. ## MIT, two release channels, and signed Windows installers The licence is MIT, recorded in LICENSE at the top level. Windows installers are code-signed by the SignPath Foundation, and the project publishes a code signing policy alongside it, which matters more than it sounds for an application that runs as a background service capturing your screen. Releases come on two channels. Tagged versions include HyperHDR 22.0.0beta2 on 2026-05-08 and HyperHDR 22.0.0 on 2026-09-01, where the version is also stamped in a `version` file at the repository root and fed through a generated `HyperhdrConfig.h.in`. Alongside them sits a rolling tag for the latest daily development build, last dated 2026-09-08. That is a sensible split, but it means there are two ways to be wrong: a tagged release from May is old, and a daily build is by definition untested by anything except whoever ran it. The last push was on 2026-09-28 and the repository is not archived, so the code is moving faster than the tags. Building from source is documented separately in BUILDING.md with a build.sh entry point, and the tree carries both .clang-tidy and .clazy configuration, so static analysis is part of the project's own workflow rather than an afterthought. For anyone pinning a version in a home-assistant setup, decide which channel you are on first, because the v22 colour engine is a version boundary and older tags do not have it. ## Conclusion Adopt HyperHDR if you already own an addressable strip and can get frames into the host, whether from DirectX, PipeWire or a USB grabber, and if you want host-side analysis rather than a controller-side effect engine. Skip it if your capture path is 10-bit P010 on a stock Raspberry Pi OS, since the README offers that only through a patched image, or if you expect documented benchmark figures, which the release notes do not carry. Read HyperhdrConfig.h.in, the version file and the 3RD_PARTY_LICENSES tree before building from source with CMake. ## FAQ ### What hardware do I need to run HyperHDR? An addressable strip such as WS281x, APA102, HD107, SK9822 or SK6812, plus a controller: HyperSPI for ESP8266, ESP32 or RP2040 over SPI; HyperSerialEsp8266, HyperSerialESP32 or HyperSerialPico over USB serial at 2Mb or more; or the wireless Hyperk for ESP8266, ESP32 and Raspberry Pi Pico W. HyperHDR itself runs on Windows 10 and 11, macOS on x64 and arm64, and Linux on x64 and ARM including the Raspberry Pi. ### Does HyperHDR support HDR video and Dolby Vision? It works with SDR, HDR and Dolby Vision, with the caveat that only Low Latency Dolby Vision is supported and only if your hardware supports it. HDR-ready DirectX grabbing handles the R16G16B16A16_FLOAT format and multiple monitors, and automatic tone mapping covers SDR and HDR sources, with external tone mapping available for flatbuffers and protobuf inputs. ### How do I capture video for HyperHDR on Linux or Windows? PipeWire with Portal gives hardware-accelerated capture on Linux and Wayland, and DirectX does the same on Windows 10 and 11. USB grabbers work on Linux, Windows and macOS for P010, NV12, YUYV, MJPEG, UYVY, I420 and RGB, with automatic LUT calibration from MP4 test files and latency benchmarking built in. ### What does the Infinite Color Engine add in HyperHDR v22? It is the project's own rendering pipeline using floating-point arithmetic instead of packed 24-bit color, with core transformations done in linear sRGB and interpolators in inertial-physics, exponential and perceptually-uniform variants. Compatible devices including Philips Hue, LIFX and HD108 can then be driven beyond standard 24-bit depth, and a bespoke RGB-to-RGBW conversion adds temperature-aware mapping, temporal dithering and anti-flicker hysteresis. ### Can HyperHDR drive strips running WLED or Adalight firmware? Yes, both are listed as supported alongside HyperHDR's own HyperSPI, HyperSerial and Hyperk controllers. The architectural difference is where the effect engine runs: WLED generates animation on the controller itself, while HyperHDR analyzes video on the host and ships finished pixels to the strip. ### How is HyperHDR licensed and how often is it released? The licence is MIT, with vendored third-party code tracked separately in a 3RD_PARTY_LICENSES file next to the external/ tree. Releases come as tags such as HyperHDR 22.0.0 on 2026-09-01 plus a rolling tag for the latest daily development build, and Windows installers are code-signed by the SignPath Foundation under a published code signing policy. ## Sources - [awawa-dev/HyperHDR on GitHub](https://github.com/awawa-dev/HyperHDR) - [License: MIT](https://github.com/awawa-dev/HyperHDR/blob/master/LICENSE) - [Project website](http://www.hyperhdr.eu/) - [README](https://github.com/awawa-dev/HyperHDR/blob/master/README.md) - [Releases](https://github.com/awawa-dev/HyperHDR/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/awawa-dev-hyperhdr