Quote:
Originally Posted by Asmodian
I am not sure what you mean by "patterns are not HDR encoded", do you mean they do not go through madVR's HDR -> SDR conversion path? How would madTPG know HCFR was sending patches it should treat as HDR? I don't think madTPG looks for flags from software telling it HDR metadata, I don't think there are any standards around metadata attached to test patches so it would have to be something worked out between HCFR (Argyllcms) and madVR.
An option in madTPG to set the input HDR metadata, similar to how we can set the output metadata, would be cool. 
|
Your text in bold, that's what I meant and thought was implemented from the go since it comes from the same author. Viewing the PQ curve tells the whole story, can't tell how close it actually tracks from SDR luminance curve measures.
Quote:
Originally Posted by Manni
MadTPG suports HDR, at least with Calman. You simply have to specify the metadata for the content (max brightness etc) and the software indicates this to MadTPG and switches to HDR. This has been the case for a while. It’s only useful if calibrating in HDR (passthrough), not if you’re doing a conversion, in which case you want the display to be calibrated to sdr rec-709 or P3 or BT2020 with a power gamma (2.4 recommended) and you don’t need/want MadTPG to be in HDR mode.
HCFR should be supporting this, best would be to ask Zoyd on AVS in the HCFR thread.
|
I asked, no reply so far. Why do you think 2.4 gamma is recommended, i.e. why does it matter any if we can select the gamma a display is calibrated to in MadVR?