Re: PQ HDR in PNG - draft review

Hi Chris,

Thanks for the review. My feedback below.

Yes, it would be ideal if the embedded ICC profile could exactly
describe the Rec 2100 PQ colorspace. I did not think it was possible.
Let me know if you find otherwise.

Even if the embedded ICC profile matched the Rec 2100 PQ gamut, it is
still desirable to unambiguously signal that the Rec 2100 PQ
colorspace is used, to make like easier for decoders to detect and
avoid reverse-engineering the embedded ICC profile (if even possible).
The iCCP Chunk Profile Name seemed appropriate for this purpose. Let
me know if you know of a better place.

It would of course be ideal if PNG in the long-run could directly
signal non-power transfer functions, but this would require creating
and/or modifying chunks, which seemed undesirable in the short-term
since this might cause incompatibilities with the installed base of
decoders. As it stands, a PNG file that conforms to the proposal
should be displayable on all PNG decoders -- some more accurately than
others evidently.

Hope this provides additional background. Looking forward to exploring
more promising avenues, if they exist.

Best,

-- Pierre

P.S.: The proposal is at https://w3c.github.io/png-hdr-pq/.

On Thu, May 18, 2017 at 4:00 PM, Chris Lilley <chris@w3.org> wrote:
> 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

Received on Thursday, 18 May 2017 23:38:04 UTC