Announcement

Collapse
No announcement yet.

Understanding the Science of HDR: The MPEG White paper repository....

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Understanding the Science of HDR: The MPEG White paper repository....

    http://mpeg.chiariglione.org/standards/exploration/high-dynamic-range-and-wide-colour-gamut-content-distribution

    Good place to start.:-)

    INTERNATIONAL ORGANISATION FOR STANDARDISATION
    ORGANISATION INTERNATIONALE DE NORMALISATION
    ISO/IEC JTC1/SC29/WG11
    CODING OF MOVING PICTURES AND AUDIO

    ISO/IEC JTC1/SC29/WG11 MPEG2014/N15029
    October 2014, Strasbourg, France

    Source: Requirements
    Status: Approved
    Title: Draft Requirements and Explorations for HDR and WCG Content Distribution
    Editor(s): Ajay Luthra, Edouard François, Walt Husak

    Abstract
    Current television systems provide Standard Dynamic Range (SDR), supporting a range of brightness that is significantly smaller than the range that the human eye is capable of discerning. Similarly, current video systems do not support the wide range of colours that the human eye can perceive. Future television and other video distribution environments are expected to give a viewing experience that is closer to a real life experience, to provide the user with a stronger sense of “being there”. This document provides requirements and use cases for higher dynamic ranges and wider colour gamuts than are typically supported today. MPEG has initiated an effort to determine if any changes to the current MPEG standards are needed to meet these requirements.
    1. Introduction
    Current video distribution environments provide Standard Dynamic Range (SDR), typically supporting a range of brightness of around 0.1 to 100 cd/m2 (often referred to as “nits”). This range is significantly smaller than the range encountered in real life. For example, a light bulb can have more than 10,000 cd/m2, surfaces lit in the sunlight can have brightness upwards of hundreds of thousands of cd/m2, while the night sky can be 0.005 cd/m2 or lower.
    One of the key goals of Ultra High Definition Television (UHDTV) is to provide a user a sense of “being there” and “reality” [1]. Increasing resolution alone may not be sufficient to fully attain this goal, without also creating, capturing and displaying content that has much higher peak brightness and much larger contrast values than today’s TV.  In addition, a greater sense of reality requires rendering colours that are richer than those provided by the colour gamuts commonly used today, e.g. BT.709 [2]. Thus, new content will not only have orders of magnitude greater brightness and contrast, but also significantly wider colour gamut (e.g. BT.2020 [3] or possibly even wider in the future).
    It is not clear at this stage if the existing MPEG video coding standards are able to efficiently support the needs of future content distribution environments with higher dynamic range and wide colour gamut. MPEG will initiate the effort to see if any changes are needed in current MPEG standards to meet these requirements. This document pulls together the needs of future high quality content distribution systems. In this process, a more complete picture that involves the end-to-end chain, from video generation to final destination is considered. That chain includes the stages of creation, capture, intermediate (mezzanine) level distribution, and final distribution to the home (see Annex A).
    2. Definitions
    2.1. Dynamic Range
    Overall, the dynamic range of a scene can be described as the ratio of the maximum light intensity to the minimum light intensity [1]. In digital cameras, the most commonly used unit for measuring dynamic range is in terms of f-stop, which describes total light range by powers of 2. The current ad hoc use of the term f-stop, refers to the following dynamic ranges:
    • 10 f-stops = a difference of 210 = 1024: 1 contrast ratio.
    • 14 f-stops = a difference of 214 = 16,384: 1 contrast ratio.
    • 16 f-stops = a difference of 216 = 65,536: 1 contrast ratio.
    100,000:1 is normally regarded as approximately the range that the eye can see in a scene with no adaptation.
    • 20 f-stops = a difference of 220 = 1,048,576: 1 contrast ratio.
    1,000,000:1 is normally regarded as approximately the range that the eye can see in a scene with minimal (no noticeable) adaptation.
    In the categorization of dynamic ranges, the following definitions are typical and will be used in the present document:
    • Standard Dynamic Range (SDR) is ≤ 10 f-stops
    • Enhanced Dynamic Range (EDR) is > 10 f-stops and ≤ 16 f-stops
    • High Dynamic Range (HDR) is > 16 f-stops
    2.2. Colour Gamut
    Colour gamut, also known as colour space, describes the range of colours that can be represented in a particular circumstance, such as the colour space that humans may perceive or the subset of colours supported by a certain output device or video distribution system [5].  Historically, the colour gamut for content in Standard Definition is defined in ITU-R BT.601 [4] and that for content in High Definition is defined in ITU-R BT.709 [2].
    With the proliferation of new display technologies (e.g. OLED and quantum dot) and UHDTV, the industry recognized the need to include colours beyond those available in BT.709 [6]-[9]. Colour gamut larger than BT.709 is referred as Wide Colour Gamut (WCG). Examples of wide colour gamut include ITU-R BT.2020 [3] and Digital Cinema P3.

    2.3. Scene Referred and Display Referred pictures
    Scene Referred pictures are linearly related to the real luminance values captured from the original scene. In a Scene Referred pipeline the processed image is not directly viewable.
    Display Referred values correspond to how an image is rendered on a specific display. The pixel sample values in the captured scene or associated graded sequence may subsequently need to be modified to match the capabilities of the actual display. For example, content represented in BT.2020 colour space would need to be modified to be consistent with the capabilities of a BT.709 display. Similarly, the luminance/luma values in the captured or graded scene may need to be modified to match the dynamic range and the peak luminance capabilities of the actual display.
    3. Video Level Considerations and Requirements
    3.1. Dynamic Range
    The dynamic range of the content and the display should be decoupled.
    The achievable and desired brightness and dynamic ranges of various displays may be significantly different from those of the capturing and creating devices. For example, a content creation system may be able to create or capture content with a contrast of 1,000,000:1, to allow a cinematographer or artist to select a sub-range from a wider range to draw out desired detail in post-production grading, but it may be neither desirable nor feasible to have displays with that wider range. Some display dependent mapping of the content’s dynamic range may therefore be required. That mapping may be done at the encoding end or the receiving end. This may also be a function of the distribution mechanism, e.g. point-to-point communication or broadcasting.
    The standard should allow for content to be adapted to the target display’s dynamic range.  This may occur through the signalling of metadata, but solutions are not limited to this approach.  Specific limits may be defined in the context of profiles and levels. The standard should be able to migrate from where the content capturing and displaying ranges are today to where they will be in the medium to the long term.
    3.2. Content Input Types and Bit Depths
    The content may be distributed to a consumer electronically (i.e. via a broadcasting or other network connection) or physically (on optical media, flash memory, magnetic storage, etc.).  The types of content to be supported include:

    • Camera captured video
    • Still images
    • Computer generated content (e.g. animation)
    • High contrast security-camera content
    The standard shall support integer (8, 10, 12, and 16 bits) and half-floating point (IEEE 754) input video data formats. One or several internal compressed integer formats may be defined. As the standard is likely to operate internally using fixed point arithmetic, mechanisms should be provided that would allow an encoder to map floating point formats to the appropriate integer formats that the encoder considers to be the most efficient.
    A mechanism to indicate the mapping used to create the input integer values provided to an encoder should be provided.
    A mechanism should be provided that would allow a receiver to map the decoded video format to the one needed for display.
    https://twitter.com/CINERAMAX<br /><br />https://WALLSCREEN-SKYLOUNGES.COM

  • #2
    3.3. Transfer Function (TF)
    Input video to the encoder may or may not have a coding Transfer Function (TF) applied to it. This applies to both integer and floating point representations. Many systems map large input dynamic range by using a transfer function and a code level mapping from a linear, floating point representation, to a non-linear fixed point representation with limited precision. Some examples are illustrated in Annex B.
    New transfer functions and mapping processes are likely to be necessary to support such larger ranges. Mechanisms to map the input coding TF (linear or non-linear) to another function, which may be more efficient from a coding efficiency point of view or more appropriate from display point of view, could also be considered. The receiver may apply the appropriate inverse coding TF for the signal to be displayed.
    Luma and Chroma may have different TFs.
    The standard should support multiple coding TFs, as needed.
    3.4. Colour Sampling and Formats
    The standard shall support 4:2:0, 4:2:2 and 4:4:4 chroma formats. Chroma sub-sampling and the domain in which it is performed may have a visual quality and coding efficiency impact and should be studied.
    3.5. Colour Spaces
    The standard should support multiple colour spaces. Key colour spaces of interest include (but are not limited to):
    • CIE 1931 XYZ
    • Recommendation ITU-R BT.2020
    • DCI-P3 (SMPTE ST 428-1:2006)
    • Recommendation ITU-R BT.709
    • CIE Luv (CIE 1976)
    Enhanced and High Dynamic Range (EDR and HDR) can be combined with any of the supported colour spaces.  The standard should allow signalling of metadata to assist in the conversion of the bit-stream colour space to a display colour space. The impact of compression noise and the interaction of the compression noise with these mapping schemes should be studied. More generally, the impact of potential interactions between the transfer functions, colour space conversions, chroma sub/up-sampling, and compression should be studied.
    3.6. Spatial Resolutions
    The standard should focus on a set of rectangular picture formats that would include all commonly used picture sizes. Key spatial resolutions of interest include (but are not limited to):
    • HD: 1920 × 1080
    • UHD-1: 3840 × 2160
    • UHD-2: 7680 x 4320
    3.7. Frame Rates
    The currently typical frame rates of 24, 25, 30, 50, and 60 fps shall be supported, in addition to the anticipated future frame rates of 100 and 120 fps. The standard should support commonly used non-integer variants of frame rates (e.g. approximately 29.97 fps).
    3.8. Compression Performance and Visual Quality
    Appropriate methods of objectively and subjectively measuring compression efficiency and visual quality should be developed. The impact of compression noise and the interaction of the compression noise with various dynamic range mapping schemes should be studied.
    Visually lossless compression should be supported.
    The changes that may allow the HEVC standard to compress EDR, HDR, and WCG video more efficiently than what can be done with the current version of HEVC, can be put in two categories:
    1. Normative modifications, involving the addition of new coding tools
    2. Non-normative modifications, possibly including new metadata, new entries in SEI and VUI, non-normative adjustment of HEVC encoder, and pre- and post-processing.
    Normative changes will be justified only if a significant improvement in performance is achieved; in the single layer design, the collection of all the possible new normative tools should result in average coding efficiency improvement of 15 to 20% or higher over the anchors.
    3.9. Multiple Generations of Encoding/Transcoding
    The quality of picture should not degrade significantly as it goes through multiple generations of encoding.
    In studios, re-encoding is typically done as a part of video processing. In the consumer space, content may be transcoded for further distribution in home or outside the home. In a head end, content may be transcoded to multiple different bit rates and resolutions for Adaptive Bit Rate streaming using, for example, MPEG-DASH.
    3.10. Picture processing
    The quality of picture should not degrade significantly as it goes through different kinds of picture processing such as frame rate conversion, de-noising, chroma keying.
    3.11. Overlay processing
    The overlay of graphics should not degrade the quality of the content. The overlay may include logos, closed captioning or other data, and may be of different dynamic range. The version of the standard that is used in the studios should be such that various special effects (for example, chroma keying, page turns, etc.) are feasible, after multiple encoding and decoding generations, without significant loss in the quality.
    Different content with different dynamic ranges and/or colour spaces may be combined.
    3.12. Backward and Forward Compatibility
    As the content creation, capturing, and display technologies are continuing to evolve, it is important to have a standard that does not put undue burden on today’s devices but which also provides backward compatibility with them as the new technology gets developed and deployed.
    Also, many times it is desirable that new systems are capable of properly decoding and displaying signals compliant with existing HEVC standards. This is referred as Forward compatibility. It includes supporting one or more mechanisms to convert SDR to EDR or HDR as well as BT.709 to WCG.
    Backward and forward compatibility should be supported.
    Rendering compatibility with displays of different capabilities could be considered.
    3.12.1. Scalability
    Scalable video coding approach (see below) could be considered as one possible means to provide backward and forward compatibility.  The use of appropriate metadata (see below) is another possible approach. Scalability could also be used in combination with metadata. It is recognized that there may also be a need for a non-backwards compatible option if the removal of the need to maintain backward compatibility results in a significant improvement of performance. Following examples of scalability options provide various backward compatibility choices. One or more scalabilities may also be combined.
    3.12.1.1. Temporal Scalability
    MPEG video compression allows 2 or more layers or sub-layers with different frame rates in integer multiples, for example 60 Hz and 120 Hz. The standard should support, if desired, means for each temporal layer to be able to preserve cinematographer and director motion rendering intent.
    3.12.1.2. Colour space (gamut) Scalability (CGS)
    Colour gamut scalability (CGS) could be used to achieve compatibility and inter-operability between systems that support different colour spaces and to provide migration paths from narrow to wide colour gamut. Inter-layer prediction methods that predict values in an enhancement layer colour space from values in a base layer colour space could be considered.
    3.12.1.3. SDR to EDR and HDR Scalability
    Scalability could also be used to achieve compatibility and inter-operability between systems that support different dynamic ranges and to provide migration paths from SDR to EDR and HDR.  Some systems may use different frame rates, different colour gamut and different dynamic range for the SDR and HDR layers. SDR to EDR and HDR scalability may also be combined with CGS.
    3.12.1.4. Bit Depth Scalability ? (TBD)
    TBD. Backwards compatibility with decoders with lower bit-depth (8- or 10-bits) could be considered.
    3.12.2. Metadata
    Another possible manner of achieving backward and forward compatibility is by including additional metadata within a single layer to allow mapping, e.g. from HDR to SDR or WCG to BT.709 and vice versa.
    Metadata may also include information added by the content publisher to describe the content or to guide post-processing steps to be applied before delivery or display. The content publisher may optionally provide metadata to describe the colour space of the reference display that the content was mastered on. The metadata may refer by name to a predefined display or consist of the relevant parameters for a general display model (for example, colour primaries, white point, peak luminance, and black level).
    Optionally, to aid in the conversion of content for delivery to a display with a different colour volume, a standardized set of title-specific conversion metadata may be provided by the content publisher. As an example, this metadata might be composed of mathematical operations (such as a 3x3 matrix) in conjunction with 1D or 3D Look-Up Tables.
    The metadata should allow a feasible implementation of real-time decoding and post processing within the computational and memory power constraints that are available to devices at the consumer electronics level for the B2C use case.
    SEI and VUI entries may, for example, also include various transfer functions and colour space related information.
    3.13. Complexity
    The complexity should allow for feasible implementation of encoders and decoders within the constraints of the available technology at the expected time of usage. It should be capable of trading off complexity, compression efficiency and visual quality, by having:
    • One or more operating points with similar complexity compared to HEVC v1 and v2 but with better visual quality,
    • One or more operating points with increased complexity that provide a commensurate increase in visual quality.
    The complexity of the metadata and of the processes using this metadata should be studied.
    Note: Complexity includes power consumption, computational power, memory bandwidth etc.
    3.14. Profiles and Levels
    Profiles and Levels should be considered to define appropriate subsets of the standard, in order to meet the needs of the target applications.
    4. System Level Considerations
    System level standards should specify efficient and easy ways to carry the bitstreams over widely used protocols and networks. The compressed video layers will be transported using MPEG-2 Transport Streams, MPEG-DASH and various Internet Protocols.
    System level standards should specify efficient and easy ways to store the bitstreams in widely used file formats (e.g. ISO base media file format).
    5. References
    [1] ITU-R BT.2246-2 (2012), “The present state of ultra-high definition television”, http://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2246-2-2012-PDF-E.pdf
    [2] ITU-R BT.709-5 (2002), “Parameter values for the HDTV standards for production and international programme exchange”,
    https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.pdf
    [3] ITU-R BT.2020 (2012), “Parameter Values for ultra-high definition television systems for production and internal programme exchange”,
    http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-0-201208-I!!PDF-E.pdf
    [4] ITU-R BT.601-7 (2011), “Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios”,
    https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf
    [5] Erik Reinhard, Greg Ward, Sumanta Pattanaik and Paul Debevec, “High Dynamic Range Imaging”, Morgan Kaufmann Publishers, 2005
    [6] CIE (1931). Commission Internationale de l'Eclairage proceedings, 1931. Cambridge: Cambridge University Press.
    [7] Wikipedia: CIE 1931 color space, http://en.wikipedia.org/wiki/CIE_1931_color_space
    [8] Wikipedia: CIELUV, http://en.wikipedia.org/wiki/CIE_L*u*v*_color_space
    [9] CIE, “Colorimetry - Part 5: CIE 1976 L*u*v* Colour Space and u', v' Uniform Chromaticity Scale Diagram”, ISO 11664-5:2009(E) / CIE S 014-5/E:2009, http://www.cie.co.at/index.php?i_ca_id=721
    https://twitter.com/CINERAMAX<br /><br />https://WALLSCREEN-SKYLOUNGES.COM

    Comment


    • #3
      INTERNATIONAL ORGANISATION FOR STANDARDISATION
      ORGANISATION INTERNATIONALE DE NORMALISATION
      ISO/IEC JTC1/SC29/WG11
      CODING OF MOVING PICTURES AND AUDIO

      ISO/IEC JTC1/SC29/WG11 MPEG2014/N14549
      July 2014, Sapporo, Japan

      Source: Requirements
      Purpose: Approved
      Title: Exploration Experiments for HDR and Wide Gamut Content Distribution
      Editor(s): Ajay Luthra, Edouard François, Walt Husak, Alexis Tourapis, Touradj Ebrahimi


      Exploratory Experiments (EE)
      1. EE1 – HDR/WCG signal representation and coding
      Chair: Alexis Tourapis
      Goals:
      • Determine whether there are non-normative (to the codec) processes that would allow us to improve upon the already defined anchors
      o Tentative tools to be evaluated (with different combinations)
       Color Transforms
       Down/Up-sampling
       Transfer Functions
      o Both mathematically and experimentally
      • Provide information about the performance of HEVC Main 10 on its suitability of encoding HDR content
      Description/Experiments:
      To evaluate the above, we need to perform the following encoding tests:
      • Transfer function experiments (more could be added)
      o Dolby PQ-10K (anchor)
      o Philips optimized at 5K (PH-5K) and 10K cd/m2
      (two options, extrapolation vs parameter based)
      o Technicolor G-Log (m33773)
      • Color space experiments
      o Y’u’v’ (PQ for Y’)
      o Y’u”v” (PQ and PH-10K)
      o Y’CbCr
      o Adaptive Color Transforms
      • Down/up-sampling experiments
      (two stage: conversion only, followed by encoding of “n-best” solutions)
      o Alias Cancellation filters (Y’CbCr)
      o Linear vs. non-linear space for up/down-sampling (Y’CbCr)
      o Shorter filters, possibly avoid negative taps?
      o 2 tap for YCbCr and Y’u’v’
      o Adaptive downsampling/upsampling (see m32222)
      • Other solutions could also be investigated if proposed in any of the above
      Comments/Issues
      • As defined the number of combinations may be “forbidding”. We should determine, as soon as possible, which combinations could be used, using possibly a hierarchical approach (to be determined).
      • Preparing subjective tests takes considerable time. It is suggested that at least 3 weeks are necessary to prepare the content, while the test should not be excessive. Tests should be prepared before this timeline (to be determined).
      • Subjective verification of one or more test vectors determined as best is likely to be performed by Dolby, Technicolor, and EPFL. If verified, then ultimate best (based on the existing HEVC specification) will determine the new anchor.
      • Need a tool for PQ-YUV back to linear space OpenEXR files.
      • Can we integrate the format conversion workflow with the HM?

      2. EE2 – Subjective Test methodology
      Chairs: Walt Husak, Touradj Ebrahimi
      Goals:
      • To characterize and evaluate the visual quality of the decompressed video sequences on various displays that will be available in 2015
      • To compare the performance (coding efficiency) of various video coding algorithms via subjective tests

      Formal Viewing Tests:
      o In addition, there is interest in using Side by Side for visual testing as well, in case of using one single HDR display.

      Informal Viewing Tests:
      o Side by side
       Same motion direction on the two sides
       appropriate separation between the two sides

      Other information
      o 2 or more training sequences are required for the viewing tests.
      o The tests are based on 4 stimuli to make the visual comparisons.

      3. EE3 – Objective Test Methods
      Chair: Edouard Francois
      The scope of this EE is to select from a pool of existing objective metrics one or more metrics to assist in evaluating submitted proposals.
      Different objective distortion metrics are commonly used for SDR such as PSNR or SSIM. Unfortunately, most of these metrics are suitable for SDR, but may be not usable as is for HDR. This experiment aims at identifying distortion metrics that are relevant to evaluate the performance of HDR video coding solutions.
      The proposed approach for this EE is to proceed as follows:
      • identify a number of potentially relevant distortion metrics 
      • run different codecs (or codec settings) at different operational points for a set of test sequences
      • set-up some visual tests and measure related metrics
      • analyze the data to check how much correlation exists between visual metrics and distortion metrics

      The work plan until the next MPEG meeting of October 2014 is defined as follows:

      • Initial visual tests
      o Visual tests will be done by EPFL.
      o EPFL will provide the results of the visual tests to the MPEG HDR/WCG AhG group.
      o EPFL will also provide the analysis about the correlation between the measured perceptual scores and the objective metrics computed between the source and test (coded) sequences.
      o The tests will be done using the SIM2 display.

      o Timeline (CET based):
       September 1st : Edouard will send Touradj the anchors sequences.
      • using the MPEG ftp site used for anchors & exploration work.
      o The ftp site will be given by Jens
       September 22: EPFL provides the results to AhG chairs
      • MOS scores, confidence intervals
       September 24: selected content made available by the AhG chairs to the group
      • Address of the ftp site where results are stored
      • People interested to get the results should contact the AhG chairs.
      • Template for reporting objective measures will also be provided by EPFL
       October 8: proponents of objective metrics provide their results (objective scores) to Touradj
       October 15: EPFL provides results of the analysis

      • Sequences
      o The tests will be made using the 5 Technicolor sequences (Seine, Market3, FireEater2, Tibul2, Balloon)
      o In addition, the sequences Lux and Typewriter should be added
       The sequences to be provided by Alexis to Edouard by August 15
      o Possibly 2 more sequences (from Stem and Telescope) could be added
       The sequences to be provided by Chad to Edouard by August 15

      o EPFL will select the training sequences among the provided test sequences
      o The sequences will be made available at the following ftp website:
       The ftp site will be given by Jens

      • Codec configurations
      o The coding chain as defined for the generation of the Main10, 4:2:0 anchors provided at the Sapporo meeting will be used.
       1 version of the codec used, with YCbCr color space
      o For Balloon sequence, one lower point around 1 Mbps will be added.
      o The uncompressed version plus three compressed versions (the 3 lower bitrates) for each sequence will be provided (on September 1, cf timeline above).
      o Later on, the work can be possibly continued by considering another codec (for instance HEVC Main 10 using YDzDx color space) and other evaluation methodologies.

      • Formats sequences
      o The format of the sequences for the derivation of the objective metrics will be 4:4:4 RGB BT.709, openEXR (uncompressed, no tiles, …)

      • Objective metrics to be evaluated
      o A set of metrics will be evaluated in priority. Any participant can bring additional data, for example VDP2.
      o The considered metrics are:
       PSNR Y’, Cb, Cr 4:4:4 in PQ-TF (applied on R, G and B) 16b domain
      • Option X, Y, Z can be also considered
      • A Single measure for the 3 components will also be derived as:
      o MSE = (MSEY+MSECb+MSECr)/3
      o Same for X, Y, Z
       deltaE2000 or PSNR_deltaE2000 – peak 65504
      • which white point Yn value ?
      • difference reference luminance for white point value will be tested: 100, 1000, 5000 nits
      o possible references from Walt
       mPSNR
       a software will be provided implementing these different metrics, by Jacob on September 15, 2014 – to be validated
      • Jacob to provide the initial sw version with mPSNR implemented
      • Alexis to provide openEXR input/output
      https://twitter.com/CINERAMAX<br /><br />https://WALLSCREEN-SKYLOUNGES.COM

      Comment


      • #4
        3. EE3 – Objective Test Methods
        Chair: Edouard Francois
        The scope of this EE is to select from a pool of existing objective metrics one or more metrics to assist in evaluating submitted proposals.
        Different objective distortion metrics are commonly used for SDR such as PSNR or SSIM. Unfortunately, most of these metrics are suitable for SDR, but may be not usable as is for HDR. This experiment aims at identifying distortion metrics that are relevant to evaluate the performance of HDR video coding solutions.
        The proposed approach for this EE is to proceed as follows:
        • identify a number of potentially relevant distortion metrics 
        • run different codecs (or codec settings) at different operational points for a set of test sequences
        • set-up some visual tests and measure related metrics
        • analyze the data to check how much correlation exists between visual metrics and distortion metrics

        The work plan until the next MPEG meeting of October 2014 is defined as follows:

        • Initial visual tests
        o Visual tests will be done by EPFL.
        o EPFL will provide the results of the visual tests to the MPEG HDR/WCG AhG group.
        o EPFL will also provide the analysis about the correlation between the measured perceptual scores and the objective metrics computed between the source and test (coded) sequences.
        o The tests will be done using the SIM2 display.

        o Timeline (CET based):
         September 1st : Edouard will send Touradj the anchors sequences.
        • using the MPEG ftp site used for anchors & exploration work.
        o The ftp site will be given by Jens
         September 22: EPFL provides the results to AhG chairs
        • MOS scores, confidence intervals
         September 24: selected content made available by the AhG chairs to the group
        • Address of the ftp site where results are stored
        • People interested to get the results should contact the AhG chairs.
        • Template for reporting objective measures will also be provided by EPFL
         October 8: proponents of objective metrics provide their results (objective scores) to Touradj
         October 15: EPFL provides results of the analysis

        • Sequences
        o The tests will be made using the 5 Technicolor sequences (Seine, Market3, FireEater2, Tibul2, Balloon)
        o In addition, the sequences Lux and Typewriter should be added
         The sequences to be provided by Alexis to Edouard by August 15
        o Possibly 2 more sequences (from Stem and Telescope) could be added
         The sequences to be provided by Chad to Edouard by August 15

        o EPFL will select the training sequences among the provided test sequences
        o The sequences will be made available at the following ftp website:
         The ftp site will be given by Jens

        • Codec configurations
        o The coding chain as defined for the generation of the Main10, 4:2:0 anchors provided at the Sapporo meeting will be used.
         1 version of the codec used, with YCbCr color space
        o For Balloon sequence, one lower point around 1 Mbps will be added.
        o The uncompressed version plus three compressed versions (the 3 lower bitrates) for each sequence will be provided (on September 1, cf timeline above).
        o Later on, the work can be possibly continued by considering another codec (for instance HEVC Main 10 using YDzDx color space) and other evaluation methodologies.

        • Formats sequences
        o The format of the sequences for the derivation of the objective metrics will be 4:4:4 RGB BT.709, openEXR (uncompressed, no tiles, …)

        • Objective metrics to be evaluated
        o A set of metrics will be evaluated in priority. Any participant can bring additional data, for example VDP2.
        o The considered metrics are:
         PSNR Y’, Cb, Cr 4:4:4 in PQ-TF (applied on R, G and B) 16b domain
        • Option X, Y, Z can be also considered
        • A Single measure for the 3 components will also be derived as:
        o MSE = (MSEY+MSECb+MSECr)/3
        o Same for X, Y, Z
         deltaE2000 or PSNR_deltaE2000 – peak 65504
        • which white point Yn value ?
        • difference reference luminance for white point value will be tested: 100, 1000, 5000 nits
        o possible references from Walt
         mPSNR
         a software will be provided implementing these different metrics, by Jacob on September 15, 2014 – to be validated
        • Jacob to provide the initial sw version with mPSNR implemented
        • Alexis to provide openEXR input/output methods
        • Technicolor to provide the deltaE implementation
        • Fraunhofer to provide the PSNR implementation
        o Results frame by frame  as  well as overall per sequence will be provided
         An xls template will be distributed to the group, developed by Alexis Tourapis (Apple), Jacob Strom (Ericsson), Edouard Francois (Technicolor)
         Delivered by September 24

        Overall timeline
        • August 15:
        o the sequences Lux and Typewriter to be provided by Alexis to Edouard
        o 2 more sequences (from Stem and Telescope) to be provided by Chad to Edouard

        • September 1st : Edouard will send Touradj the anchors sequences.
        o using the MPEG ftp site used for anchors & exploration work.
         The ftp site will be given by Jens
        • September 15: software implementing these different metrics to be provided by Jacob on September 15, 2014 – to be validated

        • September 22: EPFL provides the results to AhG chairs
        o MOS scores, confidence intervals

        • September 24: selected content made available by the AhG chairs to the group
        o Address of the ftp site where results are stored
        o People interested to get the results should contact the AhG chairs.
        o Template for reporting objective measures will also be provided by EPFL

        • October 8: proponents of objective metrics provide their results (objective scores) to Touradj

        • October 15: EPFL provides results of the analysis



        https://twitter.com/CINERAMAX<br /><br />https://WALLSCREEN-SKYLOUNGES.COM

        Comment

        Working...
        X