Better Color Adjustment

I tested the new version too, working fine.

@Funatiq
I agree with you, maybe we should reduce the saturation by the same factor that luminance is increased. Let's say that global luminance is 0.05 and backlight luminance is 0.1, therefore the saturation reduction factor should be 2. Maybe even more aggressive, as we dont want a dark movie to keep changing backlight color at every scene.

new .tar.gz´s online
thank you

@Rick164
Does this help to avoid the color "shifting" (brightness)?

@AEtHeLsYn @Funatiq
discovered a bug: if you use the backlight setting and set a red or green or blue picture and go back to a black one the leds stay at a slightly red/green/blue (dependent from color)
Would be great if you could have a look.

There is a fun fact, if you disable the grabber with the kodi check this color won´t stay so it is no problem
@redPanther
Idea why this happen?

@Brindosh
Thats probably a smoothing issue. If you keep the black picture for a while, do the leds stay slightly colored?

yes/no, if you browse to another place (picture change) it is gone
but maybe it is a smoothing issue (in another way), i will disable it.

The backlight setting doesn't change the amount of color, only keeps luminance at a minimum, so the only thing I can think about that can reproduce this behaviour is smoothing.

// confirmed
disabled smoothing it is gone.
After redPanther stopt the processing if no new pictures arrive the last output is now a smoothed mix of black and green or black and red.
@redPanther
If you may have an idea

Edit: Should be no issue, cause this is just forced if you calibrate colors and get a high and short color change.
Maybe you are able to add a small hardcoded delay until the smoothing shutdowns the output

Hm, looks like the HSL brightness regulation is not suitable for everyone. Some people still just get a good regulation if they use HSV brightness.
Is there a special reason why this is so much different?

Regarding the MinimumLuminance i have to admit, i still use the old "blacklevel" implementation. It may be a bad hack but it works. Maybe we could go more in this direction to prevent issue with the backlight?

@Funatiq @AEtHeLsYn
So after some more testing i have sadly to say. the side effects of MinimumLuminance are really weird.
For me it looks like the last color still "hangs" in a lower value. This leads to a weird color mix around tv which is completely wrong even when the picture is already black.

If there is no real solution, is it possible to move to another (dirty) implementation like the old blacklvl. It kills the color space but it works.

Another thing:
People requested to set the min luminance just during grabbers are active, so it will be diabled if you use a "idle effect/color" or just black with disabled grabbers.
For this you may "move" this to another(new?) component which could be called (started and stopped) during runtime.
ping @redPanther
I will open a issue for this.

Would be helpful if Hypercon could access some of the v4l2 values. For me it helped a lot to disable chroma thingy. If hyperion does not get a decent source picture you can hardly fix it with the color corrections.

Chroma thingy on

And off

@HalbesHaehnchen

After fighting with hyperion color corrections i recognized that my fushicai grabber output is over saturated, exactly like your chroma on picture. So all my calibration effords lead to strange colors... Can you please tell me how you disabled this over-saturation?

I already changed my image from openelec to raspian so i have access to v4l2-ctl - butno i have no idea how/what to change...

pi@raspberrypi:~ $ v4l2-ctl --all
Driver Info (not using libv4l2):
        Driver name   : usbtv
        Card type     : usbtv
        Bus info      : usb-3f980000.usb-1.5
        Driver version: 4.4.13
        Capabilities  : 0x85200001
                Video Capture
                Read/Write
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x05200001
                Video Capture
                Read/Write
                Streaming
                Extended Pix Format
Priority: 2
Video input : 0 (Composite: ok)
Video Standard = 0x000000ff
        PAL-B/B1/G/H/I/D/D1/K
Format Video Capture:
        Width/Height  : 720/576
        Pixel Format  : 'YUYV'
        Field         : Interlaced
        Bytes per Line: 1440
        Size Image    : 829440
        Colorspace    : Broadcast NTSC/PAL (SMPTE170M/ITU601)
        Flags         :
Streaming Parameters Video Capture:
        Frames per second: 25.000 (25/1)
        Read buffers     : 2

Hello
I posted my current v4l2 Settings here:

https://hyperion-project.org/t…uck-colors.257/#post-2206

The first command disables the chroma thing. Then you have to play around with saturation and chroma_gain to get a natural saturated image.
I also raised image brightness, makes Hyperion works better with darker colors for me.

Ah btw, you have to put these command into a file that starts up with linux every time since they dont get saved.

Hm, the controls are all missing:

pi@raspberrypi:~ $ v4l2-ctl --set-ctrl=chroma_agc=0
unknown control 'chroma_agc'

I run a curret raspbian lite image.

Addition: I don't have any controls:

pi@raspberrypi:~ $ v4l2-ctl -l
pi@raspberrypi:~ $ v4l2-ctl -L
pi@raspberrypi:~ $

But i can definitely grab the over-saturated screenshots with hypercon... Driver issue? I have no clue how to get the controls

Uhmm sorry I have no clue whats wrong. Its probably driver related I would say. I am using the STK grabber though. Someone with linux knowledge may be able to help.
I use Jessies Full version, not sure if that makes a diffrence.

Now i have tried: Using a full image instead of lite, compiling latest version of v4l-utils (1.10.1), updating to latest kernel... Nothing, no commands.

Perhaps ists hardeware related? I have the Fushicai UTV007 grabber. But without correct colors from the grabber, i think i can try calibrating hyperion forever...