HDR ST2084

[Stuart.p]

HDR with Photo and 32bit preview to true HDR monitor Asus PA32UCX. To output HDR from AP, you need to enable HDR On in WIn 10 to get the EDID working for HDR so the 32bit HDR selection is active in AP. But, what WIndows does is it seems to then create an ST2084 (PQ) to 2.2gamma EOTF to the monitor so SDR content looks correct. It then relies on the HDR content to be tagged correctly for the ST2084 EOTF to work. In AP, the HDR becomes active but with a 2.2gamma. I need to work in ST2084 for VFX/cinema/HDR for video. So it seems AP does not send a tag correctly to Windows to pick up the profile selection in colour settings. I have tried loading a ST2084 profile in both AP and Windows default etc and it always remains a 2.2gamma, not ST2084 EOTF. I have tried the OCIO config with ACES, but again it seems it is interacting with the ST2084 to 2.2G that Windows is applying.

Any ideas please. HDR is not usable if the EOTF is wrong, regardless of getting the peak luminance to 1000nit and the primaries correct.

[Mark Ingram]

Hi @Stuart.p, thanks for your comments. I wrote the HDR output functionality for Windows. Unfortunately due to the current COVID situation, I'm at home, away from my HDR monitor (ASUS ROG-PG27UQ), so diagnosing this may be a little tricky right now.

You're right that Windows performs a gamma 2.2 transform for SDR content (so the user doesn't notice a change to non-HDR content when enabling the option). When you click "Enable HDR" in 32-bit Preview in Affinity Photo you should notice the document goes darker due to Windows no longer applying this transform (now that the output is HDR). At this point we're outputting HDR with linear gamma, and depending on your choice of Display Transform in 32-Bit Preview, transforming it via ICC / None / OCIO before it hits the screen.

Have you correctly set the Monitor reference white value? Could you record a video or some screenshots demonstrating what you're seeing?

[Stuart.p]

Hi Mark

Thanks for responding to this and I understand the difficulties at this time. I'm very impressed with the colour management work you have done since I last saw AP a few years ago.  What you have said in that the image should go darker or to the ST2084 transform is what I would have expected. But this doesn't happen. With Win10 HDR activated the Asus PA32 is definitely in PQ mode (you need this to get EDID working with HDR to get the ENABLE HDR active). EDID was double checked with HDFury Integral2. To see what was actually happening I created an image stack of test patches from Lightspace (https://www.lightillusion.com/) and measured these with my CR100 probe in a  manual mode that Lightspace has. This showed that the response from the patches within the AP window had a 2.2gamma. I could get 1000nit, so it was "HDR" sort of and the Enable HDR was active, but not a ST2084 EOTF. I have tried various icc profiles such as a ST2084, Null (linear), and also unmanaged. The OCIO REC2020 ST2084 1000Nits was more linear and the luminance very low, quite strange. The other thing to consider is that monitors such as the PA32UCX have 2 calibration slots and other high end HDR monitors that may be used won't output EDID but you still want the HDR capability to be engaged, so having the capability to manually set this should be available. Please see two images, both showing the response of the patches in HDR one against (black line) 2.2gamma (1) and the other against an ST2084 P3 1Knit (2). Please note again the monitor was set to a St2084 EOTF (PQ) response and this was verified through measuring with Lightspace - ASUS_PA32_PQ. I'm not sure about the ROG-PG27 and its HDR mode but I will try and get some details from ASUS.

I have also attached two profiles created with Displaycal synthetic profile creater (Argyllcms) with one for pure 10K PQ 2020 and the other a PQ 1Knit_P3.

Stay safe.

PQ_1K_NIT_P3_D65.icm

PQ_10K_2020_D65.icc

 

[Mark Ingram]

That's interesting @Stuart.p, thanks for those graphs.

As I mentioned earlier, I don't have hardware to check here at home, so I've just gone through the code again. To enable the "Enable HDR" checkbox, your output device must has told us it can receive Gamma 2084, with BT.2020 primaries. Then at render time we tell Windows that we are going to output colours in the scRGB colour space (linear gamma, BT.709 primaries), and it's my understanding that Windows should take care of the conversion from scRGB to the output device. 

Thanks for taking the time to respond, I'd be interested in talking to you further about this particular issue, and any other requirements or issues you have for our HDR support.