Re: [PNG] Upcoming meeting topics

OH! You're right!
I forgot that the PNG spec saves the high bit of a 4-byte unsigned int.
Well then, that is SUPER convenient. And sorry I missed that when you
originally said it above. (Side note: This isn't true for 2-byte unsigned
ints.)
I'll have to investigate implications--that high bit is explicitly defined
to not be used. So using it breaks that.

But that said, I wouldn't be shocked if several PNG decoders use unsigned
32-bit and just assume the high bit will not be set. They would still see a
large value.
I see libpng does check the range. Chrome and Firefox use libpng.
lodepng doesn't
<https://github.com/lvandeve/lodepng/blob/79a61c79cc62814f315661f53a026004bac80614/lodepng.cpp#L5011>.
Nor does spng
<https://github.com/randy408/libspng/blob/adc94393dbeddf9e027d1b2dfff7c1bab975224e/spng/spng.c#L2464>.
But we can file bugs on those.

I'll try to find a way to test Safari, Adobe tools, Microsoft tools, etc.

But I do think this opens the possibility you suggest.

On Thu, Nov 21, 2024 at 10:35 AM John Bowler <
john.cunningham.bowler@gmail.com> wrote:

> >PNG decoder which understands cHRM as unsigned will see a huge number for
> ACES AP0.
>
> No it won't.  The maximum PNG unsigned value is 0x7FFFFFFF.  All the PNG
> 32-bit **signed** values are encoded with bit sequences outside this range
> and are therefore rejected as invalid.  All **valid** PNG unsigned values
> are **also** **valid** signed values positive values and all the the
> unsigned values have exactly the same 32-bit (4-byte) representation as the
> identical PNG signed values.
>
> All the 32-bit sequences which correspond to negative PNG signed values
> are invalid PNG 32-bit **unsigned** encodings.
>
> I did say all of this above!
>
> I'm simply pointing out that the "dead" space in the PNG 32-bit encoding
> of PNG unsigned values (which currently results in the cHRM chunk being
> rejected if used) can simply be used to fix this serious defect in the PNG
> specification.
>
> So nothing gets broken.  I did say this above.  I made both these points
> in what I wrote.
>