mewin/libpng
1
0
Fork 0
mirror of https://git.code.sf.net/p/libpng/code.git synced 2025-07-10 18:04:09 +02:00
Code Issues Projects Releases Wiki Activity

[devel] Update CHANGES and ANNOUNCE

Browse Source
This commit is contained in:
Glenn Randers-Pehrson 2011-05-18 21:44:37 -05:00
parent 5441e18988
commit 0a048923ae
3 changed files with 29 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
ANNOUNCE
View File

@ -1,5 +1,5 @@
Libpng 1.5.3beta10 - May 17, 2011
Libpng 1.5.3beta10 - May 19, 2011
This is not intended to be a public release. It will be replaced
within a few weeks by a public version or by another test version.
@ -134,7 +134,16 @@ Version 1.5.3beta09 [May 17, 2011]
do any gamma correction. Moving the tests back leaves the old, inaccurate,
8-bit gamma calculations, but these are clearly better than none!
Version 1.5.3beta10 [May 17, 2011]
Version 1.5.3beta10 [May 19, 2011]
png_set_background() and png_expand_16() did not work together correctly.
This problem is present in 1.5.2; if png_set_background is called with
need_expand false and the matching 16 bit color libpng erroneously just
treats it as an 8-bit color because of where png_do_expand_16 is in the
transform list. This simple fix reduces the supplied colour to 8-bits,
so it gets smashed, but this is better than the current behavior.
Added tests for expand16, more fixes for palette image tests to pngvalid.
Corrects the code for palette image tests and disables attempts to
validate palette colors.
Send comments/corrections/commendations to png-mng-implement at lists.sf.net:
(subscription required; visit

23
CHANGES
View File

@ -3389,13 +3389,24 @@ Version 1.5.3beta08 [May 16, 2011]
Minor cleanup and some extra checking in pngrutil.c and pngrtran.c
Version 1.5.3beta09 [May 17, 2011]
Reversed earlier 1.5.3 change of transformation order; move png_expand_16 back.
The change doesn't work because it requires 16-bit gamma tables when the code
only generates 8-bit ones. This fails silently; the libpng code just doesn't
do any gamma correction. Moving the tests back leaves the old, inaccurate,
8-bit gamma calculations, but these are clearly better than none!
Reversed earlier 1.5.3 change of transformation order; move png_expand_16
back where it was. The change doesn't work because it requires 16-bit
gamma tables when the code only generates 8-bit ones. This fails
silently; the libpng code just doesn't do any gamma correction. Moving
the tests back leaves the old, inaccurate, 8-bit gamma calculations, but
these are clearly better than none!
Version 1.5.3beta10 [May 17, 2011]
Version 1.5.3beta10 [May 19, 2011]
png_set_background() and png_expand_16() did not work together correctly.
This problem is present in 1.5.2; if png_set_background is called with
need_expand false and the matching 16 bit color libpng erroneously just
treats it as an 8-bit color because of where png_do_expand_16 is in the
transform list. This simple fix reduces the supplied colour to 8-bits,
so it gets smashed, but this is better than the current behavior.
Added tests for expand16, more fixes for palette image tests to pngvalid.
Corrects the code for palette image tests and disables attempts to
validate palette colors.
Send comments/corrections/commendations to png-mng-implement at lists.sf.net
(subscription required; visit

2
pngrtran.c
View File

@ -1434,7 +1434,7 @@ png_init_read_transformations(png_structp png_ptr)
{
/* TODO: fix this. Because the expand_16 operation is after the compose
* handling the background color must be 8, not 16, bits deep, but the
* application will supply a 16 bit value so reduce it here.
* application will supply a 16-bit value so reduce it here.
*
* The PNG_BACKGROUND_EXPAND code above does not expand to 16 bits at
* present, so that case is ok (until do_expand_16 is moved.)