RE: Help with HLG profile

Hi Lars

Many thanks for the reply.

As the ITU-R BT.2100 HLG video signal is scene-referred, with a scene-referred ICC profile, would we expect a colour stored in an image file with an embedded profile match an HLG video (with the correct signalling) when composited on the same television?  (Assuming that any differences in bit-depth are handled correctly)

If so, then it sounds like such a profile is a good idea and would be what we want.

Best Regards


Simon Thompson MEng CEng MIET
Project R&D Engineer
From: Lars Borg <>
Sent: 15 October 2018 20:55
To: Simon Thompson-NM <>; Leonard Rosenthol <>; Max Derhak <>;
Subject: Re: Help with HLG profile

Yes, can be done with ICC v4. We have some already for 2100 PQ.

Should this HLG profile be a scene-referred transform or a display-referred transform?
This depends on how the profile is to be used.

With a scene-referred profile, the decoded colors would not match the color appearance as seen by the consumer on an HLG TV.
The scene-referred profile is easier to create as there’s no cross channel function.
As the scene-referred profile is display independent it might be the best option for archiving graphics and for compositing.

If a display-referred profile, as it’s HLG, it would need to be for a specific peak display luminance, probably 1000 nits as that’s the reference display in BT.2100.
SDR video profiles are usually display-referred. One exception being FCPX’s profiles.
The SDR video standards (709, 2020, sRGB) use the same decoding for all peak luminances, but HLG’s contrast function is dependent on peak luminance.

In either case, code value 75% would be the assumed graphics white as per ITU-R BT.XXXX, and would map to the PCS value.

Lars Borg, Adobe

From: Simon Thompson-NM <<>>
Date: Monday, October 15, 2018 at 12:06 AM
To: Lars Borg <<>>, Leonard Rosenthol <<>>, Max Derhak <<>>, "<>" <<>>
Subject: RE: Help with HLG profile

Hi Lars,

Many thanks for your help.

We’ve been discussing internally how we could progress this.  We would like to get a workable solution for storing graphics in the shorter term.

We believe that the best solution for HDR graphics would be to have the ability to have correct, working ICC profiles embedded in the image file (rather than using an incorrect profile with the ICC profile name as a key to induce specific behaviour in the decoding software, as proposed in the TTML group).

It sounds like there is a possibility that we could use an ICC v4 profile?  We would need ITU-R BT.2020 primaries, D65 White point and the transfer functions applied on luminance.

Best Regards


Simon Thompson MEng CEng MIET
Project R&D Engineer

From: Lars Borg <<>>
Sent: 02 October 2018 00:18
To: Simon Thompson-NM <<>>; Leonard Rosenthol <<>>; Max Derhak <<>>;<>
Subject: Re: Help with HLG profile

Here are some thoughts:

From: Simon Thompson-NM <<>>
Date: Monday, October 1, 2018 at 3:53 AM
To: Leonard Rosenthol <<>>, Max Derhak <<>>, "<>" <<>>
Subject: RE: Help with HLG profile
Resent-From: <<>>
Resent-Date: Monday, October 1, 2018 at 3:53 AM

Hi all,

Apologies for the delays in replying to this list, I’ve been busy with events over the summer period.

We are interested in furthering this work and getting a usable solution that we can use for our Video on demand platforms.  Similar use cases are explained in this blog:<>

Could I just ask:

1.      What the security concerns are with using ICCmax calculator functions?
Any implementation of ICC should be considered insecure and a hacker target.
Implementations that accept scripts as user input such as the calculator are inherently more insecure than pure data tables.
Some historical examples: SQL in input fields, Visual Basic, Word Equations, Flash
ICC is not responsible for security. The ICC reference code is usually not used commercially.
Implementors usually write their own code for better performance.
Each implementor, not ICC, needs to design its code to be secure.

2.      How far are we from widespread deployment of ICCmax?
Be prepared to wait. 15 years since the first spec came out, V4 still is not fully supported.

Could I also check my understanding of the issues?

1.      ICC v4.0 uses D50 as its PCS white point and 1D LUTs?
Don’t confuse PCS with device white points.
ICC V4 and V2 uses D50 purely as a connection point between profiles.
ICC V4 allows for D65 device white points or any other white point.
ICC V4 allows you to convert from a D65 device space to a D60 device space, etc.
ICC V4 allows your LUTs to operate at any white point.

It is rare to use 1D LUTs on the PCS side of a transform.
It is rare to use 1D LUTs in any XYZ space.
ICC 1D LUTs typically operate in device space.
A common exception would be 1D LUTs in CIELab printer profiles with 3D LUTs.

2.      ICCmax allows D65 white points and a calculator function which allows parameters to be passed – this is useful for the Display transform which varies for different screen brightnesses and surround brightnesses.

Best Regards


This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.


Received on Thursday, 25 October 2018 13:36:37 UTC