Randy

Changes made for libpng compatibility so far: * Handle invalid palette indices as black, opaque pixels - https://github.com/randy408/libspng/commit/4955d6449b8fd62083b924c973461687888857dc * Ignore tRNS chunks for grayscale alpha / truecolor alpha images -...

To improve libpng compatibility the default CRC action for ancillary chunks will be changed from `SPNG_CRC_ERROR` to `SPNG_CRC_DISCARD`. 1. https://libspng.org/docs/context/#spng_crc_action 2. https://github.com/glennrp/libpng/blob/v1.6.37/png.h#L1436 Related issues: * https://github.com/gatsbyjs/gatsby/issues/28203 * https://github.com/lovell/sharp/issues/2448

Since [v0.6.3](https://github.com/randy408/libspng/releases/tag/v0.6.3) all corrupted ancillary chunks are silently discarded, this eliminates 99% of compatibility issues with existing images.

Saving this here for future reference: https://github.com/madler/zlib/issues/149#issuecomment-225237457

This would be the equivalent of `png_set_expand_gray_1_2_4_to_8()`? There's also `png_set_packing()` which seems to also apply it for indexed color images too.

I wonder if those two functions are different for grayscale images, maybe the latter unpacks them without scaling? It's not like scaling the indices would make sense, if neither does...

`SPNG_FMT_UNPACK` would be a single set bit and must be OR'd with `SPNG_FMT_PNG` or `SPNG_FMT_RAW`, that's the only way it makes sense to me. It could be implemented as an...

I've made the decision to support grayscale (output) formats, there's some limited support right now, more importantly expanding 1,2,4-bit grayscale to `SPNG_FMT_G8` with scaling is supported, for unsupported PNG formats...

For interlaced images with subimages which match the width of the image there is no deinterlacing to be done, the non-interlaced codepath can be used which involves less copying.

The current streaming API expects the read callback to copy data to a library-controlled buffer, this introduces unnecessary copying if the user is also storing the PNG in memory. Add...