Wrong Colors

[ShockWaveFlash]

I have a small problem with HyperHDR. Some of the colors don't match. What do I have to set to get them right?

Sometimes light sources are also shifted. The lamp is further to the left than HyperHDR shows

[awawa-dev]

Hi
'One piece' 😉 ? Check out HyperHDR video live preview and compare it with what's displayed on your TV.

[NatyaSadella]

Yes One Piece 😋

I've already watched the live preview. Something's not right. The stream looks weird.

While watching, open the elgato 4K capture utility on your PC and increase brightness and/or contrast. It's the typical „you don't see anything in dark scenes„ LUT behavior.

[awawa-dev]

I don't think this is a good idea. The brightness/contrast/saturation/hue etc controls are for the SDR signal standard. If you apply it to raw HDR you will ruin it, so I recommend leaving it on neutral settings. If the image becomes corrupted before Elgato receives it (and the LUT has nothing to do with it because it didn't even have a chance to do anything about it), there is no such post-processing correction that will fix it properly afterwards: the damage is already done.

[NatyaSadella]

I don't think this is a good idea. The brightness/contrast/saturation/hue etc controls are for the SDR signal standard. If you apply it to raw HDR you will ruin it, so I recommend leaving it on neutral settings. If the image becomes corrupted before Elgato receives it (and the LUT has nothing to do with it because it didn't even have a chance to do anything about it), there is no such post-processing correction that will fix it properly afterwards: the damage is already done.

Many things about Ambilight maybe aren't mathematically correct, but look way better for the naked eye. If you are not satisfied because the live preview is way too dark then you have to increase brightness and/or contrast to your liking. It's simple as that. Maybe the calculations aren't correct anymore but who cares if the results are way better and do exactly what you want?

If I go by data alone then I have created the worlds best LUT with a error score of 82 at the lowest. Even a lot lower than your best scores, but guess what? The image looked like shit. So what's better? Having a error score of 82 and a wrong image or a score of 700 and the most perfect live preview image you have ever seen?

[awawa-dev]

And look what has been done with ms2109, where manufacturers improve the saturation/contrast/brightness a bit? For SDR it looks really nice but it completely messes up the calibration, but to fix HDR you need a RAW signal. Not modified in any way. If in your case you managed to improve the situation, then good, I'm happy, but it has nothing to do with standard signal processing (unless the Elgato settings are not so neutral from the factory) and reminds me of the old method of achieving HDR to SDR tone mapping by applying brightness /contrast/saturation/hue… even then and now some people thought it was cool and sufficient. So I won't change my opinion because there is no basis for it. Here on the screenshots you can see that the image is completely broken, too dark, or to say it correctly: the HDMI splitter set a very high brightness point and converted it accordingly.

[luisperis]

Hi 'One piece' 😉 ? Check out HyperHDR video live preview and compare it with what's displayed on your TV.

Hi I have similar issue.
I have ezcoo splitter hdmi 2.0 HDR and very cheap grabber:
https://www.amazon.es/dp/B0895N9KM5?psc=1&ref=ppx_yo2ov_dt_b_product_details
i have a rpi 3b+ with hyperhdr and te led strip si a ws2812b with ESP32 and WLED.
I have tried RGF, GRB, .... all combinations and i have done the test of the greeen/red spots.... and fiunally always some colors don't match (see attached picture)....
and when HDR is on no light in the led strip, any clue?

Thanks in advance.

[ameran]

I have a similar problem.
I'm running a RSPi Zero 2W, when I preview the captured content, I get this:

when I hook the capture card up to my MacBook and run HyperHDR for Mac, I get this:

So I know the capture card isn't faulty and working correctly, but when I connect it to the Pi the colours are all wrong.
Everything else works, just the colours and none of the setting I change makes a difference.

Any ideas?

[awawa-dev]

Check the pinned topic

[dkovacic74]

I had a wrong color capture with HyperHDR on RPI zerro 2W. Instead of green, I had a purple etc.

I was experimenting with hardware hue and saturation, and after a lot of trials I found combination that compensated error.

[awawa-dev]

I've learned a lesson for the future: no matter how many exclamation marks I use in a pinned topic's subject, people won't read it anyway 😉
Not a HyperHDR issue, it is a kernel bug: #848

[z3rone]

Thank you soo immediately works after hue shift

[dtraparic]

I've learned a lesson for the future: no matter how many exclamation marks I use in a pinned topic's subject, people won't read it anyway 😉 Not a HyperHDR issue, it is a kernel bug: #848

Thank you so so much, I had the same issue with a yuv capture card, finally have correct contrast and colors thanks to the raspberrypi kernel fix. Colors were all very dark and noisy, of course even after a simple hue shift.

[rama31244]

What kernel fix did you apply? I run raspberry pi 3b and have not been able to get the colours to correct even after kernel downgrade

[orrionis]

Hello all, i had the same problem and with help chatGPT i have a little solution its not perfect but it's work

Fix V4L2 Colors for HyperHDR on Raspberry Pi

If you are using HyperHDR on a Raspberry Pi with Debian 12 / Kernel 6.12+, you may notice that your Ambilight LED colors are wrong after a system update. Brightness, contrast, saturation, and hue defaults are often completely out of range, causing color shifts.

This repository provides a simple script and systemd service to permanently fix V4L2 color issues.

---

Symptoms

• Ambilight colors are off (red/orange shifts, blue/green issues)
• HyperHDR works, but manual color adjustments are needed
• v4l2-ctl --list-ctrls shows absurd default values, e.g.:

---

Solution

We will force the correct values for brightness, contrast, saturation, and hue at boot using a script and a systemd service.

---

1️⃣ Create the Fix Script

Create /usr/local/bin/fix_v4l2_colors.sh:

#!/bin/bash
# fix_v4l2_colors.sh
# Script to fix V4L2 colors on Raspberry Pi for HyperHDR

VIDEO_DEV="/dev/video0"
MAX_WAIT=15  # max wait in seconds
WAIT_INTERVAL=1

echo "Waiting for $VIDEO_DEV..."
WAITED=0
while [ ! -e "$VIDEO_DEV" ]; do
    sleep $WAIT_INTERVAL
    WAITED=$((WAITED+WAIT_INTERVAL))
    if [ $WAITED -ge $MAX_WAIT ]; then
        echo "Error: $VIDEO_DEV not found after $MAX_WAIT seconds."
        exit 1
    fi
done

echo "$VIDEO_DEV detected. Applying color settings..."

v4l2-ctl -d $VIDEO_DEV --set-ctrl=brightness=0
v4l2-ctl -d $VIDEO_DEV --set-ctrl=contrast=128
v4l2-ctl -d $VIDEO_DEV --set-ctrl=saturation=128
v4l2-ctl -d $VIDEO_DEV --set-ctrl=hue=0

# Optional: force video format if necessary
# v4l2-ctl -d $VIDEO_DEV --set-fmt-video=width=1920,height=1080,pixelformat=YUYV

echo "V4L2 colors fixed for $VIDEO_DEV."

---

2️⃣ Make It Executable

sudo chmod +x /usr/local/bin/fix_v4l2_colors.sh
sudo dos2unix /usr/local/bin/fix_v4l2_colors.sh  # if edited on Windows

---

3️⃣ Create the Systemd Service

Create /etc/systemd/system/fix-v4l2-colors.service:

[Unit]
Description=Fix V4L2 Colors for HyperHDR
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fix_v4l2_colors.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

---

4 Create the Systemd Service

Create /etc/systemd/system/fix-v4l2-colors.service:

[Unit]
Description=Fix V4L2 Colors for HyperHDR
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fix_v4l2_colors.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

---

###3️⃣ Enable the Service

sudo systemctl daemon-reload
sudo systemctl enable fix-v4l2-colors.service
sudo systemctl start fix-v4l2-colors.service
sudo systemctl status fix-v4l2-colors.service

---

✅ This will ensure the colors are correct every boot, before HyperHDR starts capturing.

Optional Tweaks

Adjust brightness, contrast, saturation, and hue in the script if your grabber behaves differently.

Force the video format (YUYV/MJPEG/NV12) if necessary to match your grabber.

The script waits up to 15 seconds for the grabber to be ready; adjust MAX_WAIT if needed.

[awawa-dev]

This is a workaround only for one featured grabber and reporting the issue to RPi might take 1-2 minutes and would probably solve the problem once and for all... but as can be seen we've been where we are for almost a year.

[heeeeeenerika]

Hey, has this kernel bug been resolved already? I am having this issue with several hyperhdr images or normal pi os.