HLG processing for good picture on SDR monitor

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

Originally Posted by huhn

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.

Originally Posted by huhn

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/mad...yllcms.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.