133 lines
5.1 KiB
Plaintext
133 lines
5.1 KiB
Plaintext
|
|
Known bugs and suggested enhancements in libpng-1.0.6
|
|
|
|
1. April 24, 2000 -- BUG -- binary incompatibility
|
|
|
|
Libpng-1.0.6 is binary incompatible with old applications that
|
|
allocate the png_struct and png_info structures themselves instead
|
|
of using png_create_*(). They do not allocate enough space for
|
|
the structures because they have an incorrect notion of
|
|
sizeof(png_struct) and sizeof(png_info). Although such applications
|
|
should be considered broken rather than considering libpng to be broken,
|
|
they are numerous and include products of the PNG group, such
|
|
as gif2png and pnmtopng-2.36 (pnmtopng-2.37 is OK), so libpng will
|
|
be fixed in version 1.0.7 to work around this problem.
|
|
|
|
Applications that use png_create_*() instead of png_ptr=malloc(...)
|
|
are immune to this problem.
|
|
|
|
STATUS: Fixed in libpng-1.0.6ad, libpng-1.0.6i, and patch-d
|
|
which are currently being tested by the PNG group.
|
|
The fix necessarily reintroduces a binary incompatibility with any
|
|
application that makes direct access to the png_info and
|
|
png_struct members that deal with the pCAL chunk, palette_lookup,
|
|
dither_index, time_buffer, or weighted filtering, i.e., any members
|
|
coming after the new "free_me" member of either structure. It
|
|
is believed that applications affected by this reintroduced binary
|
|
incompatibility are rare (none are known to the PNG group). An
|
|
effective workaround for this and the next bug is to recompile the
|
|
old applications with the installed version of libpng.
|
|
|
|
2. April 23, 2000 -- BUG -- binary incompatibility
|
|
|
|
Libpng-1.0.6 introduced binary incompatibility for applications that
|
|
make direct access to members of the png_struct and png_info structures,
|
|
due to the insertion of the free_me member ahead of some previously
|
|
existing members.
|
|
|
|
Applications that use png_set_*(), png_get_*() are immune to this
|
|
problem, but people are still to this day writing applications that
|
|
make ill-advised direct access to members of the png_struct and
|
|
png_info structures, so libpng-1.0.6 will be patched to work around
|
|
this problem.
|
|
|
|
STATUS: Fixed in libpng-1.0.6g and patch-d, which are currently being
|
|
tested by the PNG group. Users can work around the problem without
|
|
patching libpng by recompiling their applications.
|
|
|
|
3. April 15, 2000 -- BUG -- pnggccrd.c
|
|
|
|
If PNG_NO_GLOBAL_ARRAYS is defined, pnggccrd.c will not compile.
|
|
|
|
STATUS: Fixed in libpng-1.0.6g
|
|
|
|
4. April 1, 2000 -- BUG
|
|
|
|
Under some circumstances old applications that make direct access to
|
|
the info_ptr->text and its members might free the same memory that
|
|
is also free'ed by libpng during the png_destroy_struct process.
|
|
|
|
Fixed in libpng-1.0.6-patch-c and libpng-1.0.6d. The PNG_FREE_TEXT flag
|
|
bit in info_ptr->free_me is now checked to make sure libpng is responsible
|
|
for freeing the memory.
|
|
|
|
5. April 1, 2000 -- BUG
|
|
|
|
The non-ISO-C "strdup()" function is used in png.c
|
|
|
|
STATUS: The function has been simplified and no longer uses strdup()
|
|
in libpng-1.0.6-patch-c and libpng-1.0.6d.
|
|
|
|
6. March 24, 2000 -- BUG
|
|
|
|
The png_set_rgb_to_gray_fixed() function is setting incorrect weighting
|
|
factors.
|
|
|
|
STATUS: Fixed in libpng-1.0.6-patch-b and libpng-1.0.6d.
|
|
|
|
7. March 22, 2000 -- BUG
|
|
|
|
There are some printf() and fprintf() statements active in pngwutil.c
|
|
when PNG_NO_STDIO and PNG_sCAL_SUPPORTED are both defined.
|
|
|
|
STATUS: Fixed in libpng-1.0.6-patch-a and libpng-1.0.6d. The strcpy()
|
|
function is used instead.
|
|
|
|
8. March 22, 2000 -- BUG
|
|
|
|
The length of the iCCP chunk data is calculated incorrectly; because
|
|
it can contain zeroes, strlen() doesn't work.
|
|
|
|
STATUS: Fixed in libpng-1.0.6-patch-a and libpng-1.0.6d by adding a
|
|
data_length parameter to the png_decompress_chunk() function.
|
|
|
|
9. March 15, 1998 -- OPTIMIZATION -- Kevin Bracey
|
|
|
|
Loops need to be optimized everywhere
|
|
|
|
Make them count down instead of up -- Kevin Bracey
|
|
|
|
Optimizing compilers don't need this, and making
|
|
the change would be error prone -- Tom Lane, Glenn R-P
|
|
|
|
Question whether i-- or --i is better.
|
|
|
|
STATUS: Under investigation, postponed until after
|
|
libpng-1.1.0. About 160 loops will be turned around
|
|
in libpng-1.1.Nn, for testing.
|
|
|
|
10. July 4, 1998 -- ENHANCEMENT -- Glenn R-P
|
|
|
|
libpng-1.0.5 and earlier transform colors to gamma=1.0 space for
|
|
merging with background, and then back to the image's gamma. The
|
|
bit_depth of the intermediate (gamma=1.0) representation is probably
|
|
not sufficient. In the typical gamma=1/2.2 situation, the linear
|
|
pixels need about 4 more bits than the gamma-encoded ones, to avoid
|
|
loss of precision. A similar situation exists with the rgb_to_gray
|
|
operation.
|
|
|
|
STATUS: under development.
|
|
|
|
11. September 1999 -- ENHANCEMENT --
|
|
|
|
It should be possible to use libpng without floating-point aritmetic.
|
|
|
|
STATUS: Under investigation, implementation postponed until after
|
|
libpng-1.0.6. The application interface will change because replacements
|
|
for the png_set_gAMA(), png_set_cHRM(), and corresponding png_get_()
|
|
functions will be needed.
|
|
|
|
Much of this was completed in libpng-1.0.6, but gamma compensation
|
|
is not yet done in fixed-point arithmetic.
|
|
|