Re: Help with HLG profile

Hi Leonard

I understand your concern about the Calc element in iccMAX.

ICC has been proactive around the potential for exploits of v4 profiles (http://www.color.org/profilesecurity.xalter), including making tools available to identify known problems, documenting good practice, publicly reporting issues, and providing a profile scanning service. I anticipate that these policies would also apply to iccMAX profiles.

However, you are right to imply that it cannot be proven that all instances of the Calc element will resist all possible exploits, and Adobe products process a wider range of profiles than other software typically does. It is expected that the iccMAX profiles for a given workflow will be based on a sub-set of iccMAX tags defined by an ICS, and a software vendor can choose which ICSs to support. Although it would be a pity to restrict the functionality available, while there are uncertainties about the vulnerability of the Calc element it would be possible to limit support to ICSs that exclude it.

Phil

On 21/10/2018 22:02, Leonard Rosenthol wrote:
[Sorry to have this discussion “in public”, but since it has come up]

Max – as an implementor of one of two most widely attacked (and therefore security conscious) applications in use today (aka Adobe Acrobat/Reader), I can say with quite a bit of authority that while I appreciate your (and the ICC’s) efforts to create a “secure” calculator feature, it is not!  None of the members of the ICC are security experts (nor would I expect them to be) and the material was not reviewed by any such experts.  And because you chose to create a completely new “language” which requires completely new parsers – it makes it even more open for possible security holes.

Until the ICC has their reference implementation properly reviewed and pen-tested by a reputable authority of application security, Adobe (and others) will not support Calc elements in iccMAX profiles in actual world usage.


Concerning support for iccMAX in real world usage…while I agree with all of your statements of active work (eg. FDIS, creation of various ICS’s, etc.) and even the fact that it offers functionality not currently present in v4 – none of that changes the fact that it will take developers quite a while to develop their own implementations of iccMAX since many companies may not be able to use the reference code as it uses a non-standard license agreement.

I, for one, don’t think it will be as long as Lars’ 15 years – but it’s certainly not sooner than 5…


Leonard

From: Max Derhak <Max.Derhak@onyxgfx.com><mailto:Max.Derhak@onyxgfx.com>
Date: Sunday, October 21, 2018 at 9:54 AM
To: Lars Borg <borg@adobe.com><mailto:borg@adobe.com>, Simon Thompson-NM <Simon.Thompson2@bbc.co.uk><mailto:Simon.Thompson2@bbc.co.uk>, Leonard Rosenthol <lrosenth@adobe.com><mailto:lrosenth@adobe.com>, "public-colorweb@w3.org"<mailto:public-colorweb@w3.org> <public-colorweb@w3.org><mailto:public-colorweb@w3.org>
Subject: RE: Help with HLG profile

I’m sorry for the late response.  I’ve been incredibly busy at work, and getting ready for travel and participating in ISO/ICC standards meetings.

Here are some thoughts on Lars’s thoughts – below.

Best Regards!
Max

From: Lars Borg <borg@adobe.com><mailto:borg@adobe.com>
Sent: Tuesday, October 2, 2018 8:18 AM
To: Simon Thompson-NM <Simon.Thompson2@bbc.co.uk><mailto:Simon.Thompson2@bbc.co.uk>; Leonard Rosenthol <lrosenth@adobe.com><mailto:lrosenth@adobe.com>; Max Derhak <Max.Derhak@onyxgfx.com><mailto:Max.Derhak@onyxgfx.com>; public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: Re: Help with HLG profile

Here are some thoughts:

From: Simon Thompson-NM <Simon.Thompson2@bbc.co.uk<mailto:Simon.Thompson2@bbc.co.uk>>
Date: Monday, October 1, 2018 at 3:53 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, Max Derhak <max.derhak@onyxgfx.com<mailto:max.derhak@onyxgfx.com>>, "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: 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: https://medium.com/netflix-techblog/enhancing-the-netflix-ui-experience-with-hdr-1e7506ad3e8<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fnetflix-techblog%2Fenhancing-the-netflix-ui-experience-with-hdr-1e7506ad3e8&data=02%7C01%7Clrosenth%40adobe.com%7Cc615da1a85314bbe014d08d6372a5a26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636757052397916848&sdata=OK0eUPVDnN0xNKoHh7rlpoI5KiNlw%2B%2FlerDr3Fkokeo%3D&reserved=0>

Could I just ask:

1.       What the security concerns are with using ICCmax calculator functions?
LB - 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.

MD -  Lars is correct in asserting that any implementation of ICC is a hacker target.  And ultimately, implementers are responsible to ensure that they have done their very best to ensure the security of their products.  However, the ICC would have been negligent if it had not taken security into consideration in the design of the calculator element.  And great consideration was put into the development of the specification for the calculator element in iccMAX (please note proper capitalization). Two significant features/limitations of the iccMAX calculator scripting language  were put into place to help establish security form a specification point of view.  The first is static addressing of memory - The iccMAX calculator script is formed by a sequence of operator codes that each have static parameters associated with them.  The second is that the script can be represented as a tree structure (no loops) and therefore every possible flow of operations along with all possible associated memory accesses related to the script (defined using static parameters) can be determined using a recursive analysis of the script BEFORE THE SCRIPT TRANSFORM IS APPLIED.  The iccMAX specification specifies that this SHALL be done to ensure that all operators are valid and only valid memory use is performed by any branch of the script execution path.    Any profile with either invalid operators or invalid memory uses is by definition an invalid profile and should be flagged by the CMM and not used.  Additionally, the ICC is providing profiles that test each and every operator to purposely access invalid memory for implementers to test against to ensure that they are correctly checking for these conditions.    Every effort has been made to try to achieve as close as possible the same level of security in an iccMAX calculator script as a data table.

I also agree with Lars that optimal implementations are needed.  However, I disagree that implementers have to implement everything from scratch.  Having an open source reference implementation (which is also very object oriented) provides a basis on which implementers can more easily extend to define their own optimizations (which is what Onyx Graphics has done).  At minimum it provides a basis for comparison in their own implementations.


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

MD -  I beg to differ with Lars on this for two reasons. The first is that V4 did not provide much functional difference over V2 (everything that could be done in V4 could be done in V2).  The second is that there was no reference implementation.  The whole point of iccMAX is that it provides for functionality that cannot be completely achieved using V4/V2 profiles.  Once iccMAX profiles are being used to do things that cannot be done with V4/V2 profiles there will be greater pressure for support of iccMAX to be implemented.  The iccMAX specification is currently up for FDIS ballot concluding early in November.  If it passes this ballot then it will be an ISO standard. Interoperability Conformance Specification (ICS) documents are presently in the works (awaiting having an ISO standard for iccMAX) to define subsets of iccMAX for specific workflows.


Could I also check my understanding of the issues?

1.       ICC v4.0 uses D50 as its PCS white point and 1D LUTs?
LB - 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.

MD -  Lars is correct that there is a difference between PCS and device points.  However, with V2/V4 the PCS IS BY DEFINITION D50.  This means that like the game show Jeopardy where every answer needs to be expressed “In the form of a question” all colorimetry in V4/V2 profiles needs to be chromatically adapted to D50.  Thus, the RGB primaries in sRGB and AdobeRGB V2 profiles are chromatically adapted to D50.  If you want to work with D65 colorimetry from PCS values you have to chromatically adapt them back to D65 first.  With iccMAX the PCS can have whatever observer/illuminant you desire and no conversion is made by the CMM if the profiles have a PCS with matching observing conditions.

For matrix/TRC profiles you only have 1-D luts that are applied before the primary matrix.  V2/V4 LutAToB/LutBToA tags have a fixed sequence of operations with the ability to leave out some of the elements.  The elements involve 1-D curves, N-D Luts, and a 3x3 matrix.


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.

MD -  That is correct. As others have indicated, you should probably be able to define a V2/V4 profile that does something like HLG but the primaries will be chromatically adapted to D50 in the profile, and you will have to define curves (probably as 1D-LUTS) that have a fixed set of parameters.  To have different parameters you would need to define separate profiles and then put in logic in the calling APP to select and apply the correct profile.

Best Regards

Simon