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

FWIW – Adobe uses libpng for all of our desktop and mobile applications (for the web we let the browser do the work for us).

As John says, libpng is VERY old code designed to run on any platform (not necessarily to do so optimally).  The original author/maintainer (Glenn) passed away about 5+ years ago, and I am not aware of who (if anyone) picked up that responsibility.

I have no objection behind review existing implementations and seeing if one of them could be updated to be considered ”reference” – but I think that a starting point would be for the maintainers of any such implementations to join the W3C and this group.

Leonard

From: John Bowler <john.cunningham.bowler@gmail.com>
Date: Sunday, January 21, 2024 at 2:46 PM
To: public-png@w3.org <public-png@w3.org>
Subject: libpng complexity (Was: [PNG] Cancel meeting?)
EXTERNAL: Use caution when clicking on links or opening attachments.


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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fimage-rs%2Fimage-png&data=05%7C02%7Clrosenth%40adobe.com%7C015e4ef0925644ad1c1e08dc1ad2bb60%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638414739604375970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=67FBoEvBM%2Fz3FAaPM0C0srFGZ9taAnAt5UQkqIFT2lI%3D&reserved=0<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>