Monitor luminance calculation with EOTF

[HXhester]

Hi,

I'm trying to compare the brightness between the following SDR and HDR monitors (Asus ProArt Display PA32UCG)

SDR monitor: color space sRGB, piece-wise sRGB EOTF, max brightness 140 cd/m2
HDR monitor: color space BT2020, PQ EOTF

The test pattern from http://www.lagom.nl/lcd-test/contrast.php

After ocio conversion calculation, I got the following input in 10-bit on the first 8 blocks.
An SDR example:

srgb_signal = [0, 0.003910, 0.010753, 0.021505, 0.040078, 0.065494, 0.094819, 0.124145]
hdr_signal = [0.020528, 0.044966, 0.069404, 0.092864, 0.116325, 0.142717, 0.169110, 0.193548]

sdr_display=colour.models.eotf_sRGB(srgb_signal) * 140
hdr_display=colour.models.eotf_BT2100_PQ(hdr_signal)

The outputs in cd/m2 I got from the calculation above is

SDR	0	0.04236842	0.11651858	0.23302632	0.43428173	0.76672415	1.29325057	1.98615616
HDR	0.00913142	0.04727111	0.12929194	0.26760842	0.48688263	0.86567141	1.43400504	2.1861963

However, visually SDR monitor is obviously darker than the HDR monitor.
Is the calculation of the monitor luminance correct?
If correct what could be the reason why the monitors look obviously different?

Thanks!

[KelSolaar]

Hello,

So the display, if calibrated correctly, should undo exactly the encoding with the inverse EOTF you imposed to the signal. Put another way, whatever you put in should be exactly what you get out. The main difference is that with SDR, you indeed need to multiply the input signal by the display peak luminance and with PQ, because it is absolute, you do not need to do anything.

Without having access to the hardware it is tricky to find out what is going on. How did you determine the peak luminance in SDR?

I would recommend using some patterns to verify that the EOTF track in both modes. For example, you can encode the attached file with the inverse EOTF, display it at 100% and verify that the checkerboard patterns blend with their background:

EOTF__HDR_Linear__HD1080.exr.zip

[HXhester]

Hi @KelSolaar,

Thank you for your reply!

Since the source image is encoded with a game engine through white paper nit definition and ocio, it's not exactly the inverse EOTF of the display.
If the signal in the script below is the encoded result, and the displays are setting the corresponding eotf, then the calculation of the final luminance is correct right?

srgb_signal = [0, 0.003910, 0.010753, 0.021505, 0.040078, 0.065494, 0.094819, 0.124145]
hdr_signal = [0.020528, 0.044966, 0.069404, 0.092864, 0.116325, 0.142717, 0.169110, 0.193548]

sdr_display=colour.models.eotf_sRGB(srgb_signal) * 140
hdr_display=colour.models.eotf_BT2100_PQ(hdr_signal)

How did you determine the peak luminance in SDR?

The asus monitor comes with a colorimeter and a color management software, which can measure the luminance value when the input (255,255,255) white is given.

I would recommend using some patterns to verify that the EOTF track in both modes. For example, you can encode the attached file with the inverse EOTF, display it at 100% and verify that the checkerboard patterns blend with their background:

Thank you for the test pattern. I'll test it out! May I ask what is the theory behind the this checkerboard test pattern?

[KevinJW]

Generally these patterns work because they have some solid areas of colour and then some alternative set of pixel values in another area, in the case of an equally sized checkerboard you typically have half the pixels at one intensity and half at another, when the pixels are close together and subtend a small enough angle then visually an optical system can blur the intensities enough to make the checkerboard look one intensity, i.e. average them, in the case of 'fully off' and 'fully om', then this should equate to close to half the peak luminance (as black is typically not exactly zero you get a slightly higher value). This assumes you display the image 1:1 zoom pixel for pixel with no filtering, and that pixels have equal areas etc.

If the system is fully linear with no EOTF then you can calculate all these averages for a range of checkerboard values and use that to set the colours of the solid areas, that is what the EXR contains. If you view on such a conceptual device then the checkerboards blend in to their surroundings.

When you go to real life display and view the EXR on a screen which does not have a linear response, e.g. where it has a "Gamma 2.2" EOTF, or a "PQ" EOTF, then this no longer holds because the relationship is broken by the non-linear response of the display ... the solution is to then encode the pixels with the inverse of the display response, so that this transformation cancels out the display one, and you get back the optical effect.

Light out = EOTF( EOTF^-1( pixel ) )

If you encode the image with different expected display inverses, then you can simply display different images encoded with the different inverses and look for the one that the effect works the best on - this strongly hints at the display's EOTF, most error will occur near black pixels as depending on the real display there maybe an effective minimum display output depending on the display technology used as well as reflected light from the room the display is in etc which elevate above 0 Nits, you can repeat the procedure encoding with different offset assumptions to determine the pixel values of the solid areas assuming non-zero black levels and guess at the size of this effect, Depending on how closely you need to know the EOTF this may not be needed.