Re: PQ HDR in PNG - draft review

On 18/05/2017 19:02, Lars Borg wrote:
> It’s not that simple.
Care to elaborate further?

>
> Lars
>
> From: Chris Lilley <chris@w3.org <mailto:chris@w3.org>>
> Date: Thursday, May 18, 2017 at 1:00 PM
> To: "public-colorweb@w3.org <mailto:public-colorweb@w3.org>" 
> <public-colorweb@w3.org <mailto:public-colorweb@w3.org>>
> Subject: PQ HDR in PNG - draft review
> Resent-From: <public-colorweb@w3.org <mailto:public-colorweb@w3.org>>
> Resent-Date: Thursday, May 18, 2017 at 1:00 PM
>
>     Hi color experts,
>
>     I have been asked to review a proposal for encoding raster
>     graphics with the BT.2020 chromaticities and the PQ EOTF from
>     BT.2100 in the PNG format. This is a spin-off from the Timed Text
>     Markup Language (TTML) Working Group.
>
>     I'm one of the authors of PNG. It has the ability to embed ICC
>     profiles (using the |iCCP| chunk) and also an older ability to
>     specify the gamma and the RGB chromaticities (using the |gAMA| and
>     |cHRM| chunks). If present, |iCCP |has precedence for color
>     management-enabled applications, PNG also supports up to 16 bits
>     per component. In principle then, this should be straightforward.
>
>     The proposal is at https://github.com/w3c/png-hdr-pq and the
>     relevant ICC profile is at
>     https://github.com/w3c/png-hdr-pq/blob/master/icc/ITUR_2100_PQ_FULL.icc
>     (click on 'view raw' to download.
>
>     I used ICC Profile Inspector to examine the profile. I also
>     converted it to XML for closer inspection.
>
>     This is an ICC 4.2 display profile, so it has a D50 whitepoint and
>     a chad tag to indicate the adaptation from D65. The first thing I
>     noticed is that there are no colorant tags to indicate the
>     primaries used. Although the specification itself does list the
>     chromaticities of the 2020 primaries, they are not in the ICC profile.
>
>     The second thing I noticed was that the lumi tag indicates a peak
>     luminance of 100 cd/m^2 which does not sound like HDR at all.
>
>     There are A2B0 and B2A0 tags for the transfer functions. The B
>     curve is linear, the M curve has a gamma of 5 and there is a
>     slightly sigmoidal A curve. I am not able to tell whether this
>     correctly represents the BT.2100 EOTF and would appreciate
>     guidance here.
>
>     Finally, having looked at the ICC profile for a while, i noticed
>     an odd statement in the specification itself. Even though it says
>     in the introduction  "This specification uses the existing |iCCP|
>     chunk to unambiguously signal the color system of an image that 
>     uses the Reference PQ EOTF specified in [BT2100-1]" the name of
>     the ICC profile is defined, "|ITUR_2100_PQ_FULL" |and this appears
>     to be a normative requirement.
>
>     The specification goes on to say:
>
>>     Note
>>
>>     The |gAMA| and embedded ICC profile are provided solely for
>>     compatibility with processors that do not conform to this
>>     specification.
>>
>     Eek! It looks as if a *magic string* is used to signal the image
>     contents, and that string is the *name *of the ICC profile. Not
>     only are the gamma and chromaticity to be ignored, but also the
>     contents of the ICC profile.
>
>     This looks terrible! Please, if I have missed something in this
>     analysis, point it out.
>
>     It seems clear that a vastly better way to encode BT.2100 still
>     images in PNG would be to embed an ICCMax profile that correctly
>     describes the EOTF and the primary chromaticities, and has a
>     correct peak luminance value. I assume that the flaws noted above
>     are due to limitations of ICC v.4?
>
>     Any obvious drawbacks of my proposed approach?
>
>
>
>     -- 
>     Chris Lilley
>     @svgeesus
>     Technical Director @ W3C
>     W3C Strategy Team, Core Web Design
>     W3C Architecture & Technology Team, Core Web & Media
>

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media