Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

integrate FPNG for ultra fast encoding/decoding #155

Open
richgel999 opened this issue Jan 3, 2022 · 1 comment
Open

integrate FPNG for ultra fast encoding/decoding #155

richgel999 opened this issue Jan 3, 2022 · 1 comment

Comments

@richgel999
Copy link

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

@lvandeve
Copy link
Owner

lvandeve commented Jan 9, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants