HLG processing for good picture on SDR monitor

[VictorLS]

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.
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]

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]

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.


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.
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]

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

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.

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]

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.

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.

And, if we use "disable calibration controls for this display" [...] the source gamut is used without correction ?Yes.
And about conversion itself.
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 :)

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]

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.
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/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/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.php?p=1930343#post1930343

[kasper93]

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)
https://thumbs2.imgbox.com/66/d1/SomlKBFU_t.png (https://images2.imgbox.com/66/d1/SomlKBFU_o.png) https://thumbs2.imgbox.com/21/b8/bCoPz6PT_t.png (https://images2.imgbox.com/21/b8/bCoPz6PT_o.png)

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/madvr-argyllcms.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.

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/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/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.

[huhn]

first of my calibration setting on the new Tv where ignored because of 2 possible reasons windows 11 been a windows OS or this TV is so broken that it creates new identifies that the current available one in the settings is an old one so it never applies. maybe both.

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.

the point is both output SDR. HDR10 with pixelshader and HLG with no special treatment. but in one case madVR assumes BT709 and does a conversation and in the other it doesn't even through the display characteristics didn't change both are SDR to a unknown display one time it's bt 709 and one type is just doesn't touch the image.
just because on has a HDR pipeline does not excuse the different behaviour. the HDR10 file is just to proof that it assumes in this case bt709.

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.
well the gamma was supposed to be added to the 3D LUT so madVR can read it and act accordingly. but well same for clipping btb and wtw... argyll CMS 3D LUT don't support the input of these values because of timing "reasons" that don't apply to a PC and want them clipped and madshi wanted them to just not read them or something what so ever still buggy.

bt 1886 is generally messy :-)

[kasper93]

the point is both output SDR. HDR10 with pixelshader and HLG with no special treatment. but in one case madVR assumes BT709 and does a conversation and in the other it doesn't even through the display characteristics didn't change both are SDR to a unknown display one time it's bt 709 and one type is just doesn't touch the image.
just because on has a HDR pipeline does not excuse the different behaviour. the HDR10 file is just to proof that it assumes in this case bt709.

Ok, I get what you mean. But it is the other way around. madVR still doesn't "assume" anything about target display if you have "disable calibration control". Just happens to be that output of "pixel shader" tone mapping is BT.709 internally (by default/design) after tone mapping, which happens to much output display. You can still correct this by changing "display calibration" settings.

I can actually see why this is confusing from high level point of view. HDR processing is not consistent with SDR one, mostly because HDR is a big bulk of processing, which is not really compatible fully with "calibraton" tab currently.

Nevertheless my original point was that in order to properly watch SDR BT.2020 (or HLG) you need to set calibration for a display. I get that HDR processing overwrites some os the original SDR pipeline logic, but in pure SDR mode it has to be done.

well the gamma was supposed to be added to the 3D LUT so madVR can read it and act accordingly.

This is off topic here, we could move to https://www.avsforum.com/threads/madvr-argyllcms.1471169 if you would like to continue discussion. I even have posted there not long ago about my issues with current setup. Indeed expected input gamma could be embedded in 3dlut so madVR could convert before. We could also have a more complex list of 3dluts to support common transfer functions. Currently when selecting 3dlut transfer function is ignored and essentially this means you need to manual change 3dlut file when needed.