V2 flesh tones

[sonicblue]

Poll question for V2 owners: do you feel the flesh tones have a bit of an orangey glow to them?

I'm asking as I've been doing a lot of A-B comparison between it and my other boxes, and observe that there is a bit more orange in the flesh tones compared to my other boxes.

However, I'm not sure which one is "correct", since all three of my boxes each have different flesh tones, despite identical picture settings on each input. For example, my Tivo has distinctly more green in the flesh tones, while my TV's internal tuner doesn't have that, and my T2 seems to have more red than the tuner.

The V2 has its own colour saturation control which can be reduced, however that reduces saturation of all colours; flesh tones remain the same in relation to other colours. Also the default saturation setting (128) does appear to be the correct one according to an RGB ramp test pattern, as decreasing it below 128 starts to cause the brightest most saturated colours to drop below digital value 235. i.e the saturation control appears to be correctly aligned at its default value of 128.

This leads me to speculate about the V2's "auto flesh" setting. I've tried to get an observable result from manipulating this control, but can't. I conclude that it doesn't work, or hasn't been set up properly to do anything. The fact it hasn't been set up properly leads me to wonder whether it's defaulting to on rather than off. What makes this theory even more compelling to me is that my TV has its own flesh tone control which can boost flesh tones to look exactly like they do from the V2. Since the V2 already has a few other bugs relating to its HDMI output, it seems plausible.

However my TV has far from reference colours, so I'm more interested to hear what other V2 owners think.

[MrQuade]

Too subjective without using proper calibration equipment.

What "looks right" may be way off the mark in terms of accuracy.

I do know that the U4 looks very much more saturated then any of the other models. The V2 seems comparable to me to the T series though.

[sonicblue]

Too subjective without using proper calibration equipment.

Yep, I was thinking of getting a HDMI capture card and checking the pixel values in Photoshop.

[sonicblue]

This appears to be another Hisilicon bug; cycling the HDMI HDR type setting back and forth (eg. off > HLG > off) results in less orangey skin tones:

https://i1.lensdump.com/i/jXBfxi.png

The images were taken via openwebif screenshot which doesn't capture the colour accurately, however it does capture differences in colour.

It seems we only need to cycle the HDR setting once at system startup to get the less orangey skin tones to stick, but further testing will be needed to confirm this to a high degree of certainty.

Cycling HDR mode also appears to fix the other colour bug after playing a 4k media file (item 8 in "v2 various issues" thread).

[MrQuade]

Not that it affects the colour balance, but what's the reason for using 4:4:4 chroma?

[sonicblue]

Not that it affects the colour balance, but what's the reason for using 4:4:4 chroma?

The 4:4:4 and 4:2:2 modes are the only ones that output YCbCr.

After some more testing, this issue appears to be related to the auto flesh setting in video enhancements.

I observe that after resetting the bug via cycling HDR mode, and then setting proc/stb/vmpeg/0/pep_auto_flesh to its default setting of 0 (off), the orange skin tones are re-instated.

The reason it gets instated in the first place is because VideoEnhancement explicitly sets auto flesh to 0 at launch (and also when opening the video enhancements GUI since those config values have notifiers on them which get called in the screen's __init__)

Therefore a better workaround might be to just remove the auto flesh setting from the Video Enhancement module.

I will need to do more testing as there may be other enhancement settings that may re-instantiate it.

[MrQuade]

The 4:4:4 and 4:2:2 modes are the only ones that output YCbCr.

Interesting. Is that related to your earlier observation about rgb being output in Auto mode? As in, when 4:2:0 is used, it instead uses rgb?

[sonicblue]

The 4:4:4 and 4:2:2 modes are the only ones that output YCbCr.

Interesting. Is that related to your earlier observation about rgb being output in Auto mode? As in, when 4:2:0 is used, it instead uses rgb?

4:2:0 outputs RGB as far as I can tell...I'm using an inference based on a picture setting on my TV that only becomes available when the signal is RGB.

The V2's conversion from YCbCr > RGB appears to be faulty, but I don't have hard proof of that, only inferences and subjective observations.

Also my TV isn't 4k and yours is, so you'd be using 2160p mode and may be getting different results.

eg. "9. Colour space reverts to RGB when setting HDMI output mode to 2160p" so even though you've selected 444/422 you might still be getting RGB.

edit: also beware the separate colour space setting in video enhancements as that one gets applied after the one in AV Settings (they both control the same proc value though, but it can cause confusion) ...I removed that redundant setting for my upcoming patch.

[sonicblue]

After more testing it seems that disabling auto flesh from VideoEnhancement.py is sufficient.

i.e /proc/stb/vmpeg/0/pep_auto_flesh must be completely left alone and never have a value written to it.

Steps to reproduce:

1. In Video Enhancement set auto flesh to 0
2. In AV Settings cycle HDMI HDR type from off > HLG > off
3. Pause on a scene with flesh tones
4. From telnet echo 0 > /proc/stb/vmpeg/0/pep_auto_flesh and observe flesh tones get brighter when you hit enter
5. Reset the bug with echo hlg > /proc/stb/video/hdmi_hdrtype; sleep 0.1; echo none > /proc/stb/video/hdmi_hdrtype (note: video content must be playing, not paused, in order for this to work)

[IanSav]

Hi,

Is any of this testing and development happening with the current manufacturer drivers (the current Beyonwiz drivers are quite old)? All this effort will have to be repeated when the new drivers are implemented on the Beyonwiz image.

Regards,
Ian.

[sonicblue]

Is any of this testing and development happening with the current manufacturer drivers (the current Beyonwiz drivers are quite old)?

If you're asking me, the answer is yes as I've already implemented my code and see no benefit to not releasing it. I've written my code in a semi-modular way that doesn't make it too difficult to go back and remove individual fixes after the new driver.

If you're asking official Beyonwiz devs, then obviously I can't speak for them, but I'd agree it doesn't make sense to invest time until the driver is updated.

Personally I'm not optimistic the new driver will fix the majority of issues, but would love to be proven wrong. I'm just glad we can modify the source code so easily unlike eg. Fetch

Have seen the changes in settings for audio and video. Confirmed that the 4K Auto setting locks the refresh rate at 50hz – what were they thinking?

Fetch colours are noticeably washed out and dull if the video resolution settings are on Auto or 4K, but they're fine if I set it back to 1080P.

[IanSav]

Hi Sonicblue,

I was talking to you. I think it would probably be worth taking MrQuade's advice and trying out the latest version of openATV to see what changes the new drivers have implemented. If there are still issues then they could / should be pursued via Captain to see if the drivers can be fixed for all images.

I don't understand the pointers to the Fetch box.

Regards,
Ian.

[sonicblue]

I think it would probably be worth taking MrQuade's advice and trying out the latest version of openATV to see what changes the new drivers have implemented. If there are still issues then they could / should be pursued via Captain to see if the drivers can be fixed for all images.

I'd be willing to do that if I could get a second V2 box for testing purposes, as we need our primary V2 for daily duties.

I don't understand the pointers to the Fetch box.

To show how lucky we are to be able to modify our source code to fix our issues while the poor FetchTV people can't and are stuck with similar issues.

[IanSav]

Hi Sonicblue,

To show how lucky we are to be able to modify our source code to fix our issues while the poor FetchTV people can't and are stuck with similar issues.

Trust me, I am well aware of the configurability of Enigma2. I actively develop code for openATV, OpenPLi and OpenViX. My code is also used in a number of other derivative images. I was also a Beyonwiz developer.

Regards,
Ian.

[sonicblue]

i.e /proc/stb/vmpeg/0/pep_auto_flesh must be completely left alone and never have a value written to it.

This got me thinking, what if there are other picture quality improvements to be had by preventing the other pep settings from being written to. I tried disabling them all and noticed the image quality was different. Narrowed it down to the two noise reduction settings: pep_block_noise_reduction and pep_mosquito_noise_reduction. It appears the driver default is a noise reduction = on setting, as setting them to 0 results in more texture details. Just putting this out there.

edit: to clarify, the VideoEnhancement module will automatically set them to 0 at boot up if you have them set to 0 in the menu, so you don't need to do anything, except avoid disabling them in VideoEnhancement.py.