[randy408]

> bKGD overflow, tRNS overflow

This is one of those awkward parts of the standard, the samples always take up 16 bits and decoders are expected to mask off the extra high bits, any 16-bit value was supposed to be considered valid. In the real world trash values are often written for transparency (tRNS) chunks that inadvertently match samples in the image when the extra bits are masked off, which leads to random holes in the image. In practice those chunks have to be ignored when the values are out-of-range for the given bit depth.

[nayuki]

Nope. I rechecked the PNG specification, and it explicitly states that the high bits must be zero:

"If the image bit depth is less than 16, the least significant bits are used and the others are 0." -- Year 2003, https://www.w3.org/TR/2003/REC-PNG-20031110/#11bKGD

"Gray: 2 bytes, range 0 .. (2^bitdepth)-1" -- Year 1996, version 1.0, http://www.libpng.org/pub/png/spec/1.0/PNG-Chunks.html#C.bKG...

[randy408]

It makes sense to treat it as an error but the ISO standard is too vague on this and the libpng developers never "fixed" this[1], it issues a warning but otherwise just masks off the high bits. Firefox has a workaround[2][3], Chrome doesn't.

FWIW I do the same in my library[4], handling it as an error is problematic because it would mean the chunk gets discarded and then you can't even retrieve the values.

[1] https://sourceforge.net/p/png-mng/mailman/png-mng-implement/...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=428045

[3] https://searchfox.org/mozilla-central/source/image/decoders/...

[4] https://libspng.org/