4 Replies Latest reply on Feb 24, 2013 1:55 PM by Justin Putney

    Paradoxical Results with PNGQualityEnum

    Justin Putney Level 2

      The PNGQualityEnum values are documentated as reflecting export qualitly, but when I test them the file sizes seem to indicate that this value sets the level of compression. So maximum actually results in the smallest file size.

       

      Screen Shot 2013-02-23 at 3.20.35 PM.png

       

      Does any one else have any experience with this?

        • 1. Re: Paradoxical Results with PNGQualityEnum
          [Jongware] Most Valuable Participant

          It's indeed an unfortunate name. "Quality", with respect to compression, is only an issue with JPEG, as 'high quality' literally means 'a larger file'. That's no coincidinky, it's how JPEG compression works.

           

          PNG compression, on the other hand, is lossless. The only variable is tinkering with the compression itself (both the PNG filter settings and the intricacies of deflate compression). Can you, just for the fun of it, compare your "lowest" and "highest" quality images in Photoshop? I think you only have to save both of them in an uncompressed format; I expect you end up with two *identical* files.

          1 person found this helpful
          • 2. Re: Paradoxical Results with PNGQualityEnum
            Justin Putney Level 2

            Thanks, Jongware. That's good info. So I won't worry that Adobe will change this functionality in CS7...

             

            I don't see any different (visibly) in quality between "low" and "maximum" PNGs, but the file size is noticeably different (~ a 2x difference). I guess I'll go with the smaller (max compression) option, as it doesn't appear that there's a downside.

            • 3. Re: Paradoxical Results with PNGQualityEnum
              [Jongware] Most Valuable Participant

              Got it. The difference lies not in applying different PNG filters (which, theoretically at least, would lead to a better compression), but the supplied value seems to be handed over directly to the deflate compressor: the 'memLevel' argument in deflateInit2.

              I meant to say the compression level in deflateInit

               

              The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: 1 gives best speed, 9 gives best compression, 0 gives no compression at all (the input data is simply copied a block at a time). Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6).

              (from http://www.zlib.net/manual.html)

               

              as is shown by running pngcheck on a Low and Max 'quality' exported PNG:

               

              File: low.png (6372 bytes)
                chunk IHDR at offset 0x0000c, length 13
                  139 x 167 image, 24-bit RGB, non-interlaced
                chunk pHYs at offset 0x00025, length 9: 2834x2834 pixels/meter (72 dpi)
                chunk IDAT at offset 0x0003a, length 6294
                  zlib: deflated, 32K window, fast compression
                  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (167 out of 167)
                chunk IEND at offset 0x018dc, length 0
              No errors detected in low.png (4 chunks, 90.8% compression).
              

               

              File: max.png (4989 bytes)
                chunk IHDR at offset 0x0000c, length 13
                  139 x 167 image, 24-bit RGB, non-interlaced
                chunk pHYs at offset 0x00025, length 9: 2834x2834 pixels/meter (72 dpi)
                chunk IDAT at offset 0x0003a, length 4911
                  zlib: deflated, 32K window, maximum compression
                  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (167 out of 167)
                chunk IEND at offset 0x01375, length 0
              No errors detected in max.png (4 chunks, 92.8% compression).
              

               

              and this was my test image

              addy.png

               

              Message was edited by: [Jongware]

              1 person found this helpful