png-mng-implement — PNG and MNG programming issues, including use of libpng and libmng

[png-mng-implement] libpng 1.8.0 late beta: default branch switch and release preparation

[Cosmin T. <ct...@gm...>]

This is a re-posting of github.com/pnggroup/libpng/discussions/735

***

Hi everyone,

Following up on the early beta announcement from July
<https://github.com/pnggroup/libpng/discussions/726>: libpng 1.8.0 has been
progressing well, and we've now reached the *late beta* stage!

This is a major milestone. The default branch on GitHub has been switched
from libpng16 to libpng18. This reflects our confidence in the 1.8.0
codebase, and it signals that we're approaching release readiness.

WHAT'S HAPPENING NOW:

   - The libpng18 branch is stable and feature-complete, with APNG support
   fully integrated.
   - The documentation is being reorganized and updated. The *"What's new
   in libpng 1.8"* part is coming up soon.
   - We're still working on code deprecations, code cleanups, and build
   system refactorings and cleanups.

WHAT TO KEEP IN MIND:

   - To the best of our knowledge, the correctness of libpng 1.8.0 beta and
   the correctness of libpng 1.6.51 beta are on par. In other words, there are
   no more known bugs in the upcoming libpng 1.8.0 release than there are in
   the upcoming 1.6.51 release.
   - The 1.6.x line is effectively in maintenance mode. With the
   development work shifted onto 1.8.0, we will cherry-pick commits into 1.6.x
   as needed, but the focus will be almost exclusively on correctness and
   security. On the other hand, the work on 1.8.x line will be merged upward
   to 2.x on a regular basis.

WHAT WE NEED FROM YOU:

*Testing!* If you're using libpng in production (browsers, image tools,
embedded systems), now is the time to test the libpng18 branch with your
configurations. We especially want to hear from:

   - Users with custom build configurations.
   - Projects with platform-specific optimizations.
   - Anyone using libpng in security-critical contexts.

Please report any issues you encounter. The more testing we get now, the
smoother the final release will be.

The finish line is in sight. Stay tuned for the final 1.8.0 release!

Sincerely,
Cosmin

[png-mng-implement] libpng 1.6.50 goes out, libpng 2 alpha steps in, and PNG 3 turns it up!

[Cosmin T. <ct...@gm...>]

Hello, world,

While I was not paying full attention, the PNG-3 standard became officially
ratified, and our own Chris Blume wrote an exceptional article, picked up
and commented enthusiastically by the media.

https://www.w3.org/TR/png-3/
https://www.programmax.net/articles/png-is-back/

If Theo Browne says there's one thing we can all agree on, that PNG is
awesome, then let us all agree with his agreement (^_^)

https://www.youtube.com/watch?v=kbLKROuv27g


---

libpng-1.6.50 is out, business-as-usual. The RISC-V support is getting
better, the cross-platform build support is getting better also; and, just
when we thought we had sorted out all of the "regular" API bugs, here comes
John Bowler proving us wrong. He just fixed a decades-old decoder defect in
which unknown chunks trailing IDAT, set to go through the unknown chunk
handler, incorrectly triggered out-of-place IEND errors. The users who
didn't enable the unknown chunk handler might not care about this, but the
users who do use it might find this fix welcome.

https://github.com/pnggroup/libpng/tree/v1.6.50/
https://sourceforge.net/projects/libpng/files/libpng16/1.6.50/
https://raw.githubusercontent.com/pnggroup/libpng/v1.6.50/ANNOUNCE

---

..... aaaaaaaaaand .....

libpng-2 alpha is in our official repo, in the 'develop' branch, with the
APNG patch applied, and with a bunch of APNG-related fixes already on top
of that. Some of the external projects already picked it up, chief among
them being the mighty GIMP!

https://github.com/pnggroup/libpng/tree/develop/

---

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published files:

libpng-1.6.50.tar.gz
708f4398f996325819936d447f982e0db90b6b8212b7507e7672ea232210949a

libpng-1.6.50.tar.xz
4df396518620a7aa3651443e87d1b2862e4e88cad135a8b93423e01706232307

lpng1650.7z
757a5b50fac3697a67d25440d701a3ea83b0b9d641c43bd4b5f41af42aeaae0f

lpng1650.zip
4be6938313b08d5921f9dede13f2789b653c96f4f8595d92ff3f09c9320e51c7

---

Sincerely,
Cosmin

[png-mng-implement] Announcing libpng version 1.6.49 + pre-announcing libpng version 2

[Cosmin T. <ct...@gm...>]

*Motto: "hello, world!"*
-- Brian Kernighan, BCPL programmer, circa 1972

So... hello, world!

In observance of today's date (Friday, 13th of June, 2025), and in defiance
of paraskevidekatriaphobia, I am super-happy to announce the release of
libpng-1.6.49 which happened yesterday, the merging of all changes into
libpng-1.8 which happened today, and the renaming of libpng-1.8 to libpng-2
which will happen tomorrow.

libpng-1.6.49 is the latest, greatest and stable-est of all libpng
releases. This is the first libpng version in which the delta-filtering
implementation is SIMD-optimized for the RISC-V architecture --
specifically for the RV64GV variant of the RISC-V ISA. I would like to
thank Manfred Schlägl, Dragoș Tiselice and Filip Wasil, not only for their
exceptional work, but also for their exceptional patience: according to my
records, Manfred submitted the first pull request back in September 2021(!!)

https://github.com/pnggroup/libpng/tree/v1.6.49/
https://sourceforge.net/projects/libpng/files/libpng16/1.6.49/
https://raw.githubusercontent.com/pnggroup/libpng/v1.6.49/ANNOUNCE

Next in line is libpng version 1.8, which is about to have an ever shorter
development life than its predecessor version 1.7.

Tomorrow I will rename the v1.8 development branch to v2. And not only
that, but also, I want to make certain C language and library features
mandatory, from C99 onwards. And not only that, but also, I want to make
certain zlib library features mandatory, from zlib-1.2.8 (or maybe from
zlib-1.2.11) onwards. And not only that, but also, I would like to invite
everyone interested to discuss and debate what to do and what not to do,
either on our group's png-implement mailing list or on our group's brand
new discussion forum at https://github.com/pnggroup/libpng/discussions/

---

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published files:

libpng-1.6.49.tar.gz
d173dada6181ef1638bcdb9526dd46a0f5eee08e3be9615e628ae54f888f17f9

libpng-1.6.49.tar.xz
43182aa48e39d64b1ab4ec6b71ab3e910b67eed3a0fff3777cf8cf40d6ef7024

lpng1649.7z
74129e2c3fdcbcc6a7a0bca21e394597ae30593fe948235808790d4d9db120e2

lpng1649.zip
84d82e24e8436b05f2e1a5fba218cbd0a017c27f1f735151f257277409a0809c

---

Sincerely,
Cosmin

[png-mng-implement] libpng 1.6.48 released

[Cosmin T. <ct...@gm...>]

Dear libpng users,

I'm as happy as usual for my business-as-usual announcement of the release
of libpng 1.6.48.

Notably, we swatted a bug in the floating-point API, specifically in the
setter of the mDCv chunk. We had only tested the fixed-point API at the
time when we first introduced the mDCv support. (Oopsie!)

https://github.com/pnggroup/libpng/tree/v1.6.48/
https://sourceforge.net/projects/libpng/files/libpng16/1.6.48/
https://raw.githubusercontent.com/pnggroup/libpng/v1.6.48/ANNOUNCE

--

I would like to send a big thank you to Travis CI for their five-year-long
contribution to our automated verification process. Until we sign up with
another service, I will be performing those verifications, manually, on
FreeBSD, Linux and Mac. Mind you, it's not me, exactly; it's my ThinkPad,
my Mac, and my Raspberry Pis. I'll be the one who claims *"Works For Me™️"*.

And, of course, thanks that are just as big shall go to AppVeyor CI for
continuing to help us out with the verification on Windows.

https://ci.appveyor.com/project/ctruta/libpng

--

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published files:

libpng-1.6.48.tar.gz
68f3d83a79d81dfcb0a439d62b411aa257bb4973d7c67cd1ff8bdf8d011538cd

libpng-1.6.48.tar.xz
46fd06ff37db1db64c0dc288d78a3f5efd23ad9ac41561193f983e20937ece03

lpng1648.7z
ee1c03066e1f6fdc6fe44b9a83a895f9f92039659895ee08324b82fe6bfb50b6

lpng1648.zip
2e5f080360f77376eb2bfa9e2ed773b9c7728159aba47b638ad53ca839379040

--

Sincerely,
Cosmin

Re: [png-mng-implement] pngcheck, live at https://github.com/pnggroup/pngcheck

[Cosmin T. <ct...@gm...>]

Chris Lilley wrote:

> Are we using semantic versioning, or just making up numbers?

In my personal experience, there's nothing to dislike about semantic
versioning. Which, BTW, we should also be using in libpng, but we don't,
because of legacy, but we will, from post-1.6 libpng onwards.

> So, what should we call this current, official, version?

As I understand the SemVer rules, it should not be called 3.0.4. That would
be the kind of SemVer breach that the present-day libpng is also guilty of.
You should make it at least 3.1, or 3.1.0, or (if you wish to account for
the rather significant new features) bump it all the way to 4.0.

Sincerely,
Cosmin

Re: [png-mng-implement] pngcheck, live at https://github.com/pnggroup/pngcheck

[Chris L. <ch...@w3...>]

On 2025-02-19 21:07, John Bowler wrote:
> The current pnggroup copy lost my last PR (the one that changed (char 
> *) into (const char *)), I assume that is deliberate but just in case.

Not deliberate. Although, your PR [1] did briefly close when I merged 
another PR without seeing that you had a PR against it on the same 
branch. But I un-deleted the branch and merged it.

[1] https://github.com/pnggroup/pngcheck/pull/18

-- 
Chris Lilley
@svg...@ma...
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

Re: [png-mng-implement] pngcheck, live at https://github.com/pnggroup/pngcheck

[John B. <joh...@gm...>]

On Wed, Feb 19, 2025 at 2:29 PM Chris Lilley <ch...@w3...> wrote:

>
> So, what should we call this current, official, version?
>

I don't think it matters much what you call it.  The issue is that the
version operating system distributions use is most likely to come from here:

http://www.libpng.org/pub/png/apps/pngcheck.html

The tar archive there is "version 3.0.3 of 25 April 2021", and that is what
is installed on gentoo ~dev and Ubuntu.  I can confirm that gentoo gets the
archive from libpng.org, I don't know about Ubuntu.

The current pnggroup copy lost my last PR (the one that changed (char *)
into (const char *)), I assume that is deliberate but just in case.

John Bowler

Re: [png-mng-implement] pngcheck, live at https://github.com/pnggroup/pngcheck

[Chris L. <ch...@w3...>]

On 2025-02-18 19:43, Cosmin Truta wrote:
> As of the time of this writing, the main README file says "pngcheck 
> unofficial of 03 Feb 2025", because it started as Chris' private fork 
> in his own account at GitHub before having it transferred wholesale to 
> the PNG Group's account. But make no mistake, this is as official as 
> it gets!

So, what should we call this current, official, version?

Are we using semantic versioning, or just making up numbers?

-- 
Chris Lilley
@svg...@ma...
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

[png-mng-implement] pngcheck, live at https://github.com/pnggroup/pngcheck

[Cosmin T. <ct...@gm...>]

Hello, again,

When I wrote in my previous email about being twice as happy to make
software release announcements, I haven't actually counted my extra reasons
to be absolutely ecstatic:

I had the honour to reconstruct a large part of the history of development
of the pngcheck program, thanks to Greg Roelofs who graciously shared his
offline archive containing most of the original files with original
timestamps(!!)

And then, I had the honour to merge this reconstructed history (let's call
it "the old history", which ended at pngcheck v3.0.3) with Chris Lilley's
new development branch (let's call it "the new history", which started at
pngcheck v3.0.3, not at all coincidentally).

https://github.com/pnggroup/pngcheck

As of the time of this writing, the main README file says "pngcheck
unofficial of 03 Feb 2025", because it started as Chris' private fork in
his own account at GitHub before having it transferred wholesale to the PNG
Group's account. But make no mistake, this is as official as it gets!

--

Fun fact #1: The earliest surviving file is pngcheck version 1.2 by
Alexander Lehmann, from 13th of March 1995, checking compliance against PNG
draft 9. Not compatible with PNG 1.0, just so you know.
To anybody out there who stumbles upon pngcheck version 1.1 or version 1.0:
please, do come forward.

Fun fact #2: Before taking over officially from Alexander Lehmann and
Andreas Dilger, Greg maintained his own unofficial forks (suffixed with
"grr"), which you can find in the reconstructed Git history. Point being:
the present-day "unofficial-yet-official" pngcheck is not the first-ever
"unofficial-yet-official" pngcheck :-)

--

Sincerely,
Cosmin

[png-mng-implement] libpng 1.6.47 released

[Cosmin T. <ct...@gm...>]

Hello there, hi everyone,

I am twice as happy as usual to announce the release of libpng 1.6.47
earlier today plus the release of libpng 1.6.46 about four weeks ago -- I
forgot to announce it back then. (Oopsie!)

After we started shipping new features from the draft Third Edition of the
PNG Specification in v1.6.45 (the cICP chunk), we continued that in v1.6.46
(the mDCV and cLLI chunks). And now, in v1.6.47, we finalized the
modification of the colorspace behavior in order to make it fully
conformant to this latest and greatest spec.

https://github.com/pnggroup/libpng/tree/v1.6.47/
https://sourceforge.net/projects/libpng/files/libpng16/1.6.47/
https://raw.githubusercontent.com/pnggroup/libpng/v1.6.47/ANNOUNCE

Many thanks to John Bowler for delivering us all this PNG-3 goodness!

--

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published files:

libpng-1.6.47.tar.gz
084115c62fe023e3d88cd78764a4d8e89763985ee4b4a085825f7a00d85eafbb

libpng-1.6.47.tar.xz
b213cb381fbb1175327bd708a77aab708a05adde7b471bc267bd15ac99893631

lpng1647.7z
3af4549c7dce3e234dc683b6b75cbaaf4f4c95b39c5efb3cd1b6ff5aff5c98f9

lpng1647.zip
883340209fccd5353e406a79e22a2d226fc61666b83e700ab1e367bc1a679101

--

Sincerely,
Cosmin

Re: [png-mng-implement] 1.6.45 - non-C89 variable declaration at png.c:1547

[John B. <joh...@gm...>]

On Mon, Jan 20, 2025 at 6:37 AM Martin Burke <bur...@gm...> wrote:

> In png_XYZ_from_xy(), `int error = 0` not at beginning of scope.
>

Thanks for the report here and #641 on github; yes, github gets faster
responses, at least from me.   Fixed along with another set of non-ANSIisms
by #642.

John Bowler

[png-mng-implement] 1.6.45 - non-C89 variable declaration at png.c:1547

[Martin B. <bur...@gm...>]

In png_XYZ_from_xy(), `int error = 0` not at beginning of scope.

[png-mng-implement] libpng-1.6.45 released and signed with a new key

[Cosmin T. <ct...@gm...>]

Hello, everyone!

I tagged the newest libpng release in the 1.6 line two days ago. It would
have been business-as-usual, and it mostly is, except for this unexpected
"meta-announcement":

** IMPORTANT ** NEW PGP PUBLIC KEY **
https://github.com/ctruta.gpg

If anybody wants to know what happened to the old key, my answer is this: I
know where the old public key is, but I honestly don't know about the
private one. Or about its revocation certificate, for that matter. I wiped
out wrong files, wrong directories, and even a wrong drive AND backup drive
in the past, and I'll probably do some more of that in the future, so you
can trust me.

Ergo, brand new PGP signing, from libpng 1.6.45 onwards, with my brand new
key. Have I mentioned that you can trust me?

*****

And now, back to our business-as-usual announcement.

Thanks to the work of Lucas Chollet and John Bowler, we are on our way to
supporting the Third Edition of the PNG Specification. In v1.6.45 we bring
forth the support for cICP, which is a colorspace chunk.

https://www.w3.org/TR/png-3/#cICP-chunk

https://github.com/pnggroup/libpng/tree/v1.6.45/
https://sourceforge.net/projects/libpng/files/libpng16/1.6.45/
https://raw.githubusercontent.com/pnggroup/libpng/v1.6.45/ANNOUNCE

In the good old tradition of file authentication, here are the SHA-2-256
checksums of the published files:

libpng-1.6.45.tar.gz
7dee9e1ca8152bf52f919456f4190330aee48209887f2ec0b3d9f0ad571df11b

libpng-1.6.45.tar.xz
926485350139ffb51ef69760db35f78846c805fef3d59bfdcb2fba704663f370

lpng1645.7z
6a69737cceeabcdd50e78743caf3e38612fcb2ebb3f6e3b37c99931ad983b32b

lpng1645.zip
a66c4b1350b67776e90263e2550933067cd9ccbd318db489f84dcc0d2b033249

--

Sincerely,
Cosmin

Re: [png-mng-implement] libpng-1.6.41, live at its OFFICIAL HOME https://github.com/pnggroup/libpng

[John B. <joh...@gm...>]

On Sat, Nov 2, 2024 at 11:45 AM * Neustradamus * <neu...@ho...>
wrote:

> - https://github.com/glennrp/libpng-releases


This is an artefact of the prior approaches to source control.  It's
perhaps of historical interest so might be a candidate for inclusion in the
github archival project (if it isn't already) but even that seems
unnecessary complexity; all the "tags" in that project should exist in the
current pnggroup/libpng project and, because of the way Glenn did this, the
source tree should be identical to the tarball.

At present this approach is in the process of being abandoned, or maybe
already has been abandoned, in pnggroup/libpng; instead the source tree is
no longer identical to the distribution tarball and, I believe, the
distribution tarballs are only on sourceforge and *not*, so far as I can
see, on github.  A quick look at sourceforge suggests that it does contain
a historical record at least back to "0.71" (i.e. effectively 0.0.71 in the
new numbering scheme.)  Consequently that seems the right place to go to
for authoritative historical copies.

>
> - https://github.com/glennrp/pmt


These are Glenn's private projects; nothing to do with libpng.  The last
update was to pngcrush 7 years ago.

JBowler

Re: [png-mng-implement] libpng-1.6.41, live at its OFFICIAL HOME https://github.com/pnggroup/libpng

[* N. * <neu...@ho...>]

Dear PNG team, Cosmin Truta,

Have you progressed for the migration of 2 latest repos into pnggroup organization?
- https://github.com/glennrp/libpng-releases
- https://github.com/glennrp/pmt

Last steps after the success of https://github.com/glennrp/libpng -> https://github.com/pnggroup/libpng that I have requested a long time ago.

Thanks in advance.

Regards,

Neustradamus

________________________________________
From: * Neustradamus * <neu...@ho...>
Sent: Saturday, January 27, 2024 18:39
To: PNG/MNG implementation discussion list; jb...@ac...
Subject: Re: [png-mng-implement] libpng-1.6.41, live at its OFFICIAL HOME https://github.com/pnggroup/libpng

The bad repo is a full copy (a double), after the 5 issue transfers, the repo can be removed.

Regards,

Neustradamus
________________________________________
From: John Bowler <joh...@gm...>
Sent: Saturday, January 27, 2024 00:51
To: PNG/MNG implementation discussion list
Subject: Re: [png-mng-implement] libpng-1.6.41, live at its OFFICIAL HOME https://github.com/pnggroup/libpng

On Thu, Jan 25, 2024 at 3:04 AM Andrew Randrianasulu
<ran...@gm...> wrote:
> may be archive it instead of removing?

I.e. so far as I could understand from your message (I strongly
suggest editing the email before sending it) this refers to the repo
that was, originally, pnggroup/libpng and Cosmin renamed to
pnggroup/libpng-see-issue-2

Nah.  Delete it.

After careful review the repo contains nothing of merit; @thealberto
and @jmckenna might disagree.  The pull requests have all been closed
and I am perfectly happy for all traces to disappear; @adamjrichter's
very valid point was, IRC, acknowledged in the relevant commits, yet
of course he may care to comment.


_______________________________________________
png-mng-implement mailing list
png...@li...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

_______________________________________________
png-mng-implement mailing list
png...@li...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: [png-mng-implement] IHDR libpng error on width > 1, 000, 000 pixels

[John B. <joh...@gm...>]

On Tue, Oct 22, 2024 at 6:17 AM s.samociuk via png-mng-implement <
png...@li...> wrote:

> libpng warning: Image width exceeds user limit in IHDR libpng error:
> Invalid IHDR data Aborted (core dumped)
>
You didn't set up an error handler, which is fine if you want your program
to do SIGABRT when an error is detected.

You control the width/height limit at run time by calling
*png_set_user_limits*.  If you didn't build libpng yourself the
default values can be found in *pnglibconf.h* in the
*PNG_USER_{HEIGHT,WIDTH}_MAX* #defines.  The value in the
PNG file is a PNG unsigned integer so it can't exceed 2,147,483,647

If you build libpng the default value is configured in *pngusr.dfa*  That's
a sample file which shows some of the
security related limits but you can set the above ones there too.

John Bowler

[png-mng-implement] IHDR libpng error on width > 1,000,000 pixels

[s.samociuk <s.s...@bt...>]

I am converting large raw data to image files using Ubuntu Linux. Works 
fine up to and including 1,000,000 pixels wide. Over this, eg 1,000,001, 
I get an error:

libpng warning: Image width exceeds user limit in IHDR libpng error: 
Invalid IHDR data Aborted (core dumped)

Just wondering if there is a test in libpng if(width > 1000000) error

Thanks

All works well up to 1000000 limit and no problems with memory.

Re: [png-mng-implement] libpng version 2.0, anyone?

[John B. <joh...@gm...>]

>
> Any thoughts?
>

Numbers are cheap.  It doesn't mean they can't be meaningful.

So far the definitions have worked sort-of.  I'll use Vincent's use of
"major.minor" but I don't ascribe such significance to the words.  As
Cosmin seems to observe we have been stuck with "1".  Stuck at first base
as my fellow countrymen say.

The 1.x would have worked if they were a *fixed* ABI with a *fixed* API.
However over time the tendency emerged to fix bugs by adding ABIs and the
corresponding API.  That doesn't work because an ABI has to be fixed to
allow distribution of binaries; a binary ABI guarantees compile-once, use
anywhere.  The ABI might have bugs, even security level bugs, in some
versions but the app which uses it need not care because, gee, if the user
didn't fix their system they keep the bug!  Unfortunately with libpng if
you try that your app crashes.  So ABIs need to be fixed at some level.
This is what I believe was always intended by, in Vincent's terms, a
"minor" release.  ABI fixed, won't change until the next minor release.

If this is made true minor releases become functional, useful and
productive.  In a "minor" release the ABI changes, the API expands, maybe
changes a little, but adapting to it is pretty much a set of "minor" code
changes for app writers.  Indeed, since numbers are free, a minor release
can just be an ABI change with no meaningful API change; where the ABI
change is hidden by function-like macros.

But that doesn't mean we may not dream.  Maybe there will be libpng-2.0.

John Bowler <jbowler @ acm.org>

Re: [png-mng-implement] libpng version 2.0, anyone?

[Cosmin T. <ct...@gm...>]

Hi,

It's still me, thinking out loud.

About Vicent's complaint about this being "complicated", and my reply "the
v1 doesn't actually matter":

libpng-1.2 was, for all practical intents and purposes, version 2. (Second
version, coming after the first one.) Then we dropped libpng-1.3 because of
DLL versioning, and we jumped over to libpng-1.4, which was, in a way,
version 4. Then libpng-1.5, which was, in a way, version 5. Then
libpng-1.6, etc.

We are still at libpng-1.8 alpha, and I was thinking about moving to
libpng-2; and then, about moving more easily to libpng-3; and then,
about... having to jump versions at 10 and 12 and 14 15 16...

### HOW ABOUT WE DROP THE "1"

How about we do it like they did it with Java:

Java 1.2 became J2SE
...
Java 1.5 became J5SE
Java SE 6 followed Java 1.5.

So, libpng-8 could follow libpng-1.6, after we skipped over libpng-1.7.

And then, we could tell the community of libpng users at large:

*_We don't want to break the PNG-supporting apps, so we don't want to break
the API compatibility, so we want to stay forever at "version one", so we
drop the "one"._*

***The current libpng version 1.8 will become libpng version 8.***
***The next libpng version, to be introduced at the next ABI change, will
be libpng version 9.***

***Et cetera.***

Any thoughts?

Sincerely,
Cosmin

Re: [png-mng-implement] libpng version 2.0, anyone?

[Cosmin T. <ct...@gm...>]

On Sat, Sep 21, 2024 at 8:37 AM Vincent Torri <vin...@gm...> wrote:
> i think that it is overcomplicated. For the last 25 years or so, major
> version has not change, and current minor version is only 6 (libpng
> 1.6.0 was released in 2013 btw. 20 years). In 2050, minor version
> would be between 10 and 20. Not a big deal.

As I said in the introduction to this note: it was simple for the
libpng users, but extremely complicated for us the libpng developers.
Every new feature addition, no matter how little, feels like
navigating a minefield.

Look, Vincent, libpng is libpng, which is libpng, which is, also,
libpng. Applications shouldn't care (too much) about the version
numbers, as long as they continue to run after a libpng upgrade.
Sticking to "v1" forever is just wasting version numbers. For all I
know, libpng version 1.6 could have just as well been called "version
6".

One last thing about the claim that it's "overcomplicated". On the
contrary: I want the libpng versioning to be **simplified** by
introducing semantic versioning.

> Imho, If you don't want to break API, you should continue with 1.x versioning.

When I said that we didn't break the source API, I should have
clarified that we DID break the binary interface (the ABI) every time
from 1.0 to 1.2 to 1.4 to 1.5 and finally to 1.6. And we're about to
do it again with the new 1.8 branch.

Also, we didn't break the source API in awfully disruptive ways, but
we did break it in subtle ways, and sometimes, in not-so-subtle ways
(e.g. from 1.2 to 1.4 to 1.5 when many applications had to be fixed).

> DLL name should be libpng-$major.dll (libtool and meson is doing so,
> lot's of cmake-based projects too). It's a very clear and
> straightforward way to say that api has not changed. Same for mac :
> libpng.$major.dylib.

Exactly!

We can achieve that with my proposed transition to libpng-2, but we
absolutely couldn't with libpng-16 and earlier. So next time there's
an ABI change, or a minor but non-trivial API breakage, then we should
move to libpng-3, then libpng-4, etc.

We cannot achieve that with the current versioning scheme.

> What i would like for png is smaller files, fast decompression.

I, for one, would like to land my own improvements in file size, which
I've been maintaining separately in my own project (named OptiPNG),
and I'm talking about lossless image reductions. Very unfortunately,
due to the extreme backwards compatibility promises that we made (and
kept!!) any new feature addition automatically becomes a new mine on
the above-mentioned minefield.

I wholeheartedly invite you to contribute a code review to this PR:
https://github.com/pnggroup/libpng/pull/565
FYI I already landed it in libpng-1.8, even though it needs some
trimming, and some fixing too -- I hereby invite you to a friendly
challenge: to figure out how to fix and/or how to simplify this pull
request.

Sincerely,
Cosmin

Re: [png-mng-implement] libpng version 2.0, anyone?

[Vincent T. <vin...@gm...>]

Hello

> libpng.2.dylib and libpng.2.0.dylib (on Mac), libpng.so.2 and libpng.so.2.0 (elsewhere on Unix). New features added? Upgrade to libpng-2.1. A patchlevel release to v2.1, with no new features added? Upgrade to libpng-2.1.1. More patchlevel releases, security fixes, etc? Upgrade to libpng-2.1.2, libpng-2.1.3, etc. Keep going until the next new PNG feature support comes in libpng, when it's time to upgrade to libpng-2.2. The compiled library name remains unchanged, i.e. libpng2.dll and libpng.2.dylib and libpn
> ... until we break ABI compatibility again for some reason, just as we did it less than a handful of times in more than a quarter-century. That would be the time for us to move up to libpng-3.0 and libpng3.dll, etc. And so on and so forth, to libpng-4.0 and libpng4.dll etc., etc.
>
> Let us not forget to skip far-in-the-future libpng versions entirely, such us libpng version 10.0, and also version 12.0, and also version 14.0 and 15.0 and 16.0. I would suggest transitioning from version 8.x to version 9.0, and then, from version 9.x to version 20.0, and then, from version 20.x to version 21.0; but that should be another story for another century.

i think that it is overcomplicated. For the last 25 years or so, major
version has not change, and current minor version is only 6 (libpng
1.6.0 was released in 2013 btw. 20 years). In 2050, minor version
would be between 10 and 20. Not a big deal.

Imho, If you don't want to break API, you should continue with 1.x versioning.

DLL name should be libpng-$major.dll (libtool and meson is doing so,
lot's of cmake-based projects too). It's a very clear and
straightforward way to say that api has not changed. Same for mac :
libpng.$major.dylib. You can also install headers in
include/libpng-$major.minor for parallal installations.

What i would like for png is smaller files, fast decompression.
Unfortunately, this part of the (W3C at least) standard has not change
*at all* since the beginning. We are in 2024 and only deflate is
proposed. Zstd would be a good candidate (with parallal compression
and decompression). And if libpng adopts an additional compression
scheme, maybe the standard would change... But I guess that this
change will not come soon.

You can maybe consider more asm (avx, neon, arm, only sse2 is used for
filters if i'm not mistaken). This work could be funded (Germany’s
Sovereign Tech Fund or Microsoft's Free and Open Source Software Fund,
for example)

my 2 cents

best regards

Vincent Torri

Re: [png-mng-implement] libpng version 2.0, anyone?

[John B. <joh...@gm...>]

On Fri, Sep 20, 2024 at 2:29 PM Chris Lilley <ch...@w3...> wrote [
*emphasis* added]:

>
> John, please do not spread misinformation.
>
> W3C has a policy to always make specs freely available at no cost - to
> everyone, not just to the people involved in making them.
> *That is not "some version" it is the official and definitive version.*
>

Really?  I thought PNG was an ISO/IEC standard, i.e. this standard:

https://www.iso.org/standard/29581.html

Not that I've ever seen that standard as it costs more than my yearly pay.
I completely agree with
your aims. However perhaps you can explain why the W3C is now the
authoritative organisation.
The position of ISO/IEC seems somewhat counter productive if W3C is the
authority; they should
at least mention on that web page that you are in charge, even if they
don't say that you don't charge.

The OP did, in fact, ask about sRGB; a core part of the web because in
practice all images embedded
in web pages are constrained to be sRGB and the colours in CSS are sRGB, so
"W3C has a policy to
always make specs freely available *at not cost*".  Nevertheless I find
after searching for the copy of the
sRGB spec on the W3C web site (exactly what the OP asked for):

https://www.w3.org/Graphics/Color/sRGB.html

I'm not blaming you, I suspect we do, in fact, speak pretty much exactly
the same language.  I'm not
blaming the W3C.  The problem is somewhat intractable.  I'm criticising.
Personally I much prefer
criticism to put downs; I've found people who criticise what I say are most
often correct, at least on
this list.

Re: [png-mng-implement] libpng version 2.0, anyone?

[Chris L. <ch...@w3...>]

On 2024-09-19 22:19, John Bowler wrote:

> This applies to the W3C PNGv3 too; the W3C might make some version 
> available on their web site but there will be an official version 
> somewhere that costs money.

John, please do not spread misinformation.

W3C has a policy to always make specs freely available at no cost - to 
everyone, not just to the people involved in making them. That is not 
"some version" it is the official and definitive version.

https://www.w3.org/standards/

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

Re: [png-mng-implement] libpng version 2.0, anyone?

[John B. <joh...@gm...>]

>
> Also, I found draft of IEC61966-2-1   somewhere along libpng historical
> documents, but it really was very early draft. Can anyone email me
> non-draft version? :)
>

You can get it here:

https://webstore.iec.ch/en/publication/6169

Someone could send you that but the document is copyright.  People who
participated in the process do *not* get copies of the final version unless
they pay (all these documents cost around $250 each; the actual price is
190 swiss francs.)  In other words it is illegal to do what you are asking.

This applies to the W3C PNGv3 too; the W3C might make some version
available on their web site but there will be an official version somewhere
that costs money.  The current TR also requires other subsidiary documents
which are, each, 190CHF or so and, indeed, haven't been released yet (so
get the WDs while you can!)   As of this moment it looks like the final
spec will cost over $1,000 US, including all required subsidiary documents,
but I'm just guessing.  Many years ago (last millennium)  I quizzed a major
party in the sRGB stuff (the spec you mention) about whether it would be
available for FOSS developers (i.e. cost no more than we are paid) and he
asserted he was working on making it so.  Plus ça change, plus c'est la
même chose.

Re: [png-mng-implement] libpng version 2.0, anyone?

[John B. <joh...@gm...>]

There are several discussions on github:pnggroup about the issues raised by
the new WC3 spec, some raised by me, some by Chris Blume (I think, his
login names are maybe not as clear as mine).  Chris is the W3C PNG head at
this point.  Also at this point most of the issues seem to have been
resolved including the APNG one.  One issue remains because I haven't
raised it on github:pnggroup; only on the W3C mailing list.  It does not
seem to be an issue for libpng at this moment.

John Bowler <jb...@ac...>