Requirement for OOTF adjustment

[simontWork]

There are a number of reasons why the OOTF of the video signal may need to be adjusted, including:

• For BT.709, there was no EOTF specified, so a number of values came in to use - this was limited by how a CRT worked - it had a limited brightness range above which the beam would defocus and a built in gamma of approximately 2.5 adjusted by a pre-correction and brightness and contrast control. Different values were in common use, for example the EBU used 2.35 in a dim reference environment at 100cd/m2, Apple used 1.96ish in a different viewing environment and I believe NABA favoured 2.6 (although can't find a reference for that). The value 2.4 was a compromise between the values in use in reference viewing environments on a 100cd/m2 monitor.
• Various systems exist for adjusting the OOTF for different viewing environments, for both HLG and PQ. There needs to be a mechanism for adjusting OOTF as the brightness of the image is changed to maintain artistic intent. (This is analogous to the different gammas in use for cinema and TV production prior to the publication of BT.1886)
• There are at least 3 methods for live HDR production currently in use, one which uses linear techniques, one which uses gamma-correction and one which uses a hybrid of the two. The -60 document can describe all three, so we will have an inconsistency between SMPTE specifications in the same suite.

Having re-read the document I think there's a relatively straightforwards fix that could be applied. For each Alternate Image, as well as Gain and Headroom, we could store a Gamma Modifier (γMi) where,

γMi- Gamma Modifier - an optional OOTF modifier value assigned to each Alternate Image which is used as a multiplier to the OOTF. Examples of usage for BT.709/BT.2020 and BT.2100 are given in Appendix A. When not present, the value shall be assumed to equal 1.0 (i.e. no modification of OOTF).

And then in Appendix A:

for BT.709 and BT.2020

E = EOTF (E') = E'^(2.40 x _γMi_)

for BT.2100 HLG

System_gamma = 1.2 x _γMi_
Lwhite can then be simply caluclated by applying the EOTF using the modified system gamma to a value of 0.75

[ronan-boitard]

I don’t believe the proposal addresses the OOTF adjustments.

• Appendix A.2 is about linearizing the image essence and rely on non-SMPTE ST 2094-50 parameters to perform this linearization. As such the linearization equations are described in other standard documents. I do not think this is the scope of this document to redefine how BT.709 and BT.2020 should be decoded .
• The alternate image parameters are about describing the tone mapping. This tone mapping is independent of viewing environment and target display physical nits as it is parametrized by the headroom so parameters of the alternate image should not impact the linearization process of Annex A.2.
• If the intent is to add a power value to the tone curve when tone mapping to a specific headroom, this power can be baked into the gain curve rather than added as an extra parameter.

[simontWork]

The tone mapping is not independent of the viewing environment. The eye adaptation state depends on the viewing conditions and hence, the required mapping depends on the viewing environment. The problem is caused as the defined viewing conditions are being ignored in the transform - BT.709 mastered at 100 cd/m2 is being mapped to 203 cd/m2 - this is not common practice in Europe and the UK.

At present there are a number of methods in use - but in common use by some major content producers is to have a gamma correction in SDR to HDR conversions and in HDR to SDR conversions to compensate for the different viewing conditions. Without the ability to replicate this, then the documented method can't replicate the workflows in use by major broadcasters and international sports producers.

[simontWork]

As an example, in the published OOTF for HLG or the new UHD Association ambient viewing specification, one can see the power function being adjusted to match different screen and ambient brightensses. This can also used (and in a number of major events, is used) when mapping between different brightness displays or video formats.

[simontWork]

Further to yesterday's discussion, I think there may have been a misunderstanding of the need for adjusting the OOTF. The requirement is needed when compositing in to the Gain Application Color Space.

The reason is that the process listed in the appendix is not taking in to account the different reference levels in the feeds, e.g. sRGB at 80, BT.709 (in accordance with BT.2035) at 100, 2100 at 203.

At present there are two methods in use, one is to stretch the luminance to 203 and monitor SDR on 203, the other is to keep monitoring SDR on 100 and apply a gamma adjustment when mapping the signal in to 203*.

The issue is that, without access to the second method, one cannot composite SDR with the same artistic look that's in use by some major sporting leagues. Logos, team crests, specified colours, archive content would all change in terms of brightness and saturation when compositing and that's unacceptable to rights holders. It also means that videos created using this method would look different to videos composited by a vision mixer.

This requires a relatively straight forwards fix by allowing gamma adaptation during the compositing process and I think needs to be at least mentioned in the appendix. Otherwise, we will have people implementing the exact maths given and being unable to use the result.

• technically they don't apply a gamma and scale, they use the relative nature of HLG and choose a suitable peak brightness so that the HDR reference white matches the SDR peak white, apply the gamma offset if there is one (there isn't for sRGB) and directly map the values in to the correct part of the HDR signal.

[swick]

At present there are two methods in use, one is to stretch the luminance to 203 and monitor SDR on 203, the other is to keep monitoring SDR on 100 and apply a gamma adjustment when mapping the signal in to 203*.

I have trouble understanding the argument. Can you explain this part a bit more detailed? I also have not heard of the "monitoring SDR" concept before.

[simontWork]

At present there are two methods in use, one is to stretch the luminance to 203 and monitor SDR on 203, the other is to keep monitoring SDR on 100 and apply a gamma adjustment when mapping the signal in to 203*.

I have trouble understanding the argument. Can you explain this part a bit more detailed? I also have not heard of the "monitoring SDR" concept before.

During live production, cameras are adjusted by looking at a waveform monitor and a video monitor. Traditionally, for HD the monitors used are aligned in accordance with ITU-R BT.2035 which places HD (SDR) diffuse white at 100 cd/m2.

When producing live HDR, most productions use a single-wokflow technique whereby the cameras output HDR, but are monitored via an HDR-SDR conversion. The same conversion is then used to create the SDR programme feed. You can then guarantee that the HD SDR programme will look good (this is, at present, still the main deliverable)

There are 2 broad methods - continue using monitors at 100 cd/m2 and apply a gamma adaptation when mapping the signal to the HDR signal range or change the SDR monitoring to 203 cd/m2 and apply a linear mapping. Both of these give different artistic looks and need different conversions to work correctly. (There's an annex in ITU-R BT.2408 that discusses this in depth)

Both methods are in use, so to be able to replicate both using this standard, the ability to apply a gamma adapted mapping is required.

[craigctodd]

"Traditionally, for HD the monitors used are aligned in accordance with ITU-R BT.2035 which places HD (SDR) diffuse white at 100 cd/m2."

The above is not correct. BT.2035 specifies that the 10-bit code value of 940 should be 100 cd/m2. The actual wording could have been better as it does say "Reference White" but then it qualifies the meaning of that term to be code value 940.
"Reference white (value 940) should correspond to 100 cd/m2 ..."
Note that this use of "reference white" is clarified as the code value for nominal V=1, and should not be taken to be the value of "diffuse white", which in other contexts may be defined as the code value produced by the spectrally neutral Lambertian reflector.

[digitaltvguy]

Because images that go through a gamma adaption stage will have a different "look", it would be valuable to show those images side-by-side (as they might be during compositing) so we all understand how the images will be affected. A number of us are preparing those images for evaluation.