Legacy ImageMagick Discussions Archive

I When either version converts to PNG, I get that warning. I think it's simply a warning, that someone (GlennRP?) thinks grayscale PNG files shouldn't have colour profiles. But it does put the profile in the file. (Glenn knows far more about PNG than I do.) The PNG speciification for the iCCP chunk ...

When the output is PNG, the "quality" does not affect image appearance; it only affects the amount of compression. For your task, try "-quality 50" or "-quality 40", then adjust until you are happy with the compression speed and filesize (put this option at the end, just before "result.png" on your ...

Thanks, fixed in IM7. Bug didn't exist in IM6.

Not sure what else it could tell you. libpng was attempting to read a chunk (most likely IDAT) and some of it was missing. You can get more info by adding "-debug coder -log %e" to your commandline (put it right after "convert").

Confirmed the behavior you observed. You can get the result you expected by adding "+repage" to the third line: convert 2.png -resize 3 +repage 3.png The recorded offset is interfering somehow with the conversion. You can also get the result you expected by using PPM instead of PNG for the files ...

Get rid of the iCCP profile and replace it with the sRGB chunk or with a valid sRGB profile. The complaint is ocming from libpng16. The simplest way is to use the -strip option, if you haven't got any other valuable metadata that you want to preserve (by the way, the -debug option should appear ...

Not sure but "pngcheck -v file.ico" might help us figure out what's going on.

fmw42 wrote: ↑2017-08-27T20:34:01-07:00 Identify -verbose does not show that information, now, as far as I can tell.

Right, it doesn't. As I said, you need to use a large toolbox to get everything. For the particular information you wanted,
"pngcheck -vv file.png" provides it. Note that pngcheck is not libpng-based.

Yes, the first tool I usually go to is "pngcheck". If you add enough "v's" it will show you the filter method used for each line pngcheck -vvv file.png (If you add another "v" or two, you'll get every pixel sample, so three is about right for you). The next tool is "od -c" or "xxd" or my own ...

Perhaps you might discuss this with the others on the libpng development team and see if it makes sense to them to modify libpng to show one or the other. I don't know enough about the filter values to say which is better. I would leave that to you and the PNG team to decide which, if they agree to ...

Probably not possible and certainly not easy. The PNG format does not explicitly record the "quality", compression method, or filtering method used in compressing the image. You can make a guess by looking at the filter bytes; if they are all zero or some other constant N, you can guess that the ...

They probably are using the same ZIP compression and "quality". What would you like -verbose to report? Something like PNG:filters=1600x0; 0x1; 0x2; 0x3; 0x4 PNG:filters=0x0; 1x1; 1x2; 935x3; 663x4 or just PNG:filters=1600, 0, 0, 0, 0 PNG:filters=0, 1, 1, 935, 663 repectively for the two images? It ...

"pngcrush -n -v file.png" shows me that the centos compressor chose the "NONE" (0) filter for every row (note the "count" values): filter[0] defilter time = 0.000420997, count = 1600 filter[1] defilter time = 0.000000000, count = 0 filter[2] defilter time = 0.000000000, count = 0 filter[3] defilter ...

OK my mistake. I had downloaded the dropbox thumbnails. Here's what I get
when I use the DOWNLOAD/Direct Download buttons:

-rw-rw-r-- 1 glennrp glennrp 7027543 Aug 24 19:10 test_res_win.png
-rw-rw-r-- 1 glennrp glennrp 9647753 Aug 24 19:08 test_res_cent.png

Idon't see the differences in filesize that you're talking about: