Incorrect png -quality 9 setting gives the best compression

[fedetxf]

If I use -quality 9 I get extraordinary compression but the docs don't specify what is mogrify's behaviour with such input value so I don't know if I'm getting a valid result.
I have 26 TIFF images for testing, some 8 bit greyscale, some 24 bit color.

If I compress using the default quality (which is 75) I get 444.566.700 bytes.
If I use -quality 96 I get 354.773.171 which is great.
If I use -quality 9 I get 338.673.832 which is unbeatable by any other switch combination I tried.

Checking file by file between quality 96 and quality 9 I get -quality 9 gives me 23 smaller files and 3 bigger. Smaller files are on avegare 3.65% smaller and bigger ones are on average 0.08% bigger.

Looking at the logs with -debug all I see

Setting up deflate compression
Compression buffer size: 32768
Compression mem level: 9
Compression strategy: 2
Setting up filtering
Base filter method: 9

But

Code: Select all

mogrify -depth 8 -format png -define PNG:compression-level=9 -define PNG:compression-strategy=2 -define PNG:compression-filter=9 -path "$DST" "$SRC"/*.tif 

gives me 568.640.145 which is huge. Those param values are consistent with the sources as far as I could see.

So I'm not sure what compression-level compression-strategy and compression-filter are being used with -quality 9.

Maybe someone with more source code knowledge can tell me what goes on with -quality 9 and if it is ok to use it...

[dlemstra]

This is written in the comments in png.c:

Code: Select all

/* Untangle the "-quality" setting:

     Undefined is 0; the default is used.
     Default is 75

     10's digit:

        0 or omitted: Use Z_HUFFMAN_ONLY strategy with the
           zlib default compression level

        1-9: the zlib compression level

     1's digit:

        0-4: the PNG filter method

        5:   libpng adaptive filtering if compression level > 5
             libpng filter type "none" if compression level <= 5
                or if image is grayscale or palette

        6:   libpng adaptive filtering

        7:   "LOCO" filtering (intrapixel differing) if writing
             a MNG, otherwise "none".  Did not work in IM-6.7.0-9
             and earlier because of a missing "else".

        8:   Z_RLE strategy (or Z_HUFFMAN_ONLY if quality < 10), adaptive
             filtering. Unused prior to IM-6.7.0-10, was same as 6

        9:   Z_RLE strategy (or Z_HUFFMAN_ONLY if quality < 10), no PNG filters
             Unused prior to IM-6.7.0-10, was same as 6

    Note that using the -quality option, not all combinations of
    PNG filter type, zlib compression level, and zlib compression
    strategy are possible.  This is addressed by using
    "-define png:compression-strategy", etc., which takes precedence
    over -quality.

   */

And PNG:compression-filter=9 is invalid, the range is 0-5.

EDIT: Updated code block with the new comment.

[glennrp]

Since ImageMagick-6.7.1, "-quality 9" is equivalent to

Code: Select all

mogrify -depth 8 -format png -define PNG:compression-strategy=2 -define PNG:compression-filter=0 -path "$DST" "$SRC"/*.tif

The images you are creating with this are valid ones.

[fedetxf]

Thanks. Now I have this bug in my version.
viewtopic.php?f=3&t=22119
I'll have to upgrade. But no problem, I can use -quality 9.

I wonder if the docs should reflect you don't need 2 digits in the quality setting or maybe that is an unintended result when receiving just one digit there.

[glennrp]

Thanks. Now I have this bug in my version.
viewtopic.php?f=3&t=22119
I'll have to upgrade. But no problem, I can use -quality 9.
I wonder if the docs should reflect you don't need 2 digits in the quality setting or maybe that is an unintended result when receiving just one digit there.

Probably not. If there aren't enough digits, the leading missing decimal digits are interpreted to be zero, but that's not peculiar to the -quality value.

[glennrp]

The documentation about interpretation of the -quality value by the PNG encoder is revised in 6.8.7.0 (now in SVN revision 13272) to clarify what happens when the 10's digit is omitted or is 0.