RE: Help with HLG profile

Hi Leonard,

I’m glad you could join in on the discussion.  I prefer openness.  That’s why I’m involved in the ICC.

I agree with you that you can only call something “secure” until an implementation is in place and you have someone that you trust perform an analysis that provides a merit of risk that you feel is acceptable.  And even if one implementation has been provided the “blessing” of security by someone, that doesn’t necessarily mean this directly transfers to a separate implementation.  Additionally, I also agree that whether to implement something is a business decision that I cannot (nor should not) dictate.  I can hope for and encourage, but recognize that others need to take the risks and benefits into account in how they make their business decisions.

However, it is only fair and probably should be expected that those involved in the design and thought process of the specification to describe considerations and efforts that were put in place to help both mitigate possible security problems as well as provide guidance and assistance where possible for implementers to develop better products based on that specification.  This is not the same thing as saying that “It is securre” any more than saying “It is not secure” is the same thing as saying that no consideration was put into place to mitigate possible security risks.

That said I’d like to also address the issue of complexity in implementing the calculator element that has been alluded to by various individuals.  One of the considerations leading to the development of the calculator element is that we didn’t want to burden the CMM implementer with a large and complex library that would be associated with trying to incorporate an existing language.  We looked at CTL and its size and scope is much larger than the entire reference implementation.  Providing our own scripting language allowed us to minimize the implementation overhead and directly address performance and security issues.

The calculator element is implemented in the reference implementation within a single (but somewhat large) CPP file with an associated header file.  It implements the CIccTag interface and parsing a Calculator element is no more onerous that parsing a LutAToB Tag.  The script itself is stored as an array of 32 bit values that is more complex to parse than a 1-D LUT.  Additional sub elements are stored in a calculator element in the same fashion that sub elements are stored in a LutATOB tag.  Implementing the calculator element can be broken up into three parts: parsing, validation, and interpolation/transform application.  Parsing I have described, and in my previous email I outlined the basics of validation with checks for operator validity, correctness of branching offsets, and checks for invalid memory accesses. Since pixel transforms are atomic in that (per the specification) there is no means of having successive transforms pass information between each other, the interpreter is pretty basic, memory values start out initialized to zero, and the data stack is empty.  Operations are performed one operator at a time manipulating memory values and values on the data stack resulting at some point with values being put into the output channels.  For further understanding I encourage people to look at the reference implementation on github.

I openly admit that the reference implementation of the calculator element has plenty of room for optimization.  Internal caching mechanisms and implementation of a JIT compiler are two potential routes for per performance gains.

I appreciate your open dialog!

Best regards,
Max

PS – I’m not sure about your reference to the license.  My understanding is that it is essentially the same as the LGPL2 with the difference that it encourages (not requires) individuals to participate in the ICC and not hold ICC members responsible for any damages.

From: Leonard Rosenthol <lrosenth@adobe.com>
Sent: Sunday, October 21, 2018 10:03 PM
To: Max Derhak <Max.Derhak@onyxgfx.com>; Lars Borg <borg@adobe.com>; Simon Thompson-NM <Simon.Thompson2@bbc.co.uk>; public-colorweb@w3.org
Subject: Re: Help with HLG profile

[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