I think this is handled in scripts/options.awk which is a little difficult for me to follow. I wonder if the problem goes away if you add some parentheses in pngpriv.h line 910 so it reads #if (PNG_ZLIB_VERNUM != 0) && (PNG_ZLIB_VERNUM != ZLIB_VERNUM)
Confirmed that this test segfaults for me.
This is not a terribly satisfactory solution, but you may be able to work around the problem by using --zprefix when you configure your new zlib. This may eliminate a conflict between your new zlib with the older one lurking on your system somewhere.
This is not a terribly satisfactory solution, but you may be able to work around the problem by using --zprefix when you configure your new zlib. This may eliminate a conflict between your new zlib with the older one lurking on your system somewhere.
1.6.33 testsuite failures
The troublesome new interlaced files have been removed from contrib/pngsuite in libpng-1.6.34.
Thanks for the report. I removed the new interlaced images from libpng-1.6.34, and put some of them back in libpng-1.6.35beta01 (omitting the ones that were rejected by pngimage. As far as I can tell there is nothing wrong with them, but it appears that "pngimage" is having trouble with interlaced images that have bit-depth less than 8.
png_do_check_palette_indexes seems out of bounds
libpng-1.6.32 rejects valid PNG images with "IDAT: chunk data is too large"
This bug is fixed in all branches and "libpng rc01" releases. Public releases are planned for 28 September 2017.
Fixed in coders/png.c, but wouldn't it make more sense to have MagickAllocateMemory check against MemoryResource?
libpng 1.6.30 fails to build on arm64
Update libpng website for 1.6.31
Done.
png_do_check_palette_indexes seems out of bounds
libpng-1.6.32 rejects valid PNG images with "IDAT: chunk data is too large"
Fixed in git branch libpng16, please test. It sets a larger limit for IDAT, allowing for a deflate buffer per row. Also, it uses the PNG_USER_CHUNK_MALLOC_MAX user limit, so users can set an even larger limit if they need it.
Yes please regenerate the PNG and upload it as idat_too_large.png.tar.gz so SF doesn't re-encode it.
Yes please regenerate the PNG and upload it as file.png.tar.gz so SF doesn't re-encode it.
I'm not seeing a failure to read the attached image with libpng-1.6.33beta01 or 1.6.32betq12. I do see your point, though. I suppose we could use a more generous upper limit of one deflate block per sample.
I believe you're correct. Fixed in the GIT repos by subtracting 1: png_bytep rp = png_ptr->row_buf + row_info->rowbytes - 1;
I believe you're correct. Fixed in the GIT repos by subtracting 1: png_bytep rp = png_ptr->row_buf + row_info->rowbytes - 1; ===
Confirmed that this image causes my GM to segfault. pngcheck says: studio> pngcheck -vf 10.crashes.png File: 10.crashes.png (298 bytes) chunk JHDR at offset 0x0000c, length 16: first chunk must be MHDR : invalid image dimensions (65517x0) : invalid color type CRC error in chunk JHDR (computed cdfcc919, expected 73ffc400) invalid chunk name " " (0b 12 00 00) chunk at offset 0x00028, length 336592896: first chunk must be MHDR : EOF while reading data ERRORS DETECTED in 10.crashes.png
Confirmed that this file causes my GM to segfault. pngcheck says: studio> pngcheck -vf *.png File: 20.crashes.png (275 bytes) chunk JHDR at offset 0x0000c, length 16: invalid color type CRC error in chunk JHDR (computed 780f2030, expected c02bbb59) chunk sRGB at offset 0x00028, length 1 rendering intent = perceptual chunk pHYs at offset 0x00035, length 9: 2834x2834 pixels/meter (72 dpi) chunk vpAg at offset 0x0004a, length 9 unknown private, ancillary, safe-to-copy chunk CRC error in chunk vpAg (computed...
Confirmed that this file causes my GM to segfault.: studio> pngcheck -vf *.png File: 20.crashes.png (275 bytes) chunk JHDR at offset 0x0000c, length 16: invalid color type CRC error in chunk JHDR (computed 780f2030, expected c02bbb59) chunk sRGB at offset 0x00028, length 1 rendering intent = perceptual chunk pHYs at offset 0x00035, length 9: 2834x2834 pixels/meter (72 dpi) chunk vpAg at offset 0x0004a, length 9 unknown private, ancillary, safe-to-copy chunk CRC error in chunk vpAg (computed 6b36e9b6,...
allocation failure in ReadMNGImage
I've pushed a fix for Bob to check in. For completeness I tested a variant of the file with MEND length 7fffffff (the largest valid PNG chunk length) and, although there was a few-second delay while the malloc occurred, it did not crash.
This is a small MNG file with a MEND chunk that has length ff000000. Confirmed that gm crashes on it.
There's no problem with MacOS 10 on pngcrush. It's the problem of finding clock_gettime on older versions. Apparently ImageMagick's scheme finds it but simply adding librt to LIBS doesn't do it for pngcrush. Incidentally libpng has the same problem. I think you will find that on MacOS 10, the "timepng" tool gets built but on the older Macs it will be omitted.
Well, that indicates that -lrt should work. ImageMagick's configure.ac is heavy reading, but somehow it's finding librt. It uses autoconf Check for clock_gettime(). AC_SEARCH_LIBS(clock_gettime, rt, AC_DEFINE([HAVE_CLOCK_GETTIME,[1],[Define to 1 if you have clock_gettime.]) AC_MSG_CHECKING([whether clock_gettime supports CLOCK_REALTIME]) AC_COMPILE_IFELSE( AC_LANG_PROGRAM( [[#include <time.h>]], [[clockid_t clockType = CLOCK_REALTIME;]]), AC_MSG_RESULT(yes) AC_DEFINE([HAVE_CLOCK_REALTIME,[1], [Define...
Well, that indicates that -lrt should work. ImageMagick's configure.ac is heavy reading, but somehow it's finding librt. It uses autoconf Check for clock_gettime(). AC_SEARCH_LIBS(clock_gettime, rt, AC_DEFINE([HAVE_CLOCK_GETTIME,[1],[Define to 1 if you have clock_gettime.]) AC_MSG_CHECKING([whether clock_gettime supports CLOCK_REALTIME]) AC_COMPILE_IFELSE( AC_LANG_PROGRAM( [[#include <time.h>]], [[clockid_t clockType = CLOCK_REALTIME;]]), AC_MSG_RESULT(yes) AC_DEFINE([HAVE_CLOCK_REALTIME,[1], [Define...
Would you configure ImageMagick on your platform and do grep GETTIME config/config.h
On some platforms it is sufficient to enable "LIBS += -lrt" in the Makefile. Does that work on the MacOS/XCode versions that are having trouble? I believe that would be a better solution if it works because it will give you the high-resolution timing.
Fixed in the GIT repos. Just add "exit (0);" around line 4478 in pngcrush.c until I push 1.8.13 out soon with the fix. The "CPU time" line will not appear.
Fixed in the GIT repos. Just add "exit (0);" around line 4478 in pngcrush.c until I push 1.8.13 out soon with the fix.
Ah, thanks. I'll take care of it soon. Glenn
Did you add the "Check ..for the most recent version" yourself, then? It isn't coming from the pngcrush that I'm distributing.
pngcrush -version behavior different in 1.8.12
You can try using "pngcrush -v ...." to get the same output (more or less) as pngcrush-1.8.11
Your pngcrush has been modified downstream. Where did you get it? (The pngcrush distributed from here does not say "Check http://pmt.sf.net for the most recent version.")
Libpng-1.6.32 will probably be released around August 24th.
I think this has ben fixed. I'm not seeing a leak with the current GM, head of the mercurial repo.
pngcrush-1.8.12 released
Problem compiling libpng1.6.30 on ubuntu 16.04 amd64
You need to install zlib-1.2.9 or later, preferably zlib-1.2.11. If you had already installed 1.2.11, then maybe the linker is finding another older zlib on your computer when linking pngfix.
You need to install zlib-1.2.9 or later, preferably zlib-1.2.11.
Fixed in libpng-1.6.31beta01.
Thanks. I think your patch is a little better than the one I pushed to the git libpng16 branch yesterday.
Fixed at the OSUOSL (a.k.a. libpng.download) site. New releases are immediately copied (linked) into their permanent location in the src/archive directory. See for example http://libpng.download/src/archive/xz/libpng16 or if you prefer the "https:" protocol, https://ftp-osl.osuosl.org/pub/libpng/src/archive/xz/libpng16/
Fixed at the OSUOSL (a.k.a. libpng.download) site. New releases are immediately copied (linked) into their permanent location in the src/archive directory. See for example http://libpng.download/src/archive/xz/libpng16 or if you prefer "https:" protocol, https://ftp-osl.osuosl.org/pub/libpng/src/archive/xz/libpng16/
Fixed at the OSUOSL (a.k.a. libpng.download) site. New releases are immediately copied (linked) into their permanent location in the src/archive directory. See for example http://libpng.download/src/archive/xz/libpng16 or https://ftp-osl.osuosl.org/pub/libpng/src/archive/xz/libpng16/
Fixed at the OSUOSL (a.k.a. libpng.download) site. New releases are immediately copied (linked) into their permanent location in the src/archive directory. See for example http://libpng.download/src/archive/xz/libpng16
Are you still seeing this problem in libpng-1.6.30?
Fixed at the OSUOSL site. New releases are immediately copied (linked) into their permanent location in the src/archive directory.
Volatile download urls
The function of error_ptr is undocumented
Fixed in libpng-1.6.30
Extra 0 length IDAT Chunk at end of 8192 Byte aligned .png files.
Fixed in libpng-1.6.30
Fixed in libpng-1.6.30beta04. Coverity did not object to either "if (size)" so I kept both.
Confirmed that libpng17 does not have the bug.
I'll post a fixed libpng16 shortly. The fix is just to add "if (size)" before each of the two calls to png_write_complete_chunk(...IDAT...) in pngwutil.c (probably only needed before the second call).
I'll post a fixed libpng16 shortly. The fix is just to add "if (size)" before each of the two calls to png_write_complete_chunk(...IDAT...) in pngwutil.c
Confirmed that libpng-1.6.0 exhibits the bug. I'm using "pngtest" that comes with libpng; I add the following: // set compression flags here. png_set_compression_buffer_size(write_ptr, (png_size_t)8119); where the value "8119" is the exact length of the IDAT chunks in pngout.png after running pngtest. The r esult is, as expected, one IDAT with length 8119 followed by an IDAT of length 0.
Confirmed that pngcrush+libpng15-1.5.29beta does not exhibit the bug and that pngcrush+libpng16-1.6.13 does exhibit the bug.
Confirmed that pngcrush+libpng15-1.5.29beta does not exhibit the bug.
Confirmed with pngcrush+libpng16-1.6.29; it generates an extra zero-length IDAT when the last IDAT is the maximum buffer size. So it's a libpng16 off-by-one problem.
Nope. I'll see if I can reproduce the problem in another libpng16 application.
Confirmed with pngcrush+libpng16; it generates an extra zero-length IDAT when the last IDAT is the maximum buffer size. So it's a libpng16 off-by-one problem.
Nope. I'll see if I can reproduce the problem in another libpng16 application, but I suspect it might be a bug in the opencv png codec.
Thanks, I've reported this upstream and will patch pngcrush.
Which platform were you testing (unix, ios, win, or android)?
Thanks for the report. Would you try building with the current libpng (1.6.29)?
Extra 0 length IDAT Chunk at end of 8192 Byte aligned .png files.
Thanks again, that gives more to go on. That should be using the zutil.h that's included in the tar.xz distribution, so I wonder why you are seeing a conflict. Hmm, I see, it's conflicting with the system stddef.h which would be a zlib bug not a pngcrush bug. I'll follow up on that with the zlib dev.
Thanks again, that gives more to go on. That should be using the zlib.h that's included in the tar.xz distribution, so I wonder why you are seeing a conflict. Hmm, I see, it's conflicting with the system stddef.h which would be a zlib bug not a pngcrush bug. I'll follow up on that with the zlib dev.
Thanks. I'll look into this.
Pngcrush build error with ptrdiff_t when bulding with zlib-1.2.8
Please try building with zlib-1.2.11.
Plese try building with zlib-1.2.11.
No problem, I added one.
,Pngcrush build error with ptrdiff_t
The new libpng ftp site gives each release a permanent home, right away, in the "archive" directory. Here is the announcement: I'm pleased to announce a new ftp site for libpng tarball distributions, thanks to Oregon State University's Open Software Laboratory. It is able to deliver at a rate that is twenty or more times as fast as ftp.simplesystems.org, and will respond to http and https requests as well as anonymous ftp requests. https://ftp-osl.osuosl.org/pub/libpng http://ftp-osl.osuosl.org/pub/libpng...
The "quality" report for ImageMagick and GraphicsMagick are both meaningless for...
[PATCH] implement multiarch with cmake too
Done in libpng-1.6.29. Thanks.
In libpng-1.6.30beta01 I'm adding, in the description of the error_fn in libpng.3...
In libpng-1.6.30beta01 I'm adding, in the description of the error_fn in libpng.3...
PowerPC Power8 VSX SIMD optimized filter functions
Done in libpng-1.6.29
pngtopng.c: Confusing memory management
Allocate too much memory for a bad iCCP chunk
That bug was supposedly fixed in libpng-1.6.25. What version are you testing?
libpng-1.6.29 released
I don't know of any plan to change the API and I expect that we wouldn't. It should...
Have you looked at libpng-1.6.29beta02? Does that not meet your expectations?