On Fri, Nov 08, 2013 at 09:12:05AM -0800, Kurt Schwehr wrote: > Jack, > > Is there an explanation someplace with more detail as to what is wrong those > png's, why older versions of libpng are okay with it and why libpng has > changed its behavior? > > Thanks, > -kurt
Kurt, The following link... http://comments.gmane.org/gmane.comp.graphics.png.devel/6017 appears to discuss the issue we are seeing with the test.png file... > Libpng-1.6.0 through 1.6.2 use the CMF bytes at the beginning of an zlib > datastream to set the window size for decoding. > Libpng-1.5.x and earlier ignored the CMF bytes and always used a 32kbyte > window. Libpng-1.6.x has uncovered the fact > that there are hundreds of files in the wild (found in linux distributions > such as gentoo) with a too-small CMF, which > results in a "Too far back" error when decoding these PNGs. I have not yet > been able to discover what application is producing these. If you read completely through the gmane.comp.graphics.png.devel/6017 thread, you should be at least convinced that such corruption is a known issue. Jack > > > > On Nov 8, 2013, at 8:02 AM, Jack Howarth <[email protected]> wrote: > > > On Fri, Nov 08, 2013 at 10:31:08AM -0500, Jack Howarth wrote: > >> On Thu, Nov 07, 2013 at 04:34:07PM -0500, Jack Howarth wrote: > >>> The failures on x86_64-apple-darwin13 for the png.py test suite from auto > >>> test for gdal 0.10.1 are the same failures described here... > >>> > >>> https://github.com/licq-im/licq/pull/32 > >>> <https://github.com/licq-im/licq/pull/32> > >>> > >>> The failures are completely suppressed by regenerating > >>> autotest/gdrivers/data/test.png with > >>> "optipng -nb -nc -np test.png"... > >> > >> Just to clarify, I used optipng 0.6.3 for this. The newer optipng 0.7.4 > >> release seems more problematic as none of the obvious combination of > >> options > >> can fix the test.png file without changing the checksums and causing > >> additional > >> failures. So you will want to use the optipng 0.6.x release series to fix > >> the bad png files in gdal. > > > > Also, my tests here using optipng 0.7.4 to detect damaged png files indicate > > that only data/gdalicon.png in gdal-0.10.1 needs to be fixed. > > > > optipng -nb -nc -np -fix data/gdalicon.png > > ** Processing: data/gdalicon.png > > Warning: > > 32x32 pixels, 4x8 bits/pixel, RGB+alpha > > Recoverable errors found in input. Fixing... > > Input IDAT size = 1964 bytes > > Input file size = 2021 bytes > > > > Trying: > > zc = 9 zm = 8 zs = 0 f = 0 IDAT size = 240 > > > > Selecting parameters: > > zc = 9 zm = 8 zs = 0 f = 0 IDAT size = 240 > > > > Output IDAT size = 240 bytes (1724 bytes decrease) > > Output file size = 313 bytes (1708 bytes = 84.51% decrease) > > > > ** Status report > > 1 file(s) have been processed. > > 1 error(s) have been encountered. > > 1 erroneous file(s) have been fixed. > > > > > >> > >>> > >>> % ./png.py > >>> TEST: png_1 ... success > >>> TEST: png_2 ... success > >>> TEST: png_3 ... success > >>> TEST: png_4 ... success > >>> TEST: png_5 ... success > >>> TEST: png_6 ... success > >>> TEST: png_7 ... success > >>> TEST: png_8 ... success > >>> TEST: png_9 ... success > >>> TEST: png_10 ... success > >>> TEST: png_11 ... success > >>> > >>> Test Script: png > >>> Succeeded: 11 > >>> Failed: 0 (0 blew exceptions) > >>> Skipped: 0 > >>> Expected fail:0 > >>> Duration: 0.08s > >>> > >>> _______________________________________________ > >>> gdal-dev mailing list > >>> [email protected] > >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev > >> _______________________________________________ > >> gdal-dev mailing list > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > > gdal-dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
