Re: libpng-1.4.0 coming soon (but not today)

[Glenn Randers-Pehrson]

Having not received any positive feedback about libpng-1.4.0rc01
or about the libpng-1.4.0beta series, let alone 3-5 of them, I'm
holding off on release for now.

I wish we could get iTXt support out, though.  It's about 8 or 10
years overdue.

Does anyone think it would be a good idea to spend some effort
on figuring out how to implement iTXt chunk support in 1.2.x in
a binary-compatible manner?  I think it can be done but would
involve some ugliness with a new *SUPPORTED macro or two.
We cannot use the libpng-1.2.x png_text struct so would have
to invent a new one, e.g., png_itxt, that would look like
the existing png_text struct when PNG_iTXt_SUPPORTED is
enabled, and then some care to make sure it is ABI-compatible
with existing builds made with and without PNG_iTXt_SUPPORTED,
and still allows a clean migration to 1.4.0 which does *not* use
this new struct.

This should all be transparent to the casual user, but will
add complexity for those who look at the source.  There's also
a good possibliity that I'll get it wrong.

I think some of the other stuff in 1.4.0 or planned for 1.4.0
could be added to 1.2.x, as long as we are still allowed to
*add* new functions and png_struct members.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Thu, 29 Oct 2009, Glenn Randers-Pehrson wrote:

> Having not received any positive feedback about libpng-1.4.0rc01
> or about the libpng-1.4.0beta series, let alone 3-5 of them, I'm
> holding off on release for now.

I think that this is probably a wrong decision.  It is true that
libpng users feel inundated with minor releases but it is also true
that it takes several years for a major library release to make it
into stable OS distributions.  Given that you expect to be interested
in, and capable of, mantaining libpng for a few more years, and if you
feel that the 1.4.0 code and interfaces are ready, it is wise to make
a release so that it can start feeding the "raw" and "experimental"
distributions of various OSs.  This way you will start to receive
useful feedback and bug reports.  It will be at least a full two years
before the new release makes into stable distributions.

Hardly anyone tests alpha and beta releases any more.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

>> Having not received any positive feedback about libpng-1.4.0rc01
>> or about the libpng-1.4.0beta series, let alone 3-5 of them, I'm
>> holding off on release for now.

> I think that this is probably a wrong decision.  It is true that
> libpng users feel inundated with minor releases but it is also true
> that it takes several years for a major library release to make it
> into stable OS distributions.

Yeah, but it's also true that various end-user developers will grab a
new release and start playing with it and testing it with their pet
project(s); that's what freshmeat announcements are all about.  And it
may be doubly true of a major new release.  Any basic problems will
just emphasize the bad reputation that the SF voting seems to indicate.
(I am aware that the voters are self-selected, of course; I'd guess
most projects' votes are biased toward the negative because of this.)

> Given that you expect to be interested
> in, and capable of, mantaining libpng for a few more years, and if you
> feel that the 1.4.0 code and interfaces are ready, it is wise to make
> a release so that it can start feeding the "raw" and "experimental"
> distributions of various OSs.

I disagree.  If we can't get at least 3-5 test reports out of THIS GROUP,
we may as well take down the shingle and give up on real releases.  That's
pretty sad.

> Hardly anyone tests alpha and beta releases any more.

That's true, but this is a release candidate for a major release, so I
think we can and should expect a little more.  I don't have time right
now, but I'd like to make sure the pngbook utilities still build in place,
which I suspect is no longer the case due to the removal of the MMX API.
(If so, it should need only a tweak to an ifdef, and maybe Glenn has even
done that in some previous beta, but maybe not, too.)  And Vincent already
tested and reported a build problem for WinCE, which sounded fixable.

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Thu, 29 Oct 2009, Greg Roelofs wrote:
> may be doubly true of a major new release.  Any basic problems will
> just emphasize the bad reputation that the SF voting seems to indicate.
> (I am aware that the voters are self-selected, of course; I'd guess
> most projects' votes are biased toward the negative because of this.)

The SF votes are entirely meaningless and should be ignored.

>> Given that you expect to be interested in, and capable of,
>> mantaining libpng for a few more years, and if you feel that the
>> 1.4.0 code and interfaces are ready, it is wise to make a release
>> so that it can start feeding the "raw" and "experimental"
>> distributions of various OSs.
>
> I disagree.  If we can't get at least 3-5 test reports out of THIS
> GROUP, we may as well take down the shingle and give up on real
> releases.  That's pretty sad.

It is definitely wise for people here to take the responsibility to
test the library and report any issues prior to a release.

Glenn is into retirement age now.  If the 1.4 code is not released
while he is still capable and willing to maintain the release then it
seems likely that the 1.4 code will never get released, and will be
more of his work which gets sidelined or ignored.  We should be more
responsible and supportive due to our respect for the considerable
work that Glenn has put into libpng (and MNG) over many years.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Thu, Oct 29, 2009 at 13:47, Glenn Randers-Pehrson <glennrp@...> wrote:
> Having not received any positive feedback about libpng-1.4.0rc01
> or about the libpng-1.4.0beta series, let alone 3-5 of them, I'm
> holding off on release for now.

Hello,

Yesterday I've tried the rc01 with my png++ project.

It gives one compilation error due to use of deprecated function
png_set_gray_1_2_4_to_8() which is easily fixed by changing the call
to png_set_expand_gray_1_2_4_to_8().  If I then do `make check' it
fails 4 tests (out of 134) and I didn't yet have a minute to figure
out why.

So (for my test coverage) the compatibility with 1.2 is pretty good. :)

> I wish we could get iTXt support out, though.  It's about 8 or 10
> years overdue.

What strikes me most is that realized I don't really know what 1.4 is all about.

There's no page (not even a single paragraph!) on the official site
dedicated to version 1.4.  I've searched through site map, then used
yahoo and google, and all I get for 1.4 is a few pages listing
versions of apps with PNG image support.  Google gives 0 (zero) pages
for "libpng 1.4" when searching libpng.org...

Now, I think the answer should be somewhere in the mailing list, but
SourceForge search is broken, so not till another time it works.

I might be missing something, but it would be nice if someone could
enlighten me or just point to where I could read about motivation for
1.4 and features planned for it.

If people demanded a new version, if it was long awaited (8 years you
say?) I don't see why with so many betas you didn't get any feedback.

Without knowing better, I can only speculate, so I'll think stop now. :)

--
Kind regards,
Alex

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Thu, Oct 29, 2009 at 22:27, Alexander Shulgin <alex.shulgin@...> wrote:
>
> Without knowing better, I can only speculate, so I'll think stop now. :)

A-ha, just spotted your other mail describing what I need to know....

Sorry for being a bit too jumpy. ;)

--
Alex

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[John Bowler-3]

From: Alexander Shulgin [mailto:alex.shulgin@...]
>Yesterday I've tried the rc01 with my png++ project.
>
>It gives one compilation error due to use of deprecated function
>png_set_gray_1_2_4_to_8() which is easily fixed by changing the call
>to png_set_expand_gray_1_2_4_to_8().

I believe the correct change is to png_set_tRNS_to_alpha - this does the same transformations as png_set_gray_1_2_4_to_8 (and the png_set_expand function does not.)

The same problem exists in the projects fbida, vtk and, most significantly, kdelibs.

John Bowler <jbowler@...>



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Thu, Oct 29, 2009 at 22:27, Alexander Shulgin <alex.shulgin@...> wrote:

> On Thu, Oct 29, 2009 at 13:47, Glenn Randers-Pehrson <glennrp@...> wrote:
>> Having not received any positive feedback about libpng-1.4.0rc01
>> or about the libpng-1.4.0beta series, let alone 3-5 of them, I'm
>> holding off on release for now.
>
> Hello,
>
> Yesterday I've tried the rc01 with my png++ project.
>
> It gives one compilation error due to use of deprecated function
> png_set_gray_1_2_4_to_8() which is easily fixed by changing the call
> to png_set_expand_gray_1_2_4_to_8().  If I then do `make check' it
> fails 4 tests (out of 134) and I didn't yet have a minute to figure
> out why.

I've identified the problem.

Most of my test cases consist of reading a test image into memory
while performing certain read transformations, then saving it to disk
and comparing the result with the predefined 'correct' output.

The 'unexpected' output with libpng14 is produced in cases where a
16-bit per color component image without alpha channel is converted to
16-bit image with alpha channel (G -> GA, G -> RGBA, RGB -> GA, RGB ->
RGBA).  The differing bits are the low-order bytes of the added alpha
channel words.

My code supplies 0xFFFF as the alpha filler in the above case, and
images produced with libpng14 got this value correct.  But my standard
images for corresponding tests obtained with libpng12 have the
incorrect 0xFF00 in the differing positions.

Would you like a minimal test case for this problem to help it get fixed?

--
Regards,
Alex

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Sun, Nov 1, 2009 at 12:01, John Bowler
<john.cunningham.bowler@...> wrote:

> From: Alexander Shulgin [mailto:alex.shulgin@...]
>>Yesterday I've tried the rc01 with my png++ project.
>>
>>It gives one compilation error due to use of deprecated function
>>png_set_gray_1_2_4_to_8() which is easily fixed by changing the call
>>to png_set_expand_gray_1_2_4_to_8().
>
> I believe the correct change is to png_set_tRNS_to_alpha - this does the same transformations as png_set_gray_1_2_4_to_8 (and the png_set_expand function does not.)
>
> The same problem exists in the projects fbida, vtk and, most significantly, kdelibs.

It's not the case for my code, though. :)

I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
the new pngconf.h.  Would the following do the trick?

#if PNG_LIBPNG_VER >= 10400

--
Alex

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Tue, Nov 3, 2009 at 5:19 AM, Alexander Shulgin
<alex.shulgin@...> wrote:

> On Sun, Nov 1, 2009 at 12:01, John Bowler
> <john.cunningham.bowler@...> wrote:
>> From: Alexander Shulgin [mailto:alex.shulgin@...]
>>>Yesterday I've tried the rc01 with my png++ project.
>>>
>>>It gives one compilation error due to use of deprecated function
>>>png_set_gray_1_2_4_to_8() which is easily fixed by changing the call
>>>to png_set_expand_gray_1_2_4_to_8().
>>
>> I believe the correct change is to png_set_tRNS_to_alpha - this does the same transformations as png_set_gray_1_2_4_to_8 (and the png_set_expand function does not.)
>>
>> The same problem exists in the projects fbida, vtk and, most significantly, kdelibs.
>
> It's not the case for my code, though. :)
>
> I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
> the new pngconf.h.  Would the following do the trick?
>
> #if PNG_LIBPNG_VER >= 10400
>

        Yes.

        Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Tue, Nov 3, 2009 at 5:19 AM, Alexander Shulgin
<alex.shulgin@...> wrote:


> I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
> the new pngconf.h.

Should we define PNG_1_4_X in libpng-1.4.0/pngconf.h as a migration
aid, even though we don't (and won't) use it internally?

Also, should we distribute a zero-length pngpriv.h in 1.2.x/1.0.x to
minimize the difference between the 1.0.x/1.2.x makefiles and
the 1.4.0 makefiles?

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

>> I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
>> the new pngconf.h.

> Should we define PNG_1_4_X in libpng-1.4.0/pngconf.h as a migration
> aid, even though we don't (and won't) use it internally?

Nope.  As long as there's a way for apps to generate such a symbol on
their own, there's no need for us to define two of them.

> Also, should we distribute a zero-length pngpriv.h in 1.2.x/1.0.x to
> minimize the difference between the 1.0.x/1.2.x makefiles and
> the 1.4.0 makefiles?

Nope.

"Minimize the crap."

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Tue, Nov 3, 2009 at 4:07 PM, Greg Roelofs <newt@...> wrote:

>> Also, should we distribute a zero-length pngpriv.h in 1.2.x/1.0.x to
>> minimize the difference between the 1.0.x/1.2.x makefiles and
>> the 1.4.0 makefiles?
>
> Nope.
>
> "Minimize the crap."

Well, when bouncing between 1.2.x and 1.4.x when building pngcrush,
the zero-length pngpriv.h allows me to avoid having two different
makefiles.  Multiply that by a few other apps and it seems to me that
the zero-length pngpriv.h minimizes the crap.

It would also greatly simplify maintenance of the makefiles in the scripts
directory.

 diff *12* *14*
1c1
< # makefile for libpng.a and libpng12.so on Linux ELF with gcc
---
> # makefile for libpng.a and libpng14.so on Linux ELF with gcc
5c5
<
---
> #
11,13c11,13
< LIBNAME = libpng12
< PNGMAJ = 0
< PNGMIN = 1.2.41beta13
---
> LIBNAME = libpng14
> PNGMAJ = 14
> PNGMIN = 1.4.0beta92
21,22c21,22
< OLDSOMAJ=libpng.so.3
< OLDSOVER=libpng.so.3.$(PNGMIN)
---
> OLDSOMAJ=libpng.so.14
> OLDSOVER=libpng.so.14.$(PNGMIN)
32,33c32,33
< # where "make install" puts libpng12.a, libpng12.so*,
< # libpng12/png.h and libpng12/pngconf.h
---
> # where "make install" puts libpng14.a, libpng14.so*,
> # libpng14/png.h and libpng14/pngconf.h
54c54
< CFLAGS=-I$(ZLIBINC) -W -Wall -O3 -funroll-loops -DPNG_NO_MMX_CODE \
---
> CFLAGS=-I$(ZLIBINC) -W -Wall -O3 -funroll-loops \
57c57
< LDFLAGS=-L. -Wl,-rpath,. -L$(ZLIBLIB) -Wl,-rpath,$(ZLIBLIB) -lpng12 -lz -lm
---
> LDFLAGS=-L. -Wl,-rpath,. -L$(ZLIBLIB) -Wl,-rpath,$(ZLIBLIB) -lpng14 -lz -lm
102c102
<       -e s!-lpng12!-lpng12\ -lz\ -lm! > libpng.pc
---
>       -e s!-lpng14!-lpng14\ -lz\ -lm! > libpng.pc
110c110
<       echo libs=\"-lpng12 -lz -lm\"; \
---
>       echo libs=\"-lpng14 -lz -lm\"; \
237,251c237,251
< png.o png.pic.o: png.h pngconf.h
< pngerror.o pngerror.pic.o: png.h pngconf.h
< pngrio.o pngrio.pic.o: png.h pngconf.h
< pngwio.o pngwio.pic.o: png.h pngconf.h
< pngmem.o pngmem.pic.o: png.h pngconf.h
< pngset.o pngset.pic.o: png.h pngconf.h
< pngget.o pngget.pic.o: png.h pngconf.h
< pngread.o pngread.pic.o: png.h pngconf.h
< pngrtran.o pngrtran.pic.o: png.h pngconf.h
< pngrutil.o pngrutil.pic.o: png.h pngconf.h
< pngtrans.o pngtrans.pic.o: png.h pngconf.h
< pngwrite.o pngwrite.pic.o: png.h pngconf.h
< pngwtran.o pngwtran.pic.o: png.h pngconf.h
< pngwutil.o pngwutil.pic.o: png.h pngconf.h
< pngpread.o pngpread.pic.o: png.h pngconf.h
---

> png.o png.pic.o: png.h pngconf.h pngpriv.h
> pngerror.o pngerror.pic.o: png.h pngconf.h pngpriv.h
> pngrio.o pngrio.pic.o: png.h pngconf.h pngpriv.h
> pngwio.o pngwio.pic.o: png.h pngconf.h pngpriv.h
> pngmem.o pngmem.pic.o: png.h pngconf.h pngpriv.h
> pngset.o pngset.pic.o: png.h pngconf.h pngpriv.h
> pngget.o pngget.pic.o: png.h pngconf.h pngpriv.h
> pngread.o pngread.pic.o: png.h pngconf.h pngpriv.h
> pngrtran.o pngrtran.pic.o: png.h pngconf.h pngpriv.h
> pngrutil.o pngrutil.pic.o: png.h pngconf.h pngpriv.h
> pngtrans.o pngtrans.pic.o: png.h pngconf.h pngpriv.h
> pngwrite.o pngwrite.pic.o: png.h pngconf.h pngpriv.h
> pngwtran.o pngwtran.pic.o: png.h pngconf.h pngpriv.h
> pngwutil.o pngwutil.pic.o: png.h pngconf.h pngpriv.h
> pngpread.o pngpread.pic.o: png.h pngconf.h pngpriv.h

253c253
< pngtest.o: png.h pngconf.h
---
> pngtest.o: png.h pngconf.h pngpriv.h


With a zero-length pngpriv.h, about half of the diff would go
away, and similarly in many of the other makefiles.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Greg Roelofs]

> Well, when bouncing between 1.2.x and 1.4.x when building pngcrush,
> the zero-length pngpriv.h allows me to avoid having two different
> makefiles.  Multiply that by a few other apps and it seems to me that
> the zero-length pngpriv.h minimizes the crap.

_Apps_ should not be using pngpriv.h.  Yours violates the rules, so of
course you're going to feel the pain, but no one else even sees pngpriv.h
because it's not installed.  (Right?)  Ergo, no pain.

> It would also greatly simplify maintenance of the makefiles in the scripts
> directory.

It should be a one-time change.  Thereafter it becomes relevant only if you
add a new source file via diffs, but that's rare--and exceedingly so in the
case of the not-current version, which generally should be seeing only
security fixes, not new files and makefile changes.  Where else is maintenance
affected?

Even if it were otherwise affected, I think you'd have to do some fast
talking to justify uglification of every user's installation in order to
simplify the maintainer's life.  That's just not a very clean approach
to development.

> With a zero-length pngpriv.h, about half of the diff would go
> away, and similarly in many of the other makefiles.

You could equally well have set up the dependencies so the pngpriv.h one
lives on its own line, e.g.:

$(LIBPNG_OBJS):  pngpriv.h

Nobody ever said you have to have all of a file's dependencies on the same
line.

Greg

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[John Bowler]

From: Alexander Shulgin [mailto:alex.shulgin@...]

>John Bowler:
>> I believe the correct change is to png_set_tRNS_to_alpha -
>>this does the same transformations as png_set_gray_1_2_4_to_8
>>(and the png_set_expand function does not.)
>>
>> The same problem exists in the projects fbida, vtk and, most
>>significantly, kdelibs.
>
>It's not the case for my code, though. :)
>
>I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
>the new pngconf.h.  Would the following do the trick?

You shouldn't need to do this.  Either simply change every call to png_set_gray_1_2_4_to_8 to a call to png_set_tRNS_to_alpha if you really do want the behavior of the old png_set_gray_1_2_4_to_8 or, if you just want the 'expand' without the possibly spurious insertion of an alpha channel change it to png_set_expand_gray_1_2_4_to_8.

All of these APIs, and png_set_expand and png_set_palette_to_rgb (which do the exact same thing as png_set_tRNS_to_alpha) exist in both 1.2 and 1.4 - no conditional compilation required.

Perhaps 'png_set_expand' has the most meaningful name among the many possibilities to convert to 8 bit RGBA.

Johnn Bowler <jbowler@...>



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

> _Apps_ should not be using pngpriv.h.  Yours violates the rules, so of
> course you're going to feel the pain, but no one else even sees pngpriv.h
> because it's not installed.  (Right?)  Ergo, no pain.

My app doesn't use or refer to anything in pngpriv.h.  But the makefile
builds an embedded libpng and therefore needs to know about pngpriv.h.
Other apps (e.g. mozilla/firefox) build embedded libpngs, too, and their
makefiles will have to account for pngpriv.h one way or another.

But, no big deal, I can deal with it, although I still think migration aids
are generally a good thing.

>> It would also greatly simplify maintenance of the makefiles in the scripts
>> directory.
>
> It should be a one-time change.  Thereafter it becomes relevant only if you
> add a new source file via diffs, but that's rare--and exceedingly so in the
> case of the not-current version, which generally should be seeing only
> security fixes, not new files and makefile changes.  Where else is maintenance
> affected?

Over the years I've had to modify about 30 scripts/makefiles, and the
fact that one version has to deal with pngpriv.h and the other doesn't
just adds discomfort.  But again, I can deal with it.

> Even if it were otherwise affected, I think you'd have to do some fast
> talking to justify uglification of every user's installation in order to
> simplify the maintainer's life.  That's just not a very clean approach
> to development.

Right.  I'll remove the empty pngpriv.h from libpng-1.2.x

>> With a zero-length pngpriv.h, about half of the diff would go
>> away, and similarly in many of the other makefiles.
>
> You could equally well have set up the dependencies so the pngpriv.h one
> lives on its own line, e.g.:
>
> $(LIBPNG_OBJS):  pngpriv.h
>
> Nobody ever said you have to have all of a file's dependencies on the same
> line.

I am maintaining makefiles for lots of different platforms, that all handle
things slightly differently.  And I'm not a makefile guru.  I just try to keep
the donated makefiles running.

Glenn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Wed, Nov 4, 2009 at 01:25, John Bowler <jbowler@...> wrote:

> From: Alexander Shulgin [mailto:alex.shulgin@...]
>>John Bowler:
>>> I believe the correct change is to png_set_tRNS_to_alpha -
>>>this does the same transformations as png_set_gray_1_2_4_to_8
>>>(and the png_set_expand function does not.)
>>>
>>> The same problem exists in the projects fbida, vtk and, most
>>>significantly, kdelibs.
>>
>>It's not the case for my code, though. :)
>>
>>I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
>>the new pngconf.h.  Would the following do the trick?
>
> You shouldn't need to do this.  Either simply change every call to png_set_gray_1_2_4_to_8 to a call to png_set_tRNS_to_alpha if you really do want the behavior of the old png_set_gray_1_2_4_to_8 or, if you just want the 'expand' without the possibly spurious insertion of an alpha channel change it to png_set_expand_gray_1_2_4_to_8.
>
> All of these APIs, and png_set_expand and png_set_palette_to_rgb (which do the exact same thing as png_set_tRNS_to_alpha) exist in both 1.2 and 1.4 - no conditional compilation required.
>
> Perhaps 'png_set_expand' has the most meaningful name among the many possibilities to convert to 8 bit RGBA.

Thanks for explanation.

Now I can see that my testbed is plainly missing images with tRNS
chunk.  If I add some such images how do I instruct libpng that I want
them expanded to 8 bits per color component but w/o expanding tRNS?

I think I could simply pass PNG_EXPAND to png_read_png, but how can I
do the same using low-level read interface?  A call to png_set_expand
would still add PNG_EXPAND_tRNS.

--
Alex

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Wed, Nov 4, 2009 at 2:56 AM, Alexander Shulgin
<alex.shulgin@...> wrote:

> On Wed, Nov 4, 2009 at 01:25, John Bowler <jbowler@...> wrote:
>> From: Alexander Shulgin [mailto:alex.shulgin@...]
>>>John Bowler:
>>>> I believe the correct change is to png_set_tRNS_to_alpha -
>>>>this does the same transformations as png_set_gray_1_2_4_to_8
>>>>(and the png_set_expand function does not.)
>>>>
>>>> The same problem exists in the projects fbida, vtk and, most
>>>>significantly, kdelibs.
>>>
>>>It's not the case for my code, though. :)
>>>
>>>I've tried to #ifdef the problematic line, but there's no PNG_1_4_X in
>>>the new pngconf.h.  Would the following do the trick?
>>
>> You shouldn't need to do this.  Either simply change every call to png_set_gray_1_2_4_to_8 to a call to png_set_tRNS_to_alpha if you really do want the behavior of the old png_set_gray_1_2_4_to_8 or, if you just want the 'expand' without the possibly spurious insertion of an alpha channel change it to png_set_expand_gray_1_2_4_to_8.
>>
>> All of these APIs, and png_set_expand and png_set_palette_to_rgb (which do the exact same thing as png_set_tRNS_to_alpha) exist in both 1.2 and 1.4 - no conditional compilation required.
>>
>> Perhaps 'png_set_expand' has the most meaningful name among the many possibilities to convert to 8 bit RGBA.
>
> Thanks for explanation.
>
> Now I can see that my testbed is plainly missing images with tRNS
> chunk.  If I add some such images how do I instruct libpng that I want
> them expanded to 8 bits per color component but w/o expanding tRNS?
>
> I think I could simply pass PNG_EXPAND to png_read_png, but how can I
> do the same using low-level read interface?  A call to png_set_expand
> would still add PNG_EXPAND_tRNS.
>

I believe (but haven't tested) that png_set_expand_gray_1_2_4_to_8()
will also expand sub-8-bit indexed images to 8-bit-indexed without
expanding tRNS.  There ought to be a png_set_expand_1_2_4_indexed_to_8()
synonym for png_set_expand_1_2_4_to_8().

But the transformation from 8-bit-indexed-with-tRNS to 8-bit RGB-with
tRNS that you want seems to be missing.  Such a transformation would of
course have to require that all non-255 tRNS values be 0 and point to
the same RGB color.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[John Bowler]

From: Alexander Shulgin [mailto:alex.shulgin@...]
>Now I can see that my testbed is plainly missing images with tRNS
>chunk.  If I add some such images how do I instruct libpng that I want
>them expanded to 8 bits per color component but w/o expanding tRNS?
>
>I think I could simply pass PNG_EXPAND to png_read_png, but how can I
>do the same using low-level read interface?  A call to png_set_expand
>would still add PNG_EXPAND_tRNS.

Yes, just PNG_EXPAND, using png_set_expand_gray_1_2_4_to_8.  By UTSL on pngrtran.c(png_read_transform_info):

PNG_EXPAND: (!PNG_EXPAND_tRNS)
                palette -> 8 bit rgb
                1/2/4 bit gray -> 8 bit gray
                rgb/gray/rgba/ga -> min 8 bit rgb/gray/rgba/ga
                In all cases tRNS is stripped/ignored
  (png_set_expand_gray_1_2_4_to_8)

PNG_EXPAND: +PNG_EXPAND_tRNS
                palette -> 8 bit rgb
                palette+tRNS -> 8 bit rgba
                rgb/gray/rgba/ga -> min 8 bit rgb/gray/rgba/ga
                rgb/gray + tRNS -> min 8 bit rgba/ga
  (png_set_expand, png_set_palette_to_rgb, [png_set_gray_1_2_4_to_8], png_set_tRNS_to_alpha)
               
PNG_EXPAND_tRNS: has no effect
  (impossible to set on its own via a low level function)

PNG_GRAY_TO_RGB:  1/2/4/8 bit gray/ga -> 1/2/4/8 bit rgb/rgba
                        others: unchanged
  (png_set_gray_to_rgb)

Note that calling png_set_gray_to_rgb on a 1,2 or 4 bit per sample gray image will lead to invalid results unless I missed something in my code examination.  (libpng won't crash, the transform just gets ignored, but info_ptr seems to have bogus information.)

John Bowler <jbowler@...>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Alexander Shulgin-2]

On Wed, Nov 4, 2009 at 20:19, John Bowler <jbowler@...> wrote:

> From: Alexander Shulgin [mailto:alex.shulgin@...]
>>Now I can see that my testbed is plainly missing images with tRNS
>>chunk.  If I add some such images how do I instruct libpng that I want
>>them expanded to 8 bits per color component but w/o expanding tRNS?
>>
>>I think I could simply pass PNG_EXPAND to png_read_png, but how can I
>>do the same using low-level read interface?  A call to png_set_expand
>>would still add PNG_EXPAND_tRNS.
>
> Yes, just PNG_EXPAND, using png_set_expand_gray_1_2_4_to_8.  By UTSL on pngrtran.c(png_read_transform_info):
>
> PNG_EXPAND: (!PNG_EXPAND_tRNS)
>                palette -> 8 bit rgb
>                1/2/4 bit gray -> 8 bit gray
>                rgb/gray/rgba/ga -> min 8 bit rgb/gray/rgba/ga
>                In all cases tRNS is stripped/ignored
>  (png_set_expand_gray_1_2_4_to_8)

You are right, it can be done with png_set_expand_gray_1_2_4_to_8.  It
simply counter-intuitive to call it for indexed colors image.  I'm OK
with dropping tRNS in this case.

Maybe we can add a new function png_set_expand_1_2_4_to_8 to public
interface as suggested by Glenn, which will only set PNG_EXPAND?

--
Alex

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement