Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > HDTV / DVB / TiVo

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th July 2021, 22:04   #61  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,890
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.

Quote:
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.

Quote:
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 :-)
huhn is offline   Reply With Quote
Old 4th July 2021, 22:40   #62  |  Link
kasper93
MPC-HC Developer
 
Join Date: May 2010
Location: Poland
Posts: 586
Quote:
Originally Posted by huhn View Post
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.

Quote:
Originally Posted by huhn View Post
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.

Last edited by kasper93; 4th July 2021 at 23:05.
kasper93 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.