Legacy ImageMagick Discussions Archive

Here I demonstrate that gimp's conversion from pgm to png yields a considerably smaller png file than IM's conversion. I tried using the -quality option (-quality 1, -quality 100), but it didn't help.

$ convert -v | head -1
Version: ImageMagick 6.6.4-1 2010-12-17 Q16 http://www.imagemagick.org
$ ls -sh *.pgm
12M src.pgm
$ convert src.pgm im.png
$ gimp src.pgm
[save image as gimp.png]
$ ls -sh *.png
6.7M gimp.png 9.6M im.png
$ identify *.png
gimp.png PNG 4284x2844 4284x2844+0+0 8-bit PseudoClass 256c 6.979MB 0.000u 0:00.000
im.png[1] PNG 4284x2844 4284x2844+0+0 8-bit PseudoClass 256c 9.986MB 0.000u 0:00.000

Shouldn't they both output about the same size file? Indeed, I might even expect them to output the exact same .png file since they are presumably using the same shared library.

Lossless jpeg produces similar results: the lossless jpeg files are much smaller than the png files, but I expected them to be about the same.

Maybe
The first digit (9) means the highest level of zlib compression and the
second (0) means no "PNG" filtering which is almost always the best
choice for 256-color images.

Also, please try a current version of ImageMagick (6.7.0).

If you are just not sure what the best compression to use is. Try using the non-IM command pngcrush.
http://www.imagemagick.org/Usage/formats/#png_non-im

this program just read and writes PNG in different compression methods to find the smallest file.
I have written a shell wrapper around this command for my own use which batch processes images.

pngcrush_batch
http://www.imagemagick.org/Usage/scripts/pngcrush_batch


Use at own risk.

I tried -quality 90, but that didn't help.

pngcrush, on the other hand, does the trick.

The IM that came with my FC12 distribution compressed the files down smaller without using pngcrush, whereas the IM that is installed in my current distribution, FC14, requires calling this extra application. Isn't that a little strange? How is gimp able to do the compression right on the first try?

How are you processing the images. Basically I am trying to determine where the 'quality' setting was coming from.

It may have only been getting its 'right' previously by luck. Other than general gzip compression level (the first digit) there not many types of run length compression for the second digit. However there is also different types of image storage (bit depth, indexed).

We would need a lot more information to figure out what is going on. However if you are happy with using "pngcrush" as a general all purpose (but slow) solution, that is fine.

I am not certain how gimp would make a determination of the best encoding method. It also might be making a lucky guess as the final size of any image file is a very hard thing to determine.

perhaps the user could provide links to the original image, GIMP result and IM result so that others can test

Glenn would have to comment, but I am wondering if the IM pngs are carrying other info such as png chunks (due to all the recent png enhancements that he has made recently) that gimp is not storing. Thus IM pngs have more features/formats that GIMP does not provide. If so, then perhaps there might be a way to remove the excess data as an option or other function similar to -strip?

see http://www.imagemagick.org/Usage/formats/#png_write

I'll use the current solution, but I am happy to provide links to a few of the images.

https://docs.google.com/leaf?id=0B2fAsW ... y=CMPD25UP
https://docs.google.com/leaf?id=0B2fAsW ... y=CODtnooF
https://docs.google.com/leaf?id=0B2fAsW ... y=CJTYrpgJ

There is nothing special about the images. They are 4284x2844 grayscale outdoor scenes.

I suspect that the IM png files are not using any predictive coding. They have simply been run through an entropy coder, as this suggests:

[jsp@psy86 tmp] 1081:$ convert -version | head -1
Version: ImageMagick 6.6.4-1 2010-12-17 Q16 http://www.imagemagick.org
[jsp@psy86 tmp] 1082:$ find *.pgm | xargs -I{} sh -c "convert {} \`basename {} .pgm\`.png"
[jsp@psy86 tmp] 1083:$ find *.pgm | xargs -I{} sh -c "zip \`basename {} .pgm\`.zip {}"
adding: cps201004281214.pgm (deflated 14%)
...
[jsp@psy86 tmp] 1084:$ du -sh *.png *.zip | sort -h
8.7M cps201004281281.png
8.7M cps201004281281.zip
9.3M cps201004281295.png
9.3M cps201004281295.zip
9.4M cps201004281307.png
9.4M cps201004281307.zip
9.4M cps201004281308.png
9.4M cps201004281308.zip
9.6M cps201004281289.png
9.6M cps201004281289.zip
9.6M cps201004281297.png
9.6M cps201004281297.zip
9.6M cps201004281302.png
9.6M cps201004281302.zip
9.8M cps201004281313.png
9.8M cps201004281313.zip
10M cps201004281214.png
10M cps201004281214.zip
11M cps201004281239.png
11M cps201004281239.zip

Clearly, this is not correct. png should outperform pkzip.

Gimp gets another 26% reduction.

[jsp@psy86 tmp] 1085:$ gimp --version
GNU Image Manipulation Program version 2.6.11
[jsp@psy86 tmp] 1086:$ gimp cps201004281281.pgm
...
[jsp@psy86 tmp] 1088:$ du -h *.gimp.png
6.4M cps201004281281.gimp.png

fmw42 wrote:perhaps the user could provide links to the original image, GIMP result and IM result so that others can test

Glenn would have to comment, but I am wondering if the IM pngs are carrying other info such as png chunks (due to all the recent png enhancements that he has made recently) that gimp is not storing. Thus IM pngs have more features/formats that GIMP does not provide.

That seems unlikely because the source is PGM which has no metadata.

I downloaded cps201004281289.pgm and observed the same that you
did: about 10MB, pngcrushed about 7MB, with IM-6.7.0-5.
Except for the two 37-byte text chunks containing create and modify
time, there's no extra metadata.

Curiously, pngcrush selects

• Best pngcrush method = 9 (fm 5 zl 2 zs 2)

which equates to the IM "-quality 06" setting for
PNG output. This yields a 7.0MB output.

Glenn

jsp wrote:There is nothing special about the images. They are 4284x2844 grayscale outdoor scenes.

They look like Australian Euclipts to me

glennrp wrote:Curiously, pngcrush selects

• Best pngcrush method = 9 (fm 5 zl 2 zs 2)

which equates to the IM "-quality 06" setting for
PNG output. This yields a 7.0MB output.

Sorry Glenn, don't you mean "-quality 96" ???

As a FYI... Here are my own tests (IM v6.7.0-7), all numbers in bytes...

12183713 original pgm file (essentially raw uncompressed 8bit depth Grayscale data, with small ascii header at the start)
10527647 gzipped pgm file (image.pgm.gz). This is a valid PbmPlus file format and understood by IM and most PbmPlus formats without any modification. For example... as such the original raw data does not compress well normally. This is typical of natural scenes with very little repeated data strems
10547885 IM save to image.pgm.gz (not certain how to set gzip compression to 9 for IM, it does not follow -quality setting, so not as good right now)

10536349 IM convert to png (using defaults) (lower gzip data compression - faster but not as good)
10535276 IM with -quality 90
8376397 IM with -quality 91 (better due to shading effects across image generating repeatable data)
8265194 IM with -quality 92
7834432 IM with -quality 93
7504964 IM with -quality 94
10535276 IM with -quality 95 (slightly better than 90, but obvious not compressible good data encoding)
7504957 IM with -quality 96 (best result from IM)
other PNG quality/encoding levels in IM 97-99 are the same as 96

7536335 Gimp defaults to PNG (compression 9)

7463730 PngCrush which essentially tries ALL compression methods to find best) Best method 9 (fm 5 zl 2 zs 2)

Summery...
IM -quality 96 was slightly better than Gimp, even with its extra (very small) meta-data,
gimp probably added a larger meta-data element (Glenn can you verify?)
pngcrush produces the best of all -- The question is, why?

I meant 06.

The leading zero selects Huffman-only compression which is
what pngcrush selected (zs=2).

Someday I'll rewrite this to use -defines instead of the -quality,
e.g., something like

• -define PNG:compression-level=2 \
  -define PNG:compression-strategy=2 \
  -define PNG:filter-type=5

should replicate the pngcrush result exactly.

Okay do for the first digit '0' is huffman compression, and 1-9 is zlib compression. So in some cases '0' is better!

perhaps then '0' compression should be the default -quality for PNG when the user has not defined it.


However my notes in IM Examples, for the second digit has.. 0 is none, 1 is "sub", 2 is "up",
3 is "average", 4 is "Paeth", and 5 is "adaptive".

What then is 6?


I am looking forward to your PNG format submission to IM Examples

I'll work on setting up some -define PNG: possibilities
for finer (and maybe easier to comprehend) control of
the PNG compression.

This is checked in, SVN revision
4669, which will be either IM-6.7.0-10 or the next IM release.