Originally Posted by fhoech
It is not possible currently. Now that a HDR metadata passthrough is finally available in Windows and madVR, it's probably time to revisit this.
, what does the header of a 3D LUT need to look like for HDR metadata passthrough (as a side thought, I'm not even sure the distinction makes sense - the only difference between HDR mode on and off from a profiling point of view is how the display is setup, which is transparent to the profiler and any 3D LUT consumer, so I would assume the only option needed would be whether to pass HDR metadata or not)?
For the madVR option "convert HDR content to SDR by using an external 3dlut", the 3DLUT must have "Input_Transfer_Function PQ" in the header, I think, but no "Output_Transfer_Function" specified, or at least not set to "PQ". This tells madVR that this 3DLUT wants to get PQ data as input, and that the output of the 3DLUT requires the display to be in SDR mode to look right.
For the madVR option "process HDR content by using an external 3dlut", the 3DLUT must have both "Input_Transfer_Function PQ" and "Output_Transfer_Function PQ" in the header. This tells madVR that this 3DLUT wants to get PQ data as input, and that the 3dLUT output requires the display to be in HDR mode to look right.
Probably, when profiling the display, from your point of view it doesn't even matter which transfer curve the display is calibrated to, because you're measuring it, and it can be either gamma or PQ or something entirely different. It doesn't even matter, right? So from this point of view, it probably doesn't make much sense for you to specify the "Output_Transfer_Function". Rather you'd probably want to set it to something like "Output_Transfer_Function AsMeasured", or something like that. However, madVR needs to know into which mode (SDR vs HDR) it should switch the display, for the 3DLUT to produce correct results. So it needs to be written into the 3DLUT header.
We also added the option for users to use a non-profiled 3DLUT to do HDR processing. Such a 3DLUT does not actually involve measuring the display, but it simply converts PQ RGB data to Gamma RGB data. This is useful because your offline conversion might be slightly higher quality than what madVR calculates in realtime. Furthermore, the realtime pixel shader code is slower than running the data through a 3DLUT. So this approach makes sense.
Now imagine a user who has an HDR display, but no meter. He can't properly calibrate his display, but he might want to use DisplayCAL's high quality HDR processing capabilities to do tone mapping, because his display's tone mapping might have bad quality. So the user may want to let DisplayCAL convert the original HDR PQ data (e.g. 1000 nits DCI-P3) down to e.g. 120nits BT.709. But he might still want the display to activate its internal HDR mode, because in HDR mode it might run the backlight/lamp in "overdrive" mode to get more brightness etc. In this situation, the DisplayCAL 3DLUT gets PQ data as input, and should also still output PQ data, but the 3DLUT should perform some tone and gamut mapping, according to the user's wishes. So in this situation the 3DLUT should have "Output_Transfer_Function PQ" in the header.
To sum it all up: If you set "Output_Transfer_Function PQ", madVR will switch the display into HDR mode. Otherwise madVR will switch the display into SDR mode. The madVR option "convert HDR content to SDR by using an external 3dlut" requires "Output_Transfer_Function" to not be set, or at least not to PQ. The madVR option "process HDR content by using an external 3dlut" requires "Output_Transfer_Function" to be set to "PQ".
Hope all is clear now?