#15 Special PNG's / bitmaps (special behaviour when optimizing)

pending
Cosmin Truta
None
1
2012-10-10
2010-01-16
dos386
No

(I don't know what's the best place to drop such stuff so I dropped it here also)

1. Compresses better with 8bpp than 4bpp - seen some time ago, can't find it anymore :-(

2. Compresses poorly (brewn by me) :

http://freefile.kristopherw.us/uploads/temp/pngspeci.zip (1'295 Byte's)

GAMMA669.PNG 669 | 450 x 450 , 10 colours | PNGoutWIN :-(
01688422D008E8C0353E96CD14E9A6B2

BMP : 102'718
LibPNG (NCONVERT) : 915
PNGOUT : 844 (799 with DeflOPT)
OptiPNG : 694 (N/A for DeflOPT)
PNGoutWIN : 669 ### WINNER ###
ZIP (only data) : 302 !!! 2.21 !!!
Source (use32) : 195

INT1587.PNG 1'901 | 680 x 520 , 1'574 colours | OptiPNG
33C13468D5617F9CB27DD4A2BE1B70F1

BMP : 1'060'854
LibPNG (NCONVERT) : 2'329
PNGOUT : 1'946 (1'943 with DeflOPT)
OptiPNG : 1'901 (N/A for DeflOPT) ### WINNER ###
PNGoutWIN : no test
ZIP (only data) : 370 !!! 5.14 !!!
Source (use16) : 87

As we can see, PNGOUT is (exceptionally) inferior to OPTIPNG, but the BIG ECLAT is
that the "most optimized" PNG's can be ZIP'ped by factor 2.21 or 5.14 !!!

Also, both PNGOUT and OPTIPNG are inferior to PNGoutWIN :-(

At least, my source code size is impossible to beat :-)

3. PNG inferior to GIF ???

http://www.memtest.org/

6 screenshots (3 small and 3 big) and I'm unable to convert them into
PNG without loss or bloat increase ... WtF ????

Discussion

  • dos386
    dos386
    2010-01-16

    • assigned_to: nobody --> cosmin
     
  • dos386
    dos386
    2010-05-23

    Attach faulty and then link dead. Please download again from below if anyone got the bad version.

    GAMMA.PNG 669 | 450x450x4bpp | 10 Colors | PNGoutWIN :-(
    53EB'B40A'AE44'1DBF'A1F7'E481'FEEB'07FD

    BMP : 102'718
    LibPNG (NCONVERT) : 915
    PNGOUT : 844 (799 with DeflOPT)
    OptiPNG : 694 (N/A for DeflOPT)
    PNGoutWIN : 669 ### WINNER ###
    ZIP (only data) : 302 !!! 2.21 !!!
    Source (use32) : 193

    INT1587.PNG 1'901 | 680x520x24bpp | 1'574 Colors | OptiPNG
    33C1'3468'D561'7F9C'B27D'D4A2'BE1B'70F1

    BMP : 1'060'854
    LibPNG (NCONVERT) : 2'329
    PNGOUT : 1'946 (1'943 with DeflOPT)
    OptiPNG : 1'901 (N/A for DeflOPT) ### WINNER ###
    PNGoutWIN : no test
    ZIP (only data) : 370 !!! 5.14 !!!
    Source (use16) : 87

     
  • dos386
    dos386
    2012-02-05

    Unoptimizable GIF's

     
    Attachments
  • dos386
    dos386
    2012-02-05

    PNG's behaving "special" way when optimizing

     
    Attachments
  • dos386
    dos386
    2012-02-05

    > 1. Compresses better with 8bpp than 4bpp - seen some time ago

    Included in PNGSPECI

    ****

    "http://optipng.sourceforge.net/pngtech/better-lzw.html"

    FEYNMAN.GIF "feynman_ni.gif" 2'680
    A67A21743A989E354FE33DF8DADB3AD6
    "http://optipng.sourceforge.net/pngtech/img/feynman_ni.gif"

    FEYNMANX.PNG 2'594
    1A6596EE93E5AB81A467AF558563C159

    30 colors, reportedly unoptimizable,
    but successfully optimized (PNGOUT+DeflOpt) !!!

    ****

    "http://optipng.sourceforge.net/pngtech/8bpp.html"

    PHOENIX.PNG "phoenix.png" 64'872
    3B13713FBA8746C5DEDC64BE21F7C70F
    "http://optipng.sourceforge.net/pngtech/img/phoenix.png"

    PHOENIX4.PNG 62'266 | 4 bpp
    2F6496ECF79BAD84DE6763F916FEBBF6

    PHOENIX8.PNG 60'155 | 8 bpp
    B0FE7234B1BA6933197E829F2303AEC5

    16 colors, successfully optimized further (PNGOUT+DeflOpt), but as said,
    in this special case, 8 bpp (used "/d8") is better than 4 bpp (default) !!!

    ****

    Attachments updated again ...

     
  • dos386
    dos386
    2012-02-05

    Cosmin wrote:

    > Update: Some users have reported that even the image shown below can be
    > compressed as PNG better than shown in these reports, and better than GIF.
    > So: Unless I find a non-trivial replacement image whose GIF stream is shorter
    > than its PNG IDAT stream, this article has no purpose... which, in fact,
    > is a good thing! :-)

    See GIFS.ZIP attach :-(

     
  • Cosmin Truta
    Cosmin Truta
    2012-10-10

    Thank you, dos386. I had a look at the images, and they are, indeed, statistical anomalies.
    The GIFS archive contains data with short repetitive sequences. Deflate does well on long repetitions with the default strategy, or on few or no repetitions with the "Huffman-only" strategy, and that data falls into neither category.

    To this kind of data it is better to apply lossy compression like JPEG, or (as an alternative) the image data should be cleaned up by some denoising+sharpening software, before having it compressed losslessly.

    Yet another possible alternative would be to use a specially-tailored zlib. Unfortunately, I cannot invest the time to tackle that kind of experiment.

     
  • Cosmin Truta
    Cosmin Truta
    2012-10-10

    • priority: 5 --> 1
    • status: open --> pending
     
  • Matthew
    Matthew
    2012-10-10

    Regarding the GIF images:
    there are some inherent limitations in Deflate compared to LZW - notably, LZW can compress two-pixel matches while Deflate can't compress two-byte matches. So it's not hard to conceive of pathological worst cases where GIF will out-compress PNG.
    I speculate that there also tends to be a lot of two-pixel matches in heavily dithered images, without enough frequency differential to benefit much from Deflate's Huffman encoding.

    Here's another "wild" one: http://advsys.net/ken/pingball.gif
    I tried various Deflate strategies, but was unable to beat the GIF size. This is perhaps unsurprising because the image was on Ken Silverman's site, so if it were possible to lower the size using PNG he almost certainly would have.