Impedements to libpng-1.7.0 release?

Adam Richter <[email protected]> Wed, 26 Aug 2020 06:33:59 -0700
Newsgroups gmane.comp.graphics.png.devel
Message-ID <CAGn-TgjgCSCktjnzRz2L20w=3BaM-Ct29Z0KA0HBxAUFjUed3A@mail.gmail.com>
Hello, libpng developers.

I am wondering what is going on with the libpng17 branch, presumably
for a forthcoming 1.7.0 release.

Please feel free to point me to some web page or frequently asked
questions entry that I may have overlooked.  I have tried to look
around for answers before sending this message to the mailing list,
and I apologize if I missed an important explanation somewhere.

The libpng17 branch of git://git.code.sf.net/p/libpng/code appears to
have a ton of work contributed to it, including, some encoder
optimization attempts I have been wishing for, at least from my
initial skim of it, such as:

(1) making png_write_rows() avoid making a copy of each previous line, and
(2) writing the filter selection try all of the filters in a single
pass through the CPU,
(3) filter selection based on a histogram of output bytes, which I
hope would produce better compression.

However, the last commit to this branch was September 3, 2017, almost
three years ago.  It is sad to see all that contribution languishing.
So, I am wondering if anyone would care to describe what the issues
are with doing a 1.7.0 release.  I will list some reasons I can
imagine in question form, in the hopes of saving responders some
typing.

1. Has development simply moved to some other platform?  If so, any
pointers to it would be welcome.

2. Is there some show stopper regression currently in the libpng17 branch ?

3. Is it generally believed that some other free PNG library is better
for production use and optimization efforts should focus on that?  I
have seen mention of libspng, lodePNG and stb_image, for example.

4. Is there a binary compatibility problem that would effect the
shared library and, if so, some reason not to increment the major
release number (that is, call it 2.0.0 just for binary compatibility
reasons)?

5(a,b,c). Is the libpng17 branch thought to typically result in (a)
less compression, (b) slower compression, (c) slower decompression?

On a related topic, I would like to ask the purpose of the master git
branch versus the libpng17 branch, particularly in terms of which
branches people should contribute to.  I would have thought that
master would contain almost all changes in libpng17, but that does not
appear to be the case.

When I posted my message here last month about my experiments in
optimizing libpng, I was using the master branch and did not realize
that the libpng17 branch contained so many contributions absent from
master.  I am thinking that I may want to try similar changes and
perhaps some parallelization experiments on libpng17, but I would like
to know if that is likely to end up helping anyone.

Thanks in advance for any education on this, and, of course, thank you
very very much, libpng developers, for your decades of contributing to
libpng.

Adam