Re: [EXTERNAL] Re: [PNG] Meeting topics - Jan 6, 2025

Ok, I misunderstood what you were implying by this:

>Could you elaborate on why cICP is not independent of mDCV and cLLI? Most
video has existed without both mDCV and cLLI for many years. What would the
adverse effects of their absence be?

I've always assumed that the broadcast industry would want to ensure that
original broadcast data was reproduced consistently across all devices so
that two devices with the same capabilities would display the same
picture.  "*Most video has existed without both mDCV and cLLI for many
years*."   And inconsistent results existed even though the output device
capabilities (television receiver and, indeed monitor) were substantially
the same.  So I jumped to the conclusion that the ITU had, in fact,
formalised tonemapping because everyone can see that all current and,
maybe, practical RGB devices can't handle the colour gamut of 2020 (colour
primaries 9 in cICP).

Ok, *my bad*.  In fact that puts it back to exactly what I assumed at the
start.  *cICP interpretation for those primaries that are wide gamut or
don't exist in H.273 Table 2 can benefit from mDCV*.  The same applies to
cLLI for dynamic range.  I don't believe this differs from anything you
said, before my misinterpretations.

If I put *sRGB *data into a *2020 *(colour primary) container and I don't
write an mDCV chunk then I expect no detectable colour shift because the
sRGB adapted white point, D65, matches the 2020 cICP(9,) D65
encoding/adopted white point.

If I put wide gamut data with an adapted white point some way away from
D65, e.g. D50, into a REC 2020 container I will certainly expect a bad
colour shift if I don't include mDCV.  In fact I would require the colour
shift; the only adapted white the decoder can assume is the container one,
D65.

Why would I do this?  Because I have no choice: We use the tools we are
given, not the ones we want.  There are *only *three ways to include higher
dynamic range data in PNG just using publicly defined chunks:

   1. Use a gAMA value of around 1/20 (i.e. a screen gamma of "20").  The
   precise choice depends on what the aim is.  The problem is that while doing
   this produces a completely conformant PNG decoders (including libpng)
   typically cannot handle it.  My long and detailed explanation with very
   precise numbers is here:
   https://github.com/pnggroup/libpng/issues/578#issuecomment-2330282514
   2. Use a cICP chunk with the transfer function set to 16 (PQ) and the
   original PQ depth (record it in sBIT) chosen carefully.  If you go too high
   you gain no perceptual benefit but the noise zaps the PNG compression (not
   that 16-bit compression is that good in any case.)
   3. Use a cICP chunk with the transfer function set to 18 (HLG) and sBIT
   to 10 - at least that seems to be the only defined choice at present.  Be
   very careful to follow the mandatory instructions in H.273 about scaling to
   16 bits.

So then I have the transfer function in a chunk that is fully approved by
the W3C, the broadcast industry and others!  However now I have to chose
from one of the numbers in Table 2.  There is very little choice if the
data is not only "HDR" but is also wide gamut.  I can only see two choices;
additions to my list are very welcome and I haven't checked through the
H.273 chromaticities to see whether any others are wide gamut:

   1. 10: CIEXYZ.  Completely complete, every colour of the rainbow and all
   the others too.  Horribly inefficient as an encoding in PNG but, in fact,
   that probably improves the 16-bit compression.
   2. 9: REC-2020 again.  Not complete.  The question is whether the
   overlap in tristimulus colour space (measured in CIELab or CIELuv) is
   sufficient.  This is a tricky calculation which I haven't done.  I'd be
   tempted more by CIEXYZ despite the maybe weird adopted white.

I'm not trying to persuade anyone of anything beyond my normal aim which is
to present arguments in the forumagora.  Based on what I have just read and
just learned mDCV at least is essential to cICP in the broader context of
all possible valid PNG usage.

This is just my opinion.