Randy

`struct spng_chunk` should have been removed from the header before the API was stabilized, this led to `struct spng_unknown_chunk` as a workaround. Consider renaming the latter to the former and...

`struct spng_ihdr.color_type` is currently `uint8_t`, `enum spng_color_type` would be better.

Consider widening `struct spng_offs.unit_specifier` and `struct spng_phys.unit_specifier` to enums. edit: `struct spng_row_info.filter` and `struct spng_ihdr.interlace_method` too

If this would change the produced filename this would have to be delayed until at least the next minor release or 1.0.

Are the callbacks for libpng's push style API optional? How would you know if you reached the start or end of image data, the end of the file, etc?

> I'm not sure what you're asking I'm asking how you're doing I/O with the libpng ffi binding, `png_process_data()` itself does not require a callback but I've only seen it...

Would the spng binding also use ffi? I have an incomplete project meant for PUC Lua called spng-lua.

File I/O is already supported through opened `FILE*`'s, so `fread()/fwrite()` makes it depend on the crt(?) Paths are not supported at the moment because it's not as straightforward on Windows...

Never used vcpkg, if it needs upstream changes patches are welcome.

GitLab CI was set up to run on PR's, a complete migration isn't necessary anymore.