Joint Collaborative Team on Video Coding (jct-vc) of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11

3.8HDR (67)

(Consideration of this topic was chaired by GJS on Tuesday 10-20 at discussed Tue 20th 1730, but these contributions were GJS – not presented in detail except as commented otherwise, as some of this was outside the current focus or scope of JCT-VC. The contributions are – add notes – available for study.)

JCTVC-V0052 HDR-10 update [C. Fogg (MovieLabs)]

[abstract]The authors of this information document report that high dynamic range / wide colour gamut video content can, or has been exchanged between single-layer HEVC Main10 products. A description of the metadata and example settings for open source software encoders is provided.

Minor corrections to JCTVC-U0045 are included in this document. For reference, an updated version of U0045 (revision 3) is also attached to the JCTVC-V0052.zip archive.

TBP (or out of scope)

Clarification errata to U0045.

JCTVC-V0053 Best HDR/WCG video coding practices for Blu-rRay 3.0 [C. Fogg, J. Hellman (MovieLabs)]

[abstract]MovieLabs is publishing a "best practices" guide to authoring HDR/WCG content, with examples for Ultra HD Blu-ray format, at its website http://www.movielabs.com starting in October 2015. An excerpt is included in this document, JCTVC-V0053r1. A slide presentation with additional detail accompanies version 2 of the zip file archive associated with this document. An abridged version of the MovieLabs best-practice HDR workflows and coding practices are described in this document that recommends filters and encoding parameters that are said to meet Ultra HD Blu-ray requirements.

TBP (or out of scope)

This is an uUpdate to a workflow description and a discussion of tools. It includes comments on QP control and resampling filters.

JCTVC-V0055 Comments on Hybrid-Log Gamma (HLG) video transfer functions [C. Fogg (MovieLabs)]

[abstract]Two High Dynamic Range (HDR) video transfer functions based on the hybrid log gamma (HLG) formula standardized recently as ARIB 67 (JCTVC-U0032) were described. The first version described in that document (now documented as transfer_characteristics code point 18 in the latest HEVC version 3 draft, JCTVC-U1005) is limited to 1200 cd/m2 at unity. The second transfer function extendeds the first by combining a "system gamma" tone mapping step that effectively extends the range of the first transfer function to, for example, the 10,000 cd/m2 range of the SMPTE ST 2084 (PQ) transfer function (transfer_characteristics code point 16). The authors of this input document argue that the transfer function must supply information necessary to unambiguously translate each sample code level (1024 in the case of 10 bit depth) to intensity values that can be directly imported into systems having a colour space defined in terms of linear light.

TBP

The contribution dDiscusses hybrid log gamma, of which the ARIB scheme is a special case. It aAsserts that some additional data is needed for interpretation and display.

JCTVC-V0085 Comments on contribution V0055 [M. Naccari, A. Cotton (BBC)] [late]

This contribution provides comments and a reply to the points raised in document JCTVC-V0055. The contribution asserts that the other contribution contains an incorrect interpretation of the values associated with the hybrid log gamma (HLG), (ARIB STD-B67) OETF and describes a method to perform conversion from HLG to another colour space.[abstract]

TBP

It was asked Wwhat does the draft says about brightness for interpretation? A: Nothing. That question was not addressed in the contribution.

(Clarify notes.)
JCTVC-V0063 Information on HDR bitstream generation for Samsung SUHD TV(JS9500) [E. Alshina, Y. Park (Samsung)] [late]

[abstract]This information document presents a method to feed a HDR/WCG bitstream to a Samsung SUHD TV (JS9500) to see a HDR/WCG video on the commercial TV. This document explains how to generate a HDR/WCG bitstream that includes VUI and SEI messages from HM software and the open source HEVC encoder known as x265.

TBP

The contribution rReports on a bug in the HM software regarding the mastering display colour volume MDCV SEI message. Software action item: Check/fix this bug.

JCTVC-V0064 Clarifications on the semantics of CRI SEI message and its usage for HDR/WCG video compression [A. K. Ramasubramonian, J. Sole, D. Rusanovskyy, D. Bugdayci, S. Lee, M. Karczewicz (Qualcomm)]

(Consideration of this topic was chaired by GJS on Monday 06-18, 1430–1500.)

This contribution proposes two clarifications to the semantics of the colour remapping information (CRI) SEI message in HEVCv2. The clarifications are related to the input signal to the CRI SEI message and to the processing order indicated when more than one CRI SEI message is associated with a current picture. The document also describes how the CRI SEI message can be used as a range adjustment tool to improve the coding efficiency of HDR video content. It is argued that the suggested changes allow this type of application of the SEI message with no impact on its current usage.

In VCEG parent review it was said that defining a new meaning for an unforeseen use of an existing SEI message does not seem advisable. [Check fix this according to improved understanding reached later.]

Note that this contribution is partly an errata report.

It was commented that a sentence in the current specification text seems vague and potentially misleading, saying "The colour remapping information may be applied directly to the decoded sample values, regardless of whether they are in the luma and chroma domain or the RGB domain." The originator of the SEI message confirmed that this sentence seems poor and redundant and can just be removed.

It was commented that the definition of the mapping function that is to be applied may not be fully clear from the semantics of this SEI message. This may also be the case for the tone mapping SEI message. For example, it is not specified what the input value of 0 should be mapped to, if the first provided pivot point does not have an input value of 0.

In the discussion, the use of the function to map from an unknown domain into an identified domain was discussed, and this seemed to fall within the intent of the SEI message.

It was commented that the function definition assumes three inputs, but if the video is 4:2:0, there is no clear definition of the three input values to which to apply the mapping. The message is drafted to assume some (not specified) conversion to 4:4:4 prior to performing the mapping process.

Decision (BF): Clarify the semantics for the decoder to infer pivot points to the left and right as necessary, and remove the sentence quoted above, and conduct further study to determine whether further clarification is needed (e.g., the purpose of the ID). Prohibit the potential inference of indicating a cascading of remappings.