Transforms and Tone Mapping for Display

Apologies, Just noticed this got stuck in the W3C mail system.
Hi all,
In the last call, a question was raised about how we can easily convert between SDR and HDR signal formats and how we can tone-map signals when the user selects a diffuse white level which means target display does not have the overhead required to correctly draw the signal.
The conversion from SDR to HDR have been covered previously, but code examples are included here for completeness with additional notes to help implement other conversions.
I’ve also added a section on tone-mapping for different target display (e..g. the end user selects a diffuse white level of 500 cd/m2 for display on a 1000 cd/m2 display).
In these examples and those on Pierre’s webpage (https://www.sandflow.com/public/tone-mapping/index.html), the code shown is for a minimal viable product – i.e. it works, but can be optimised by the web developer.  For example, in the HDR to SDR example on Pierre’s web-page a simple hard clipping is used to limit the image to the target gamut.  This will create hue shifts so a more complex, hue-invariant scaling may be preferable.  Similarly, highlight compression or expansion may be preferable when converting to and from HDR.
In all cases, it is important that the functions can correctly deal with negative numbers by reflecting the algorithms about zero.  See section 5.3 in ITU-R BT.2408-4 relating to negative transfer functions in format conversions.
Conversion from sRGB to HLG

  1.  Linearize using the sRGB EOTF
  2.  Convert from sRGB colour space to rec2100-hlg colour space (defined in BT.2020)
  3.  Scale pixel values
  4.  Apply HLG Inverse EOTF to convert to HLG from Pseudo-Display Light with Lw = 302 cd/m2
Note: As rec2100-hlg is a relative format, the luminance of the virtual monitor used for mathematical transforms can be chosen to be any level. In this transform it is chosen to be 302 cd/m2 so that the brightness of diffuse white matches the standardised diffuse white of sRGB (80 cd/m2). Using the extended range gamma formula in footnote 2 of BT.2100, this also (by chance) sets the system gamma to be 1.0, and hence, HLG Inverse OOTF to be unity. The SrgbtoHlgScaler value represents the normalised scene-light of diffuse white and is calculated to be 0.26496256042100724… by taking the inverse OETF of 0.75, the rec2100-hlg diffuse white level.  The inverse OOTF is included for completeness.

def convertExtendedSRGBtoREC2100HLG(R, G, B):

    #Static values



    SrgbtoHlgScaler = 0.26496256042100724

    systemGamma = 1.0

    #Linearise sRGB using EOTF



    (r1, g1, b1) = srgb_eotf(R, G, B)

    #Convert colour space from sRGB to that defined in BT.2020



    (r2, g2, b2) = matrixSRGBtoXYZ(matrixXYZtoBT2020(r1, g1, b1))

    #Scale signal such that sRGB peak white matches diffuse white in target



    r3 = SrgbtoHlgScaler * r2



    g3 = SrgbtoHlgScaler * g2



    b3 = SrgbtoHlgScaler * b2

    #Apply HLG Inverse EOTF using a pseudo display with peak white 302cd/m2

    #This consists of the inverse HLG OOTF followed by the HLG OETF



    (r4, g4, b4) = hlg_inverse_ootf(r3, g3, b3, systemGamma)

    (r5, g5, b5) = hlg_oetf (r4, g4, b4)



    return (r5, g5, b5)

Further conversions

Similar functions can be created by using a virtual display with a different peak luminance, to convert between other video formats.

For example, to convert between ITU-R BT.709 (with a ITU-R BT.2035 standardised luminance at 100cd/m2) and HLG, the virtual HLG display is set so that its diffuse white luminance level is 100 cd/m2.  That requires an HLG nominal peak luminance of 400.2 cd/m2.  To do this, the above code can be modified to use bt709_eotf and systemGamma = 1.04

To convert from either sRGB or BT.709 to PQ, either a similar function (with different scaling) can be created to target PQ or the image can be converted to HLG and then converted using the ITU’s published, visually lossless conversion. (As shown in Pierre’s test webpage)

Tone-mapping for Display

In a recent call, it was mentioned that the diffuse white may be scaled by the end user (or the operating system) and that, depending on the attached screen, some form of tone-mapping may need to be applied.

In order to ensure the artistic intent of the portrayal of shadows and midtones with such a scaling, from ITU-R BT.2390, we see that there’s a gamma adjustment required in the OOTF.  It’s important that either the operating system (preferably) or browser handles this or the look of an image or video will change.  Could this be added to the discussion for the upcoming calls?

This table shows some example changes required:
[cid:image002.png@01D9A84F.5262A6E0]
--
Simon Thompson MEng CEng MIET
Senior R&D Engineer
BBC Research and Development