libpng complexity (Was: [PNG] Cancel meeting?)

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