RE: Help with HLG profile

Hi Simon,

I was first on vacation (memorial day) and out of the office last week with the ICC meeting.  I did get your fix and it addresses my questions.  I just now need to put things together to create the iccMAX profile.  In answer to your question the iccMAX specification uses a relative luminance based PCS, but allows for an option to perform luminance scaling (based on the absolute luminance of the scene white point in the spectral viewing conditions).  I intend to implement it using the iccMAX calculator element which allows for a CMM environment variable to be utilized to provide the peak luminance for the HLG curves.

Thanks again for your help!

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
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



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
*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