- From: John Bowler <john.cunningham.bowler@gmail.com>
- Date: Sun, 21 Jan 2024 14:43:52 -0800
- To: public-png@w3.org
On Sat, Jan 20, 2024 at 2:46 AM Chris Lilley <chris@w3.org> wrote: > looking at the github repo, libpng looks complicated and arcane. Indeed it is. Indeed it was in 1996. Perhaps because of this alternative decoders and encoders have been developed since 1996, possibly before (Adobe?) One of the latest fairly complete implementations is here: https://github.com/image-rs/image-png It does support APNG but it does not support eXIf and several other ancillary chunks. I didn't determine whether it can support wide gamut. There are many others, some proprietary (Adobe? Microsoft) others single files, all of them much less complex than libpng. libpng has over 30 years of coding inside. The last release to actually remove significant stuff from the API happened many years ago. However a reference implementation does not have these legacy requirements; sure, the PNG specification needs to support legacy usage of the *format*, but a reference implementation should show the best practice in using the specification. If a change to a reference implementation breaks all the code that uses it so what? Older users will simply use the older version until they can get round to rewriting their code. Users who want bug free code don't rely on reference implementations anyway and probably don't program in C :-) The issue is that a reference implementation is free of legacy requirements while a legacy implementation is bound by those requirements. libpng really is a legacy implementation. It's entirely reasonable for the WG to want a reference implementation but starting from something that doesn't just "look" but actually is "complicated and arcane" is a misstep. I've done a brief code review and I suggest the Rust implementation above is a better starting point but then it's just the first one I looked at from this point of view. John Bowler <jbowler@acm.org>
Received on Sunday, 21 January 2024 22:45:53 UTC