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.