PNG image I/O

[dcommander]

It would be nice to extend cjpeg, djpeg, and the TurboJPEG image I/O functions to handle PNG images, since PNG is the standard compressed lossless image format these days, it supports 16 bits per component (and could thus be used to test the new 12-bit and 16-bit data precision features), and it isn't limited to 256 colors like GIF. We could borrow some code from mozjpeg, but significant additional development and testing would be required in order to make the PNG I/O module as feature-rich as the current PPM I/O module, which can rescale samples to the target data precision and convert between various pixel formats.

[dcommander]

I'm refreshing my memory as to why PNG support was never added to libjpeg-turbo. It's because libjpeg-turbo and libpng are at the same level on the open source infrastructure stack. Thus, any cross-dependency between the two would have to be managed by a downstream packager in the context of a packaging environment such as a Linux/Un*x distribution, MacPorts, Homebrew, Cygwin, MSYS, Chocolatey, etc. Different Linux distributions include different versions of libpng that are not necessarily ABI-compatible, so it would probably be untenable to include a libpng dependency in our official Linux SDK packages. (It would definitely be untenable for our official macOS and Windows packages.)

That being said, libspng is a much less complex PNG implementation that doesn't depend on zlib and appears to be actively maintained. It is simple enough that we could optionally use an in-tree static implementation of it for our official packages and allow downstream packagers to link libjpeg-turbo dynamically against a system-supplied libspng implementation, if such an implementation exists.