Re: Help with HLG profile

Hi Max and Phil,
I hesitate to ask as this may show my ignorance but I had thought that HLG encodes relative scene luminance and does not carry any metadata. In my understanding the choice of the reference white is made by the camera/cameraman shooting the scene and the camera signal is encoded as HLG which makes this model ideal for broadcast television.
You seem to anticipate having max and min luminance values - where do these come from?
What does the profile represent and how do you anticipate it being used?
As I say, this may just show my ignorance...
_Craig

On 8 Jun 2018, at 23:18, Phil Green <green@colourspace.demon.co.uk<mailto:green@colourspace.demon.co.uk>> wrote:


In my understanding yes, but you would not be able to pass in the max and min luminance so would need a different profile for each condition supported.

Phil

On 08/06/2018 16:28, Leonard Rosenthol wrote:
Can this profile be defined WITHOUT the calculator?

Leonard

From: Max Derhak <Max.Derhak@onyxgfx.com><mailto:Max.Derhak@onyxgfx.com>
Date: Wednesday, June 6, 2018 at 2:43 PM
To: Simon Thompson-NM <Simon.Thompson2@bbc.co.uk><mailto:Simon.Thompson2@bbc.co.uk>, "public-colorweb@w3.org"<mailto:public-colorweb@w3.org> <public-colorweb@w3.org><mailto:public-colorweb@w3.org>
Subject: RE: Help with HLG profile
Resent-From: <public-colorweb@w3.org><mailto:public-colorweb@w3.org>
Resent-Date: Wednesday, June 6, 2018 at 2:43 PM

Simon has indeed helped me, and I’m very grateful for his assistance.  As it turns out there was a small bug in my matlab/octave code.

Based on my matlab/octave code I have been able to create iccMAX profiles for both narrow range and full range encoding of Rec 2100 using Hgl curves. I created XML representations of the profiles and used the iccFromXML tool from the reference implementation to create the profiles for testing using the iccMAX reference implementation CMM.

Significant features of these prototype profiles include:

  *   Full floating point based algorithmic encoding of RGB to XYZ and XYZ to RGB tags using calculator processing elements
  *   Uses a D65 based PCS
  *   Max and min luminances can be passed in as CMM environment variables to adjust Hlg curves
  *   The profiles use display relative Y=100 for max white for default relative intent processing
  *   Scene relative luminances can be supported with CMM luminance matching using the spectral viewing conditions tag (part of Profile Connection Conditions – PCC) illuminant white point luminance.  (Note: Using CMM control options for luminance based matching by CMM allows for scene relative luminances to be used and adjusted for.  The PCC can be externally substituted to define an alternate white point luminance for luminance scaling, but matching values for CMM environment variables are also needed to ensure that the corresponding Hlg curves are used).

An Interoperability Conformance Specification (ICS) is needed to help define specific profile and CMM requirements for this type of profile.  That is something that the ICC display working group will work on.

None of this can be directly accomplished using a single V4 profile.  V4 uses display relative with a D50 PCS (with chromatic adaptation applied).  By playing around with defining the media white point one can achieve a level of luminance scaling using absolute intent with some possible interoperability issues to contend with.  The Hlg algorithm cannot be directly encoded in v4, and LUTs and inverse LUTs using interpolation need to be populated for a fixed scene luminance condition with different profiles created for different scene luminances.

Regards,

Max Derhak (PhD)
Principal Scientist

From: Simon Thompson-NM [mailto:Simon.Thompson2@bbc.co.uk]
Sent: Tuesday, May 29, 2018 8:52 AM
To: public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: Re: Help with HLG profile


Hi Chris, all,

I’ve already sent a code correction to Max, so hopefully that will fix the issue he was seeing.

I’ll comment further inline, below.

From: Chris Lilley [mailto:chris@w3.org]
On 17-May-18 23:25, Max Derhak wrote:
Hi,

I have an action item in the ICC Display Working group to develop an HLG based iccMAX display profile.  In order to understand how to go about it I’ve first prototyped functionality in Matlab/Octave.

The attached zip file has my code along with the BT2100 document that I’m using to implement..  The problem is that for a display profile you need to have both device to PCS as well as PCS to device transforms.

The device to PCS transform is conceptually implemented in HLG_FullToXYZ.m, and the PCS to device is conceptually implemented in HLG_XYZToFull.m  (I’m using full 0.0 to 1.0 range encoding in this case).  Alternatively one could use the HLG_Narrow12ToXYZ.m and HLG_XYZToNarrow12.m to use the narrow 12-bit integer encoding.

The problem is that the OOTF (implemented in HLG_EOTF.m)  and inverse OOTF (implemented in HLG_invEOTF) functions are not logical inverses of each other (from what I can tell from the docs).

I recall hearing that these are not round-trippable.

The equations for HLG are reversible and we have used the reverse transforms for converting other HDR formats to HLG, converting SDR camera feeds to HLG and converting HLG to SDR.  An example use case is given in: https://www.bbc.co.uk/rd/blog/2018-05-ultra-high-definition-dynamic-range-royal-wedding-uhd-hdr<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bbc.co.uk%2Frd%2Fblog%2F2018-05-ultra-high-definition-dynamic-range-royal-wedding-uhd-hdr&data=02%7C01%7Clrosenth%40adobe.com%7Cb810dc2b06c24735603308d5cbdd749e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636639074360711277&sdata=R%2BFSqmXWBTIxF8EfODM8ZR83S4jkiC8YwMpWTlFzi4Q%3D&reserved=0>



On the other hand the BBC claim that the transcode looks "identical"

A more complete description of the process of transcoding between HDR formats is given in ITU-R BT.2390 section 7: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-4-2018-PDF-E.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.itu.int%2Fdms_pub%2Fitu-r%2Fopb%2Frep%2FR-REP-BT.2390-4-2018-PDF-E.pdf&data=02%7C01%7Clrosenth%40adobe.com%7Cb810dc2b06c24735603308d5cbdd749e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636639074360711277&sdata=cXEstDUoMa2r2vIP1fmlx57urfV5uyxbR2hOEjEFbQc%3D&reserved=0>
*Also it would be incredibly helpful to better understand what is the purpose of having an HLG ICC profile?

There are a few general use cases that we’ve thought of so far which apply equally to all HDR variants:
·       Storage of subtitles and other still images – currently still formats like PNG can only store a gamma value in the header files – the only way to store non-gamma encoded images is to embed an ICC Profile.  Currently for PQ HDR, there’s a draft proposal that looks for a given ICC Profile filename in the header which then over-rides both the header and profile.  We would prefer to have the correct ICC profiles available.
·       Allowing operating systems to correctly display images on non-gamma displays.
·       IP disptribution platforms (both PC based and Set-top box will need to display video and background images) – e.g. a video embedded in a webpage, you may have a video box in HDR and a surrounding webpage in sRGB, both of which need to be correctly displayed and need an ICC profile description.



Any transforms from SDR to HDR will need to place the SDR diffuse white at the correct signal level (given in ITU-R BT.2408) – I’m not sure how this is encoded in to the transforms.



Best Regards



Simon



--
Simon Thompson MEng CEng MIET
Project R&D Engineer
BBC Research and Development South Laboratory


________________________________
[FFEI_Logo_BoxOnly[1].png]<http://www.ffei.co.uk>
CONFIDENTIALITY AND DISCLAIMER NOTICE

This message and any attachment is confidential and is protected by copyright. If you are not the intended recipient, please email the sender and delete this message and any attachment from your system.

Dissemination and or copying of this email is prohibited if you are not the intended recipient. We believe, but do not warrant, that this email and any attachments are virus free. You should take full responsibility for virus checking.

No responsibility is accepted by FFEI Ltd for personal emails or emails unconnected with FFEI Limited's business.

FFEI Limited is a limited company registered in England and Wales (Registered Number: 3244452).

[Join us on Linked In]<http://www.linkedin.com/company/ffei> [Follow @FFEI_ltd] <https://twitter.com/FFEI_ltd>  [FFEI YouTube Channel] <http://www.youtube.com/user/FFEIPrintTechnology>
Registered Office: The Cube, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 7DF, England.