W3C home > Mailing lists > Public > public-colorweb@w3.org > May 2017

Re: PQ HDR in PNG - draft review

From: Lars Borg <borg@adobe.com>
Date: Thu, 18 May 2017 23:02:10 +0000
To: Chris Lilley <chris@w3.org>, "public-colorweb@w3.org" <public-colorweb@w3.org>
Message-ID: <D5434BC1.13EB1%borg@adobe.com>
It’s not that simple.

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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpng-hdr-pq&data=02%7C01%7C%7Ca912a96a501f4136285308d49e41b609%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636307452450338786&sdata=mSefxWeyWRV%2F2d0Pece%2BUmNbyt1wbvBYgHgrXHLQ7EI%3D&reserved=0> and the relevant ICC profile is at https://github.com/w3c/png-hdr-pq/blob/master/icc/ITUR_2100_PQ_FULL.icc<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpng-hdr-pq%2Fblob%2Fmaster%2Ficc%2FITUR_2100_PQ_FULL.icc&data=02%7C01%7C%7Ca912a96a501f4136285308d49e41b609%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636307452450338786&sdata=nWZt7Qss7RfEwqKwd7sf%2BLWn5QU82WlGpdkfXfkP%2FH0%3D&reserved=0> (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
Received on Thursday, 18 May 2017 23:02:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:11 UTC