lvandeve
commented
2 years ago Hi,
I've seen FPNG and it's great! I'm going to keep following it and learn from it. It also encourages trying to do some speed improvements.
I'm not planning to integrate it directly currently though since the goals are slightly different, with lodepng being more pure platform agnostic C, but that doesn't preclude possibly recognizing the chunk in the future if it can help decoding speed even with a more naive implementation. But it's possible to combine both as far as I can tell so there's maybe no need for tighter integration.
About the fdEC chunk: the fpng decoder has the comment: // Scan all the chunks. Look for one IDAT, IEND, and our custom fdEC chunk that indicates the file was compressed by us. Skip any ancillary chunks. This permits this chunk being at the beginning but also at the end. It might make sense to require this chunk to be at the beginning, before IDAT, so that streaming decoders can also benefit from it. Of course I also see that multiple IDATs are not permitted either and a streaming decoder can't know that no others will follow so maybe it's not helpful after all if going in fast mode but then having the IDAT end early would cause a problem. WDYT?
Hi, I use lodepng in our open source product (Basis Universal): https://github.com/BinomialLLC/basis_universal
It's great. I've integrated the latest lodepng version which is coming out in a few days.
I've released a super fast open source PNG encoder/decoder for 24bpp/32bpp that competes against QOI. It also includes a customized decoder that uses a special private ancillary chunk to know when the PNG file can be quickly decoded. It uses the unlicense (public domain) and not much code: https://github.com/richgel999/fpng
The first PNG library to implement support for this approach will have a leg up on the competition. Regards, -Rich