HLG processing for good picture on SDR monitor

[videoh]

Originally Posted by VictorLS

it's some strange...
Here's sample 20200926-153844_RTL UHD Austria.ts (232 MB) https://yadi.sk/d/_4Oo1_awZEQr4g

What is strange about it? It's HLG and so will play "OK" as SDR.

BTW, sorry to say but your English is borderline understandable. Try full sentences, each expressing a single coherent thought.

[VictorLS]

Originally Posted by videoh

What is strange about it? It's HLG and so will play "OK" as SDR

You can just compare 20190511-152944_RTL UHD_flag.ts (67MB) https://yadi.sk/i/985DVw34OHQrrA I've uploaded in this thread before with present 20200926-153844_RTL UHD Austria.ts (232 MB) https://yadi.sk/d/_4Oo1_awZEQr4g (20190511-130113_ARENA HD_flag.ts (38MB) https://yadi.sk/i/HiuZ5Rb2RKkc0g SDR for control) with EVR (not EVR-CP to avoid any post-processing in renderer) in MPC-HC and if you have good monitor and eyes I believe you'll see difference as minimum in red color in top left corner
Btw today's F1 race translation fully prove I was right - in some seconds before adv someone was switching from non-HLG to HLG and vise versa - I hope to cut and upload an example(s) in days.

Originally Posted by videoh

BTW, sorry to say but your English is borderline understandable.

You're welcome but i.e. when I gave just link on this thread to a smart Russian guy Iron_Butterfly (I even didn't new he's shader writer that time) he fully understand me and at first correct not working MPC-VR's correction_hlg.hlsl shader (so modern versions of MPC-BE do HLGtoSDR with i.e. EVR-CP but red becomes some rose due to wrong and non-adjustable constants) and then wrote new working shader I successfully use in app SmartDVB or MPC-HC. Here's shader with my constant 1000.0&300.0 Convert HLG to SDR.hlsl (6 КБ) https://yadi.sk/d/4Ugay1550LPg1Q - in original was 1000.0&80.0
Even nevcairiel well understand I ask him but he implement in LAV Video Decoder useful thing (like NVIDIA CUVID h265 10bit decoding or switchable CUVID DXVA processing for playing "broken" streams in Win7x64 with hardware accelerations without artifacts on nVIDIA videocards) in years but not all frame decoding - I agree he calls simpler "skipping" (this function is in ffmpeg) he don't want to implement despite of it's very easy to do, proved by Aleksoid1978 and MPC Video Decoder.

Originally Posted by videoh

Try full sentences, each expressing a single coherent thought.

It's hard to write hard enough things with simple sentences
If you or someone can't understand whole sentence try to read without () and then in () and summarize them in your brains because I believe each word I write is important

[videoh]

Originally Posted by VictorLS

I believe each word I write is important.

That's reassuring. Thank you.

[VictorLS]

Here's a sample I promised to upload 20200927-141013_RTL UHD Austria_.ts (108 MB) https://yadi.sk/i/FInnqG3BbHt5SQ - when watching with EVR (so without processing) between 5 and 6 seconds red Ferrari becomes some orange (so video beginning from 6th second becomes ordinary HLG so shader and i.e. EVR-CP become necessary to watch Ferrari in ~ normal color on SDR - so non-BT.2020 - monitor).
One more thing - rectangle STRECKENINFO GP VON RUSSLAND without shader is some orange too but see letters carefully - with EVR and in VLC they are looking well but with shader+EVR-CP and in mpv letters with visible artifacts.
PS. On my PC EVR-CP some times stutters while playing RTL UHD but VLC with OpenGL always fluent - can someone confirm that?

[VictorLS]

Originally Posted by VictorLS

Here's a sample I promised to upload

Here's one more vise versa sample 20200927-151917_RTL UHD Austria_.ts (58 MB) https://yadi.sk/i/n2vgJY5IZGg_Fg
without HLG processing at 8th second i.e. orange adv banner "Emirates FLY BETTER" becomes red.

[VictorLS]

I've watched 20200927-141013_RTL UHD Austria_.ts and 20200927-151917_RTL UHD Austria_.ts on Samsung QLED 43" supported even AV1 4K 60fps playing and it shows wrong overcontrasted and oversaturated video while non-HLG in that files and normal video when HLG in same videos.
PS. Letters on STRECKENINFO GP VON RUSSLAND looks like in VLC so good enough (but not ideal).

Originally Posted by VictorLS

Here's two shaders with my constants 1000.0&300.0 and 150.0&0.5 https://transfiles.ru/l99ql - in original was 1000.0&80.0 and 100.0&0.5

Btw I've reupload that two shaders to more permanent place Shaders.7z (2 KB) https://yadi.sk/d/-DUfaqlY6LfxtA

[VictorLS]

MPC Video Renderer (MPC-VR) v0.4.10.1542 https://yadi.sk/d/X0EVMKP4TcmnHQ/Old/0.4.10 (0.4.10.1542 is last version let turn HLG processing off in MPC-VR and well use HLGtoSDR shader instead) shows HLG on SDR even better than shaders on my own.
With MPC Video Renderer colors are less saturated but nearer to SDR.

[VictorLS]

New shader from smart Russian guy Iron_Butterfly HLG-BT2100toSRGB.hlsl (3 KB) https://yadi.sk/d/ExnEkJR-sgms1g

[VictorLS]

Just tried Daum PotPlayer 210127 https://daumpotplayer.com/download/ and it can show HLG such as HLG-BT2100toSRGB.hlsl in MPC-HC with internal in PotPlayer Direct3D9 Video Renderer
With Default.dsf skin HLG processing can be easily switched on/off by pressing HDR in a bottom while playing HLG file like 20190526-164153_RTL UHD.ts (687 MB) https://yadi.sk/d/6_vZCglWkP1xxw

[kasper93]

Originally Posted by VictorLS

Due to huhn's "madVR doesn't support HLG"
HLGw/oProcessing (undersaturated and undercontrasted):

Regardless of HLG it looks like you are using madVR wrong. Desaturation comes form BT.2020, not HLG. I figured I will clear one thing for all of you guys.

madVR does not convert gamut to your display if you do not ask it to. You have to specify you display "calibration" parameters. Even if it is not calibrated, BT.709@2.2 is probably very close to your display Or better use 3DLUT...

And this apply to all non bt.709 content, not only HLG. Here is comparison with correct and incorrect configuration.



This board is not a best example, but you can clearly see the difference when BT.2020 is converted to BT.709... With EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.

[VictorLS]

Originally Posted by kasper93

madVR does not convert gamut to your display if you do not ask it to. You have to specify you display "calibration" parameters. Even if it is not calibrated, BT.709@2.2 is probably very close to your display Or better use 3DLUT...

Because I haven't alternative of madVR (it permanently some stutters on my old and slow computer, EVR and MPC-VR shows same files fluently) I began to search 3DLUT for ~ correct HLGtoSDR conversion but didn't find it that time - your research is great.

Originally Posted by kasper93

This board is not a best example, but you can clearly see the difference when BT.2020 is converted to BT.709... With EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.

If you read (you can translate if don't understand Russian language) and download files I've uploaded from there https://forum.ixbt.com/topic.cgi?id=73:5256:3663#3663 until now you'll see 20210611-232433_TRT 4K.ts isn't HLG and don't need any color conversion (but it's 25 Hz, so SVP is appreciated), 20210612-164807_TRT 4K.ts without HLGtoSDR conversion (in i.e. MPC-VR 0.4.10.1542) looks washed out on SDR monitor, 20210613-161108_TRT 4K.ts without HLGtoSDR conversion looks better than 20210612-164807_TRT 4K.ts but with HLGtoSDR conversion looks better than without one - then I've done some screenshots madVRvsMPC-VRcomparison.7z (18 MB) https://disk.yandex.ru/d/ur54NnTmgdFzKA where MPC-VR's HLGtoSDR conversion is much more accurate than madVR and latest MPC-VR5 without conversion (~ the same result) I guess mean showing SDR layer of HLG video on SDR monitor.

[Balling]

>Desaturation comes form BT.2020, not HLG.

No. Neither BT.2020 ncl matrix, nor BT.2020 primaries can really do that. It is the PQ or HLG transfer (which is what HDR is) that affects the picture. That can be very simply checked in mpv that can override matrix, transfer, range and primaries.

>EURO2020 HLG content looks ok, as it was designed to looks reasonably well on SDR devices.

Actually HLG was designed to look well on SDR devices.

[VictorLS]

Originally Posted by Balling

Actually HLG was designed to look well on SDR devices.

Theretically so but long time HLG was with ugly colors (especially red was looked as orange) on i.e. my SDR monitor.

[kasper93]

Originally Posted by Balling

No. Neither BT.2020 ncl matrix, nor BT.2020 primaries can really do that. It is the PQ or HLG transfer (which is what HDR is) that affects the picture.

It is actually pretty simple concept. If you have wide-gammut video and map it to RGB as is and display it on narrow-gammut display it will be under saturated. The same when you display narrow-gammut content on wide-gammut display, it will be overstarated. That's why wide-gammut monitors have sRGB clamping/emulation (whatever you want to call it) mode.

Originally Posted by Balling

That can be very simply checked in mpv that can override matrix, transfer, range and primaries.

Of course you can! Try `mvp --target-prim=bt.2020` on sRGB display, with any video. Result will be understated.

This is exactly what happens with madVR if you don't tell it display parameters explicitly it will expect display to be "compatible" with source content and push it "as-is". Hence you need to tell madVR that your display is for example BT.709 (close to sRGB) so that other gammuts are converted accordingly.

For example mpv does that automatically, as it expect most people to have sRGB displays.

(auto mode) Disable any adaptation, except for atypical color spaces. Specifically, wide/unusual gamuts get automatically adapted to BT.709, while standard gamut (i.e. BT.601 and BT.709) content is not touched.

Originally Posted by Balling

Actually HLG was designed to look well on SDR devices.

Yes, this is what I said.

[huhn]

actually you have bug at your hands here.

by design madVR is supposed to do bt 709 gamma 2.2 output with "disable calibration controls for this display" outside of HDR output mode.
so this should be an automated case.
a bt2020 gamma or a bt601 gamma file should be automatically converted to bt 709 with gamma 2.2 for some reason it's not doing this for HLG files.

i will report that to him.

[kasper93]

Originally Posted by huhn

actually you have bug at your hands here.

by design madVR is supposed to do bt 709 gamma 2.2 output with "disable calibration controls for this display" outside of HDR output mode.

Where did you get this information? I'm almost certain madshi said (at one point) that there is no gamut conversion unless you request madVR to do so. And it checks out with my observation.

bt.709 2.2 output is expected after HDR pixel shader tone mapping. But since HLG is not supported it is treated like normal BT.2020

Originally Posted by huhn

so this should be an automated case.
a bt2020 gamma or a bt601 gamma file should be automatically converted to bt 709 with gamma 2.2 for some reason it's not doing this for HLG files.

I will say it third time. HLG is not a factor here... I have SDR bt.2020 file and it behaves exactly the same.

Originally Posted by huhn

i will report that to him.

Please let me know where. Because this change is not that obvious and I'd like to be in loop

[huhn]

he talk about it years ago it still kinda here as information: https://forum.doom9.org/showthread.php?t=171787

disable calibration controls for this display: The display is assumed to have a BT.709 gamut with a pure power gamma of 2.2 (probably).

and we also got the information that some correction are not done.

the new beta version can detect HLG that was a necessary change after i reported that it is treated as HDR10+ (or something like that) with the internal MPC-BE decoder lav filter at the time didn't send the HLG meta data to madVR

what so ever with a new beta (133 or 134) with HLG it totally ignored the setting could be bt 2020, bt 709 or "no calibration" i get the same image with every source. actually all calibrations setting with my current build are totally ignored so i can't do a proper test for now and i can't report it.
bugs are reported here: http://bugs.madshi.net/my_view_page.php?refresh=true

i will soon try the release version and the newest beta.

[kasper93]

Originally Posted by huhn

he talk about it years ago it still kinda here as information: https://forum.doom9.org/showthread.php?t=171787

and we also got the information that some correction are not done.

Asmodian is not madshi, is he? madshi has proven himself over the years to be very strict and organized about those things. I would never expect "disable calibration controls" to do hidden assumptions and do implicit conversions when there is explicit option "this display is calibrated" to set properties of the display.

Also to not make empty assumptions I found the posts that I remembered.

Originally Posted by madshi

Yes.

And about conversion itself.

Originally Posted by madshi

With SDR BT.2020 content and "this display is already calibrated to BT.709", madVR converts the gamut from BT.2020 to BT.709, but colors are simply clipped in the most simple way to BT.709, which is not optimal. With SDR content and "this display is already calibrated to BT.2020", no processing is necessary/done.

With HDR BT.2020 content, it's almost the same. However, the BT.2020 -> BT.709 gamut mapping is performed in much higher quality.

It's on my to do list to perform the higher quality processing also for SDR gamut down-conversions.

Optimal or not it is still better than trying to display bt.2020 without adaptation. Also if you have a 3DLUT for your monitor you will get best result

Originally Posted by huhn

the new beta version can detect HLG that was a necessary change after i reported that it is treated as HDR10+ (or something like that) with the internal MPC-BE decoder lav filter at the time didn't send the HLG meta data to madVR

what so ever with a new beta (133 or 134) with HLG it totally ignored the setting could be bt 2020, bt 709 or "no calibration" i get the same image with every source. actually all calibrations setting with my current build are totally ignored so i can't do a proper test for now and i can't report it.

I can't comment on that, I don't see any of your issues. I'm using latest LAV and madVR b135, HLG content is processed as SDR one. As I would expect if it is not supported.

[huhn]

Originally Posted by kasper93

Asmodian is not madshi, is he? madshi has proven himself over the years to be very strict and organized about those things. I would never expect "disable calibration controls" to do hidden assumptions and do implicit conversions when there is explicit option "this display is calibrated" to set properties of the display.

this is not based on empty assumption it'S more based on tests and Asmodian don't writes these parts down if he didn't test them.
and i just tested live version 0.92.17 and it clearly behaviours as usual it assumes BT 709. madVR has to work out of the box the far majority of user doesn't know what either bt 709 nor bt 2020 are and that'S absolutely ok.

Optimal or not it is still better than trying to display bt.2020 without adaptation. Also if you have a 3DLUT for your monitor you will get best result

been using 3D LUT for years now hell my meter get's so old i think about replacing it just because it could drift to far.

I can't comment on that, I don't see any of your issues. I'm using latest LAV and madVR b135, HLG content is processed as SDR one. As I would expect if it is not supported.

it's only one system and clearly needs more testing but i have to setup and calibrate a new Tv and it's taking a long time so i can't do a proper test right now.

as sad before my other system with the live none beta version behaviours like the past and assumes BT 709 test with HDR 10 and proper BT 2020 flag test file i just found. https://drive.google.com/file/d/1Ic9...rSw6y1mYv/edit
HLG is not assumed to output bt709 this is inconsistent behaviour if tone mapped or not the displays output characteristic hasn't changed when both output SDR.

the new BETA version have a change for HLG because madVR got nuts when HLG meta was send to it which lav filter doesn't do "yet" with madVR.
was great fun: https://forum.doom9.org/showthread.p...43#post1930343

[kasper93]

Originally Posted by huhn

this is not based on empty assumption it'S more based on tests and Asmodian don't writes these parts down if he didn't test them.
and i just tested live version 0.92.17 and it clearly behaviours as usual it assumes BT 709. madVR has to work out of the box the far majority of user doesn't know what either bt 709 nor bt 2020 are and that'S absolutely ok.

I get that, but I'm trying to prove to you that it is wrong. madshi said that and it is consistent with my observations.
SDR BT.2020 with stable 0.92.17 (same behavior as with beta)


What you might be referring to is how HDR pipeline works in madVR. If content is detected as HDR it goes through "hdr" tone-mapping settings. And if it goes through "pixel shader" tone map the internal output is indeed bt.709 2.2 which then goes to "calibration" settings and gamma settings. Note that if you use other option in "hdr" settings it will not go through calibration.

But for SDR and currently HLG it doesn't go through HDR pipeline, hence there is no BT.709 conversion unless selected in "calibration" settings.

Bottom line is, if you want madVR to ouptut proper colorspace for your display, set display parameters in "calibration" page, else it will not do that in some cases.

Also madVR 3DLUT selection after HDR pixel shader tone mapping is slightly broken, around 2017 there was discussion about that, but it gone nowhere https://www.avsforum.com/threads/mad...llcms.1471169/ but I digress, not related to our current discussion. But if you use HDR tone-mapping and SDR 3DLUT it has to be 2.2 gamma instead rec.1886... it is little bit mess currently.

Originally Posted by huhn

as sad before my other system with the live none beta version behaviours like the past and assumes BT 709 test with HDR 10 and proper BT 2020 flag test file i just found. https://drive.google.com/file/d/1Ic9...rSw6y1mYv/edit
HLG is not assumed to output bt709 this is inconsistent behaviour if tone mapped or not the displays output characteristic hasn't changed when both output SDR.

Sorry, I don't understand. This file have PQ transfer function, not HLG. It is detected as HDR by madVR with "unknown properties" (in fact in both stable and beta), but it is completely different case than we are discussing in this thread. This file is treated as HDR.