Re: Help with HLG profile

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>
> *Date: *Wednesday, June 6, 2018 at 2:43 PM
> *To: *Simon Thompson-NM <Simon.Thompson2@bbc.co.uk>, 
> "public-colorweb@w3.org" <public-colorweb@w3.org>
> *Subject: *RE: Help with HLG profile
> *Resent-From: *<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
> *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*
>