Re: [PNG] Upcoming meeting topics

>PNG decoders use unsigned 32-bit and just assume the high bit will not be
set. They would still see a large value.

_And they will continue to see it_.  Such PNG cHRM chunks already exist;
any black-hat worth their state pension has already produced lots of them.
What is more the fuzzers have too; I know because the people who operate
the libpng fuzzer have detected issues in libpng this way.  Anyone with a
binary editor can do this (search for "cHRM", set the following byte to
128...)

Notice that I'm not talking about "ACES" I'm talking about the
chromaticities ACES uses; I'm using these chromaticities as **examples**
because they are in use in the real world and one of them, ACES AP1 (for
ACES-cg) is used in PNG files.  I had to fix a bug in libpng 1.6 a couple
of months ago which erroneously rejected it; AP1 produces a perfectly valid
cHRM but it has a negative "z" for the "red" end point.  ACES AP0 is used
in ACES 2065-1 which is a candidate for cICP but AP0 is just a cHRM chunk!

That said what this means is that all existing implementations that handle
valid PNGs have to handle negative numbers in at least "z".  Skia, for
example, does seem to invert the cHRM to retrieve the CIEXYZ (from CIExyY
with Y=1) using floating point and libpng provides an API to do so which is
implemented in signed 32-bit fixed point (decimal 5dp).  The negative
values mean any conformant PNG decoder which handles cHRM must already
handle negative values even if the (x,y) alone are all positive; if it
doesn't that's a CVE.

Notice that a "PNG decoder" is the whole system which decodes a PNG stream
into the canonical data.  Since there seem to be a lot of TV guys here I'd
like to point out that the decoder includes the TV.  The same applies to
print operations; PNG is a perfectly acceptable format in the data an app
sends to a print device.  The same applies to 3D ray tracers; PNG is
frequently used to encode the multiple bitmaps used for "texture mapping"
including colour bitmaps for reflection and transmission (sometimes more
than one for each case!)  Such software frequently uses PNG as an output
format and sometimes this is not tone-mapped, ACES-cg is then one encoding
(including the ACES AP1 profile) which might be used and which will
generate an end-point (red) with a negative Z.

It is very easy to incorporate broken PNG files into documents, look at the
"corrupted" files page in the PNG test suite:
http://www.schaik.com/pngsuite/ nothing changes if a meaning is defined for
a broken file until an app writer changes their code and that suggested
definition is more likely to fix something that break it!

It is also worth nothing that the ICC profile specification (current[
https://www.color.org/specification/ICC.1-2022-05.pdf] and all previous
versions) has always allowed negative values for the **illuminant** even
though it is mandated to be D50 (maybe they changed that recently)!  In
general the ICC allows XYZ values to be negative, see the definition of
XYZNumber in 4.14 and the prior definition of s15Fixed16Number in 4.6.
chromaticity values are limited to the range [0,2) but are used for real
colours which describe real-world devices (I think) - similar to mDCv which
has a range of [0,1.3107].  PNG fixed point has a range of approximately
[-21472, +21472] and ICC s15Fixed16Number has a range of [-32768, 32768),
so slightly larger than PNG fixed point.