Nabble - PNG MNG - Dev

libpng-1.4.0beta109 is available

2009-12-13T13:42:25Z

libpng-1.4.0beta109 is available from
ftp://ftp.simplesystems.org/pub/png-group/src
and from
libpng.sf.net/index.html

version 1.4.0beta109 [December 13, 2009]
Added "bit_depth" parameter to the private png_build_gamma_table() function.
Pass bit_depth=8 to png_build_gamma_table() when bit_depth is 16 but the
PNG_16_TO_8 transform has been set, to avoid unnecessary build of 16-bit
tables.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-13T10:50:44Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>The fix turns out to be trivial: add a "bit_depth" parameter to
>png_build_gamma_table(), and set that to 8 when the image
>is going to be chopped, to avoid unnecessary building of the
>16-bit gamma tables. This will also help us in the future
>(1.5.0) with the premultiplied alpha, which needs the 16-bit
>gamma tables even when the image has bit_depth 8 or less.
>
>This is, I think, simple enough to go in 1.4.0. I've put it in the
>GIT repository for 1.4.0beta109.

I agree - this is appropriate for 1.4 (not just 1.5) as it has not been
released yet.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-13T06:25:10Z

On Sat, Dec 12, 2009 at 11:51 PM, Glenn Randers-Pehrson
<glennrp@...> wrote:

> On Fri, Dec 11, 2009 at 1:36 PM, John Bowler <jbowler@...> wrote:
>
>> What I think is happening is that the tRNS processing is deferred until
>> png_do_background, so the tRNS chunk doesn't work if the chop happens
>> before. The correct fix seems to be to move the chop to between
>> png_do_background and png_do_gamma, and this should be done in 1.4 (I
>> think.)
>
> Yes that is what is happening. But it is not the "correct" fix because
> this forces the 16-bit gamma tables to be built even though the
> pixels will be later chopped.
>
> The correct fix, which will require some extensive code mods,
> is to separate png_do_background() so as to move the tRNS processing
> before the chop but the background gamma processing (and the
> gamma-table building) after.

The fix turns out to be trivial: add a "bit_depth" parameter to
png_build_gamma_table(), and set that to 8 when the image
is going to be chopped, to avoid unnecessary building of the
16-bit gamma tables. This will also help us in the future
(1.5.0) with the premultiplied alpha, which needs the 16-bit
gamma tables even when the image has bit_depth 8 or less.

This is, I think, simple enough to go in 1.4.0. I've put it in the
GIT repository for 1.4.0beta109.

Glenn

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-12T20:51:36Z

On Fri, Dec 11, 2009 at 1:36 PM, John Bowler <jbowler@...> wrote:

> What I think is happening is that the tRNS processing is deferred until
> png_do_background, so the tRNS chunk doesn't work if the chop happens
> before. The correct fix seems to be to move the chop to between
> png_do_background and png_do_gamma, and this should be done in 1.4 (I
> think.)

Yes that is what is happening. But it is not the "correct" fix because
this forces the 16-bit gamma tables to be built even though the
pixels will be later chopped.

The correct fix, which will require some extensive code mods,
is to separate png_do_background() so as to move the tRNS processing
before the chop but the background gamma processing (and the
gamma-table building) after.

At the same time we also want to be implementing the
integer gamma-table build.

Glenn

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-11T16:24:34Z

On Fri, Dec 11, 2009 at 1:36 PM, John Bowler <jbowler@...> wrote:
> I believe, therefore, that after
> 1.4.0 gets released any significant changes (even ones that are ABI
> compatible) should actually happen in 1.5 (weren't the 'odd' numbers
> intended for stablisation?)

OK, I agree. I bumped libpng-1.4.1alpha02 to 1.5.0alpha01 in the
GIT repository.

About even/odd releases, I forget which is which. I remember a
while back when everyone wanted their major release to be "7"
but I think that was just a passing fad.

Glenn

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-11T10:54:18Z

On Fri, Dec 11, 2009 at 1:36 PM, John Bowler <jbowler@...> wrote:
> From: Glenn Randers-Pehrson [mailto:glennrp@...]
>>Thanks. I'll revert the change in libng-1.2.42.
>
> Well... the problem doesn't happen in Chromium with 1.4.0 (which has the
> same change).

I don't think it would happen in any browser because they don't use
the bKGD chunk data.

> This also illustrates that the level of testing we need isn't going to
> happen until there is an official release.

We need a reftest/unittest that at least runs through all of the
pngsuite, composites them against a background, and compares
the result with another file containing the correct result.

Glenn

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-11T10:36:56Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>Thanks. I'll revert the change in libng-1.2.42.

Well... the problem doesn't happen in Chromium with 1.4.0 (which has the
same change).

What I think is happening is that the tRNS processing is deferred until
png_do_background, so the tRNS chunk doesn't work if the chop happens
before. The correct fix seems to be to move the chop to between
png_do_background and png_do_gamma, and this should be done in 1.4 (I
think.)

Making changes like this in 1.2 is probably a mistake since it's meant to be
stable.

This also illustrates that the level of testing we need isn't going to
happen until there is an official release. I believe, therefore, that after
1.4.0 gets released any significant changes (even ones that are ABI
compatible) should actually happen in 1.5 (weren't the 'odd' numbers
intended for stablisation?)

John Bowler <jbowler@...>

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

libpng-1.2.42beta02 is available

2009-12-11T05:46:19Z

libpng-1.2.42beta02 is available from
ftp://ftp.simplesystems.org/pub/png-group/src
and from
http://libpng.sf.net/index.html

version 1.2.42beta02 [December 11, 2009]
Removed leftover "-DPNG_CONFIGURE_LIBPNG" from contrib/pngminim/*/makefile
Relocated png_do_chop() to its original position in pngrtran.c; the
change in version 1.2.41beta08 caused transparency to be handled wrong
in some 16-bit datastreams (Yusaku Sugai).

Glenn

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: 3x16 bits rgb color background problem

2009-12-11T04:40:46Z

Thanks. I'll revert the change in libng-1.2.42.

Glenn

On Fri, Dec 11, 2009 at 3:09 AM, Yusaku Sugai <sugai@...> wrote:

> Hello libpng developers,
>
> I used libpng 1.2.41 and got a problem around background chunk.
> This may be a library bug.
>
> Symptom:
> The following two images
> tbgn2c16.png - transparent, green background chunk
> tbbn2c16.png - transparent, blue background chunk
> in PNG Test Suite(http://www.libpng.org/pub/png/pngsuite.html)
> shows on gray background.
> While they are supposed to be transparent.
> ,,,

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

3x16 bits rgb color background problem

2009-12-11T00:09:52Z

Hello libpng developers,

I used libpng 1.2.41 and got a problem around background chunk.
This may be a library bug.

Symptom:
The following two images
tbgn2c16.png - transparent, green background chunk
tbbn2c16.png - transparent, blue background chunk
in PNG Test Suite(http://www.libpng.org/pub/png/pngsuite.html)
shows on gray background.
While they are supposed to be transparent.

Environment:
libpng 1.2.41 static library NO ASM versions(both Debug/Release)
# untested on other versions
Visual C++ 2005
Windows7 Professional 64bit

What I've got so far:
I guess it is ill side effect of
Quote from CHANGE log:
> version 1.2.41beta08 [October 30, 2009]
> Relocated png_do_chop() ahead of building gamma tables in pngrtran.c
> This avoids building 16-bit gamma tables unnecessarily.

So, I moved png_do_chop() back to 'after building gamma tables' position.
Then everything looks fine for me.

Could anyone have a look at the matter, please?

--
Yusaku Sugai

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.4.0beta107 is available

2009-12-04T15:12:02Z

On Fri, Dec 4, 2009 at 4:42 PM, Greg Roelofs <newt@...> wrote:
>> version 1.4.0beta107 [December 4, 2009]
>> ... Also revised makefile.sco
>> to put them in $prefix/include/libpng12 instead of in
>> $prefix/include/libpng/libpng12.
>
> Personally, I would probably stick them in $prefix/include/libpng14, but I
> guess that's just me...

CHANGES fixed in GIT repo and future uploads. The makefile is
already OK. Good olde cut&paste got me again.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.4.0beta107 is available

2009-12-04T13:42:26Z

> version 1.4.0beta107 [December 4, 2009]
> Updated README
> Added "#define PNG_NO_PEDANTIC_WARNINGS" in the libpng source files.
> Removed "-DPNG_CONFIGURE_LIBPNG" from the makefiles and projects.
> Revised scripts/makefile.netbsd, makefile.openbsd, and makefile.sco
> to put png.h and pngconf.h in $prefix/include, like the other scripts,
> instead of in $prefix/include/libpng. Also revised makefile.sco
> to put them in $prefix/include/libpng12 instead of in
> $prefix/include/libpng/libpng12.

Personally, I would probably stick them in $prefix/include/libpng14, but I
guess that's just me...

;-)

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

libpng-1.4.0beta107 is available

2009-12-04T08:34:26Z

libpng-1.4.0beta107 is available from
ftp://ftp.simplesystems.org/pub/png-group/src
and from
http://libpng.sf.net/index.html

Just syncing with the 1.2.42beta01 changes, except that
PNG_PEDANTIC_WARNINGS is enabled by default:

version 1.4.0beta107 [December 4, 2009]
Updated README
Added "#define PNG_NO_PEDANTIC_WARNINGS" in the libpng source files.
Removed "-DPNG_CONFIGURE_LIBPNG" from the makefiles and projects.
Revised scripts/makefile.netbsd, makefile.openbsd, and makefile.sco
to put png.h and pngconf.h in $prefix/include, like the other scripts,
instead of in $prefix/include/libpng. Also revised makefile.sco
to put them in $prefix/include/libpng12 instead of in
$prefix/include/libpng/libpng12.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

libpng-1.2.42beta01 is available

2009-12-04T08:12:36Z

libpng-1.2.42beta01 is available from
ftp://ftp.simplesystems.org/pub/png-group/src
and from
http://libpng.sf.net/index.html

version 1.2.42beta01 [December 4, 2009]
Removed "#define PNG_NO_ERROR_NUMBERS" that was inadvertently added
to pngconf.h in version 1.2.41.
Revised scripts/makefile.netbsd, makefile.openbsd, and makefile.sco
to put png.h and pngconf.h in $prefix/include, like the other scripts,
instead of in $prefix/include/libpng. Also revised makefile.sco
to put them in $prefix/include/libpng12 instead of in
$prefix/include/libpng/libpng12.
Removed leftover "-DPNG_CONFIGURE_LIBPNG" from scripts/makefile.darwin

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-04T07:24:30Z

On Fri, Dec 4, 2009 at 9:52 AM, Bob Friesenhahn
<bfriesen@...> wrote:

> On Fri, 4 Dec 2009, Glenn Randers-Pehrson wrote:
>>
>> I introduced the mistake in libpng-1.2.41beta06. Someone should have
>> caught this during all the RC and beta testing.
>
> This assumes that anyone is actually testing advance releases.
> Perhaps what is needed is a core team of package maintainers who must
> affirm that they have inspected and tested the release candidate
> before a stable libpng can be cut. For example, if there are six
> official package maintainers, a +1 from three could be considered
> sufficient.

That's nice in theory. It's like Greg's suggestion of waiting for 3-5
positive responses. But projecting 0/week for any length of time
is still 0. So we will just continue along, with the betas and rcs
being ignored, and fixing bugs reported against the public releases.
No problem, except that there are consequently more public releases
than I would really like. It looks now as though 1.2.x will end with
1.2.42 (or 43, 44?) instead of the planned 1.2.40.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-04T06:57:01Z

On Fri, 4 Dec 2009, Bob Friesenhahn wrote:

maybe adding unit testing should be a good idea, especially for such a lib
like libpng. You can use the 'check' library for that.

Vincent Torri

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-04T06:52:34Z

On Fri, 4 Dec 2009, Glenn Randers-Pehrson wrote:
>
> I introduced the mistake in libpng-1.2.41beta06. Someone should have
> caught this during all the RC and beta testing.

This assumes that anyone is actually testing advance releases.
Perhaps what is needed is a core team of package maintainers who must
affirm that they have inspected and tested the release candidate
before a stable libpng can be cut. For example, if there are six
official package maintainers, a +1 from three could be considered
sufficient.

It seems that this particular problem could have been detected by an
appropriately-written test case, but this assumes the test case is not
also updated to remove the symbol.

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

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-04T04:44:26Z

On Fri, Dec 4, 2009 at 6:20 AM, Glenn Randers-Pehrson <glennrp@...> wrote:

> 2009/12/4 Aníbal Monsalve Salazar <anibal@...>:
>> On Thu, Dec 03, 2009 at 06:58:56AM -0500, Glenn Randers-Pehrson wrote:
>>>libpng-1.2.41 (and 1.0.51 for legacy applications) is available at
>>
>> When I build the Debian libpng package using the current version 1.2.41,
>> I found that the png_set_strip_error_numbe@@PNG12_0 isn't exported
>> anymore. With 1.2.40 that particular symbol was exported. Why the soname
>> didn't change?
>
> My mistake.
>
> It was supposed to be deleted from 1.4.0, not from 1.2.41

I introduced the mistake in libpng-1.2.41beta06. Someone should have
caught this during all the RC and beta testing.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-04T04:37:57Z

On Thu, Dec 3, 2009 at 10:34 PM, John Bowler <jbowler@...> wrote:

> From: Glenn Randers-Pehrson [mailto:glennrp@...]
>>I have received a suggestion that we put libpng/png.h alongside
>>libpngNN/png.h
>
>> Interestingly, several of our scripts/makefiles already
>> put png.h and pngconf in an include/libpng subdirectory
>> and not directly in the include directory.
>>
>> These are makefile.freebsd, makefile.netbsd, makefile.openbsd,
>> and makefile.sco

makefile.freebsd builds both $prefix/include/png.h and
$prefix/include/libpng/png.h

makefile.netbsd builds only $prefix/include/libpng/png.h

makefile.neNNbsd builds only $prefix/include/libpngNN/png.h

makefile.openbsd builds only $prefix/include/libpng/png.h

makefile.sco builds only $prefix/include/libpng/png.h

To fix in libpng-1.2.42 and 1.4.0:

makefile.freebsd -- leave as is or
build only $prefix/include/png.h ?
makefile.netbsd -- build only $prefix/include/png.h
makefile.neNNbsd -- leave as is (or combine netbsd
and neNNbsd)
makefile.openbsd -- build only $prefix/include/png.h
makefile.sco -- build only $prefix/include/png.h

In all of the above, "png.h" means "png.h and pngconf.h"

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-04T03:20:25Z

2009/12/4 Aníbal Monsalve Salazar <anibal@...>:
> On Thu, Dec 03, 2009 at 06:58:56AM -0500, Glenn Randers-Pehrson wrote:
>>libpng-1.2.41 (and 1.0.51 for legacy applications) is available at
>
> When I build the Debian libpng package using the current version 1.2.41,
> I found that the png_set_strip_error_numbe@@PNG12_0 isn't exported
> anymore. With 1.2.40 that particular symbol was exported. Why the soname
> didn't change?

My mistake.

It was supposed to be deleted from 1.4.0, not from 1.2.41

Glenn

> I fixed this bug in the Debian package with the patch below.
>
> --- a/pngconf.h 2009-12-03 12:46:00.000000000 +1100
> +++ b/pngconf.h 2009-12-04 13:00:58.000000000 +1100
> @@ -756,7 +756,6 @@
>
> #endif /* PNG_WRITE_SUPPORTED */
>
> -#define PNG_NO_ERROR_NUMBERS
> #ifndef PNG_1_0_X
> # ifndef PNG_NO_ERROR_NUMBERS
> # define PNG_ERROR_NUMBERS_SUPPORTED
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-03T21:00:35Z

On Thu, Dec 03, 2009 at 06:58:56AM -0500, Glenn Randers-Pehrson wrote:
>libpng-1.2.41 (and 1.0.51 for legacy applications) is available at

When I build the Debian libpng package using the current version 1.2.41,
I found that the png_set_strip_error_numbe@@PNG12_0 isn't exported
anymore. With 1.2.40 that particular symbol was exported. Why the soname
didn't change?

I fixed this bug in the Debian package with the patch below.

--- a/pngconf.h 2009-12-03 12:46:00.000000000 +1100
+++ b/pngconf.h 2009-12-04 13:00:58.000000000 +1100
@@ -756,7 +756,6 @@

#endif /* PNG_WRITE_SUPPORTED */

-#define PNG_NO_ERROR_NUMBERS
#ifndef PNG_1_0_X
# ifndef PNG_NO_ERROR_NUMBERS
# define PNG_ERROR_NUMBERS_SUPPORTED

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-03T19:45:00Z

On Thu, 3 Dec 2009, John Bowler wrote:

> From: Glenn Randers-Pehrson [mailto:glennrp@...]
>> I have received a suggestion that we put libpng/png.h alongside
>> libpngNN/png.h
>
> No, definitely not. To be portable application source code must know

+1 on this.

It is wrong for most applications to add the libpng include directory
to the source code include statements. It is much better for the
build environment to select the libpng version to use, and to add any
necessarily include options.

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

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-03T19:34:05Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>I have received a suggestion that we put libpng/png.h alongside
>libpngNN/png.h

No, definitely not. To be portable application source code must know
whether to write:

#include <png.h>

Or

#include <libpng/png.h>

At present applications write the former. An application writer should only
be expected to write one - the request implies that the desire is that apps
always use the second form. I don't think that is justified because libpng
is a core library in most operating systems.

The existence of libpngXX/png.h is a separate issue - apps only include that
qualified name if they intentionally depend on a particular major version.
That allows app writers to intentionally bind particular releases of their
code to particular versions of libpng. It also allows system builders and
configure script writers to select from multiple versions using
-I${INC}/libpngXX in CFLAGS. As such this is orthogonal to the correct
place to find png.h.

> Interestingly, several of our scripts/makefiles already
> put png.h and pngconf in an include/libpng subdirectory
> and not directly in the include directory.
>
> These are makefile.freebsd, makefile.netbsd, makefile.openbsd,
> and makefile.sco

And OpenBSD is broken in the way I describe - it is necessary to add (on my
OpenBSD system) -I/usr/local/include/libpng to get a libpng using program to
compile.

That doesn't justify the workround, because the workround just breaks every
other operating system equally.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-03T15:05:09Z

On Thu, Dec 3, 2009 at 5:15 PM, Vincent Torri <vtorri@...> wrote:

>
> if you plan to have the possibility to have at the same time libpng 1.0
> 1.2 and 1.4, then i would suggest to have different .pc files for each of
> the versions

I am pretty sure we do already, at least when the files are
built with "configure". I see

$prefix/bin/libpng.pc
$prefix/bin/libpng12.pc

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-03T14:15:33Z

On Thu, 3 Dec 2009, Glenn Randers-Pehrson wrote:

> I have received a suggestion that we put libpng/png.h alongside
> libpngNN/png.h
>
> Right now for a specified target path/to/nclude directory we create
>
> path/to/include/png.h, pngconf.h
> path/to/include/libpng10/png.h, pngconf.h
> path/to/incolde/libpng12/png.h.,pngconf.h
> path/to/include/libpng14/png.h, pngconf.h
>
> If we add /path/to/include/libpng/png.h, pngconf.h, should
> we remove or keep /path/to/include/png.h, pngconf.h ?
>
> They are just symlinks so they don't cost much.
>
> If we add them should I reissue libpng-1.2.41 with
> these links added? Or go through the whole
> beta->rc->release thing with libpng-1.2.42 ?
>
> It's not a 100% trivial change that I could really
> do overnight without making a mistake in configure.ac,
> Makefile.am, scripts/makefile.*, CMakeLists.txt, and
> the project directiries, but I'm willing to give it a
> try.

if you plan to have the possibility to have at the same time libpng 1.0
1.2 and 1.4, then i would suggest to have different .pc files for each of
the versions

Vincent

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng/png.h

2009-12-03T14:14:45Z

----- Original Message -----
From: "Glenn Randers-Pehrson" <glennrp@...>
To: "PNG/MNG implementation discussion list" <png-mng-implement@...>
Sent: Thursday, December 3, 2009 4:58:26 PM GMT -05:00 US/Canada Eastern
Subject: [png-mng-implement] libpng/png.h

I have received a suggestion that we put libpng/png.h alongside
libpngNN/png.h

Interestingly, several of our scripts/makefiles already
put png.h and pngconf in an include/libpng subdirectory
and not directly in the include directory.

These are makefile.freebsd, makefile.netbsd, makefile.openbsd,
and makefile.sco

I haven't checked the projects to see what they do.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

libpng/png.h

2009-12-03T13:58:26Z

I have received a suggestion that we put libpng/png.h alongside
libpngNN/png.h

Right now for a specified target path/to/nclude directory we create

path/to/include/png.h, pngconf.h
path/to/include/libpng10/png.h, pngconf.h
path/to/incolde/libpng12/png.h.,pngconf.h
path/to/include/libpng14/png.h, pngconf.h

If we add /path/to/include/libpng/png.h, pngconf.h, should
we remove or keep /path/to/include/png.h, pngconf.h ?

They are just symlinks so they don't cost much.

If we add them should I reissue libpng-1.2.41 with
these links added? Or go through the whole
beta->rc->release thing with libpng-1.2.42 ?

It's not a 100% trivial change that I could really
do overnight without making a mistake in configure.ac,
Makefile.am, scripts/makefile.*, CMakeLists.txt, and
the project directiries, but I'm willing to give it a
try.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: libpng-1.2.41 is available

2009-12-03T09:13:45Z

The new xcode project was inadvertently omitted from the lpng1241.* files.
I've just now uploaded new ones to fix this.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

libpng-1.2.41 is available

2009-12-03T03:58:56Z

libpng-1.2.41 (and 1.0.51 for legacy applications) is available at
ftp://ftp.simplesystems.org/pub/png/src
and at
http://libpng.sf.net/index.html

Please direct any replies to png-mng-implement@...

The changes since 1.2.40:

Moved redundant IHDR checking into new png_check_IHDR() in png.c
and report all errors found in the IHDR data.
Eliminated useless call to png_check_cHRM() from pngset.c
Expanded TAB characters in pngrtran.c
Added "xcode" project similar one already in libpng-1.4.0beta (Alam Arias).
Eliminated a shadowed declaration of "pp" in png_handle_sPLT().
Revised pngconf.h to make it easier to enable iTXt support. From libpng
version 1.2.9 through 1.2.40, defining PNG_iTXt_SUPPORTED did not work
as expected.
Converted all PNG_NO_* tests to PNG_*_SUPPORTED everywhere except pngconf.h
Changed many "#if defined(x)" to "#ifdef x" and fixed some indentation.
Added png_calloc() as a non-exported function.
Relocated png_do_chop() ahead of building gamma tables in pngrtran.c
This avoids building 16-bit gamma tables unnecessarily.
Removed a harmless extra png_set_invert_alpha() from pngwrite.c
Bugfixes and improvements to CMakeLists.txt (Philip Lowman)
Moved CMakeLists.txt from scripts into the main libpng directory.
Patched ltmain.sh for wince support.
Added PNG_CONVERT_tIME_SUPPORTED macro.
Make inclusion of time.h in pngconf.h depend on PNG_CONVERT_tIME_SUPPORTED
Updated scripts/pngw32.def and projects/wince/png32ce.def
Copied projects/wince/png32ce.def to the scripts directory.
Added scripts/makefile.cegcc
Added PNG_DEPSTRUCT, PNG_DEPRECATED, PNG_USE_RESULT, PNG_NORETURN, and
PNG_ALLOCATED macros to detect deprecated direct access to the
png_struct or info_struct members and other deprecated usage in
applications (John Bowler).
Removed three direct references to read_info_ptr members in pngtest.c
that were detected by the new PNG_DEPSTRUCT macro.
Marked deprecated function prototypes with PNG_DEPRECATED.
Marked memory allocation function prototypes with PNG_ALLOCATED.
Changed png_check_sig() to !png_sig_cmp() in contrib programs.
Corrected the png_get_IHDR() call in contrib/gregbook/readpng2.c
Marked nonexported functions with PNG_PRIVATE macro.
Revised scripts/*.def to reflect functions actually exported by libpng.
Updated the copyright year in scripts/pngw32.rc from 2004 to 2009.
Moved descriptions of makefiles and other scripts out of INSTALL into
scripts/README.txt
Rebuilt the configure scripts with autoconf-2.65
Disabled the new pedantic warnings about deprecated function use and
deprecated structure access unless the user defines PNG_PEDANTIC_WARNINGS.
Added "#define PNG_NO_PEDANTIC_WARNINGS" in the libpng source files.
Updated the list of files and made some cosmetic changes in README.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: Segfault in pngwio.c in png_default_write_data

2009-12-03T03:04:05Z

Dear John,

>> I get a segfault in pngwio.c in
>> png_default_write_data(png_structp png_ptr, png_bytep data, png_size_t
>>
> length)
>
>> at position
>> check = fwrite(data, 1, length, (png_FILE_p)(png_ptr->io_ptr));
>>
>> it seems that pointers are valid.
>>
>> Anyone an idea?
>>
>
> The (FILE*) being passed to fwrite is of a different type to that which
> fwrite expects - make sure the C runtime library used to build the libpng
> DLL matches that used to build the hp2xx application.
>
> Generally you need to assume that any Windows application that passes C
> library data to a DLL is built to support multithreading and you need to
> match 'debug' app builds with 'debug' DLLs.
>

Thanks! That's it. The project file in hp2xx came with runtime library
multithreaded (MT switch) and libpng and zlib with multithreaded dll (MD
switch). Now, it's working perfectly :)

Best regards

Rainer

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: Segfault in pngwio.c in png_default_write_data

2009-12-02T10:48:33Z

>I get a segfault in pngwio.c in
>png_default_write_data(png_structp png_ptr, png_bytep data, png_size_t
length)
>at position
> check = fwrite(data, 1, length, (png_FILE_p)(png_ptr->io_ptr));
>
>it seems that pointers are valid.
>
>Anyone an idea?

The (FILE*) being passed to fwrite is of a different type to that which
fwrite expects - make sure the C runtime library used to build the libpng
DLL matches that used to build the hp2xx application.

Generally you need to assume that any Windows application that passes C
library data to a DLL is built to support multithreading and you need to
match 'debug' app builds with 'debug' DLLs.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Segfault in pngwio.c in png_default_write_data

2009-12-02T10:08:34Z

Hi all,

I downloaded hp2xx and libpng1.2.4 to compile all under Vista with MSVC2008.
When I run hp2xx to convert a hgl file to png, I get a segfault in
pngwio.c in
png_default_write_data(png_structp png_ptr, png_bytep data, png_size_t
length)
at position
check = fwrite(data, 1, length, (png_FILE_p)(png_ptr->io_ptr));
The debugger says
> libpng13d.dll!png_default_write_data(png_struct_def *
png_ptr=0x00293898, unsigned char * data=0x0012f338, unsigned int
length=0x00000008) Zeile 59 + 0x19 Bytes C

it seems that pointers are valid.

Anyone an idea?

Best regards,

Rainer

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

Re: Testing alpha compositing in HTML

2009-11-27T21:49:39Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>Anyhow, I revised the page to do what you were trying to do, namely
>put a white background behind the 50% transparent black image and a black
>background behind the 50% transparent white image.

Ok, that's what I expected (feared) I would see.

Windows IE: ignores the spec wrt alpha compositing, it's not taking into
account the gamma, so every 50% square comes out as rgb(128,128,128). The
opaque squares are correct.

Windows Chromium: gAMA 1/2.2 is broken (have they emulated the original
Windows IE bug?) <tr> seems to be incompatible with IE (the image is
displayed displaced maybe 5px upwards relative to IE, leaving bands below.)
Otherwise as IE.

Linux(gentoo) Midori, Konqueror, Chromium: all identical to Windows IE.
(This is a more recent build of Chromium than my Windows one.)

So we can say that every browser so far ignores the PNG spec with regard to
alpha composition.

While that explains why web pages look so crummy it doesn't help us much.

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

Re: libpng-1.4.1alpha01 in alpha branch of GIT repository

2009-11-27T20:34:07Z

On Fri, Nov 27, 2009 at 10:19 PM, Glenn Randers-Pehrson
<glennrp@...> wrote:

> Now all the 50% transparent ones look the same but are very dark.

I added a second table in which the background is rgb(128,128,128)
to the test page at
<hhtp:www.simplesystems.org/users/glennrp/alpha_demo/>
and with that, both of the 50%transparent compositions seem to be a
perfect match (although incorrect).

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

Re: Testing alpha compositing in HTML

2009-11-27T20:11:19Z

On Fri, Nov 27, 2009 at 10:12 PM, John Bowler <jbowler@...> wrote:
> Attached is another version of this HTML test file. My (limited)
> understanding of the cavernous grottos of HTML suggests that this should
> behave as Glenn originally suggested - all the table cells should be
> rgb(192,192,192) (well, maybe rgb(186,186,186) as this is mid level gray if
> gamma is 0.45454).
>
> Unfortunately the results are inexplicable, particularly the 'black' column
> - is there a problem in this piece of HTML?

It appears that you lost the style settings for the cell colors and all cells
ended up having rgb(80,80,80) behind the images.

Anyhow, I revised the page to do what you were trying to do, namely
put a white background behind the 50% transparent black image and a black
background behind the 50% transparent white image.

The resulting composited patches are still too dark but they are all
alike.

Glenn

> BTW, this depends on Glenn's original test images - if he changes those the
> page will break.
>
> 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
>
>

------------------------------------------------------------------------------
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