Randy

I believe this has to do with invalid zlib headers, if you set `SPNG_IMG_WINDOW_BITS` to `0` before `spng_decode_image()` then zlib will take into account the (potentially invalid) window size instead...

That's not where zlib is initialized, this is the init code with `InflateReset2()`/`InflateInit2()`: https://github.com/glennrp/libpng/blob/v1.6.39/pngrutil.c#L361-L422 The linked code explains why libpng doesn't ignore the window size: > the original writer of...

I think the big problem with this will be errors specific to parallel decoding that don't count as errors when decoding linearly, therefore if you fail at parallel decoding at...

>the IDAT chunks of PNG always contain non-final blocks except for the last one. In practice it doesn't even have to end, decoders just stop when they got enough data...

The existing file format does allow for additional compression/filter methods and new ones could be added to a PNG 2.0 standard. The situation would be similar to JPEG XL where...

ARGB format support is planned but not padded rows, that can be achieved with the progressive decode/encode API.

Currently there is no option to check palette indices, but there is also no clamping going on, did you decode with `SPNG_FMT_PNG/RAW` to check the values? Maybe the default handling...

`SPNG_FMT_PNG` works for both encode and decode for all formats, if you want RGB16 from a RGB16 PNG or G16 from a G16 PNG then an explicit format enum is...

> Shouldn't color_type be of type enum spng_color_type rather than uint8_t ? The fields have the same size as the described by the file format, but I'll probably change that...

The standard uses the term "truecolor", at the time it made sense to use the exact same words. I wouldn't add something like `SPNG_COLOR_TYPE_RGBA8` because the standard expresses color type...