tobi/KDEAmbi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: Add Ambilight TV concept to lessons_learned.md

Browse Source 
Documented the core principles of Ambilight TV and its relevance to the Hyperion_Grabber_X11_QT project, including potential causes for LED color mismatches.
This commit is contained in:
Tobias J. Endres 2025-08-15 22:37:03 +02:00
parent 27caa88ce9
commit 1411eff48e
1 changed files with 29 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
lessons_learned.md
View File

@ -150,14 +150,36 @@ This configuration is still primarily handled **within the WLED device itself**.
**Conclusion:** The issue was a mismatch between the sent color order (RGB) and the WLED's expected color order (RGB, confirmed by configuration). The `wled_test` program now correctly demonstrates full color control.
### Current Problem: Flickering with Static Screen
## Ambilight TV Concept
**Observation:** When running `Hyperion_Grabber_Wayland_QT`, some LEDs change color even when the screen is visually static, leading to flickering.
Ambilight TV, primarily a Philips technology, enhances the viewing experience by projecting dynamic, colored light onto the wall behind the television. This is achieved using intelligent LED lights positioned around the edges of the screen.
**Diagnosis:**
* Analysis of `output.log` revealed that the `scaledImage` (the input to `WledClient`) is *not* perfectly static, even when the screen appears still. The `WaylandGrabber` or underlying system introduces subtle pixel variations, causing the image checksum to constantly change.
* Our initial image difference threshold (`_changeThreshold_m = 100`) was too low, allowing these minor, visually imperceptible changes to trigger new frames to be sent to WLED.
**Key Principles:**
**Proposed Solution:**
* Increase the `_changeThreshold_m` significantly to filter out the noise from the screen capture. This will prevent sending new frames to WLED unless there's a visually significant change on the screen.
1. **Real-time Color Matching:** The core idea is to analyze the colors displayed on the TV screen in real-time and project corresponding hues onto the surrounding wall. For example, if the left side of the screen shows a bright blue sky, the LEDs on that side will emit a matching blue light.
2. **Extended Immersion:** This creates the illusion that the picture extends beyond the physical boundaries of the TV, making the screen appear larger and drawing the viewer deeper into the content.
3. **Reduced Eye Strain:** By softening the contrast between the bright TV screen and a dark room, Ambilight can help reduce eye strain and fatigue.
4. **Dynamic and Adaptive:** The lights are not static; they change dynamically with the on-screen content, reacting to color shifts, movement, and even audio (in some modes).
**How it Works (Generalizing for our project):**
* **Screen Analysis:** The system continuously captures and analyzes the video frame displayed on the screen.
* **Edge/Region Sampling:** Instead of analyzing every single pixel, the system typically samples colors from specific regions or "zones" along the edges of the screen. These zones correspond to the physical placement of the LEDs.
* **Color Averaging/Dominant Color Extraction:** For each sampled zone, a dominant color or an average color is calculated.
* **LED Control:** This calculated color is then sent to the corresponding LED(s) or LED segment(s) on the back of the TV, which illuminate the wall with that color.
### Relevance to `Hyperion_Grabber_X11_QT`
Our `Hyperion_Grabber_X11_QT` project aims to replicate this Ambilight functionality by:
* **Screen Capture:** The `WaylandGrabber` (or X11 grabber) captures the screen content.
* **Image Processing (`HyperionGrabber`):** The captured `QVideoFrame` is converted to a `QImage` and then scaled down (`scaledImage`). This `scaledImage` represents a lower-resolution version of the entire screen.
* **Color Extraction/Mapping (Implicit in `WledClient`):** This is where the crucial step of mapping the `scaledImage` to the individual LEDs happens. The `WledClient` iterates through the pixels of the `scaledImage` and sends them as RGB data to the WLED device.
**The Problem with Left-Side LEDs:**
Given the Ambilight concept, if the LEDs on the left side are not showing colors that match the left side of the screen, it strongly suggests an issue in one of these areas:
1. **Incorrect Sampling/Mapping in `WledClient`:** The `WledClient` might be iterating through the `scaledImage` pixels in an order that doesn't correspond to the physical layout of the LEDs. For example, it might be reading pixels from the top-left to bottom-right of the `scaledImage` and sending them sequentially, but the physical LEDs might be arranged starting from the bottom-left, then up the left side, across the top, and down the right.
2. **WLED Configuration Mismatch:** Even if the `WledClient` sends the data correctly, the WLED device itself needs to be configured to interpret that incoming stream of RGB data correctly for its physical LED layout. If WLED expects a different order (e.g., starting from the top-left LED and going clockwise), but our client sends data starting from the bottom-left, there will be a mismatch.
3. **Scaling/Aspect Ratio Issues:** While less likely to cause a complete side mismatch, incorrect scaling or aspect ratio handling could subtly distort the sampled colors.