Activity for Glenn Randers-Pehrson
-
Glenn Randers-Pehrson posted a comment on ticket #273
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?
1 >