Comparison of lossless PNG compression tools

**Surfer** · 6th January 2010, 21:08

http://www.olegkikin.com/png_optimizers/

DeflOpt 2.07 results excluded or absent.

**m^2** · 6th January 2010, 21:16

Originally Posted by Surfer

http://www.olegkikin.com/png_optimizers/

DeflOpt 2.07 results excluded or absent.

Nice. Could you provide command line switches and program versions used?
Also, how about adding some different types of images? Quick thought reveals 2 things missing: a photo and something noisy.

**Surfer** · 6th January 2010, 22:46

Originally Posted by m^2

Nice. Could you provide command line switches and program versions used?

I don't know, this is not my test.

**m^2** · 6th January 2010, 22:53

Originally Posted by Surfer

I don't know, this is not my test.

OK, I emailed the author.

**maadjordan** · 7th January 2010, 01:31

try to add this http://psydk.org/PngOptimizer

pic1 = 9,900
pic2 = 20,625
pic3 = 9,358
pic4 = 95,149
pic5 = 1,156

for advancecomp try v1.6 from here http://advancemame.sourceforge.net/beta/

**SvenBent** · 7th January 2010, 11:08

since advancecomp and pngout lies so close it proves to me that the author of that test didn't use the full potential of pngout

i have tested several hundreds (thousands?) pictures and advance comp has yet to improve upon a propper made png with pngout.

unless he off cause he uses something very small png unrealistic pictures

my test goes over B/W pictures 16 gray tones, 256 colors, 256colors with dither.

-- edit --

i just downloaded pic 4 and did af simple pngout optimizing (1 trials/no bruteforcing) and get 92420bytes which in smaller then this test.

its clearly flawed in my opinion

-- edit ...
after optimizing optimal filter (was the same as orignal) and the optimal chunksize the size is now 91740 bytes

which makes pngout back on spot one.
and I haven't even done trials with the random initialization vectors

**Black_Fox** · 7th January 2010, 13:13

SvenBent, could you publish some batch file for pngout that is quick enough even for larger images (such as 1280x1024 screenshots)? I currently use this for PNG optimization:

Code:

advdef -z -4 %1
advpng -z -4 %1
pause

Depending on switches, PNGout either isn't better than that or is too slow.

EDIT: maadjordan: AdvanceCOMP 1.6 has only one new feature according to history.txt and that is not crashing on zero-size files.

**SvenBent** · 7th January 2010, 15:12

i just use these command linies

for %f in (0,1,2,3,4,5) do pngout.exe "file.png" /f%f

for %c in (0,64,128,192,256,384,512,768,1024,1536,204

do pngout.exe "file.png" /c%c

and then use deflop a last ( i ididnt use deflopt in the prior test)

i once made a multithreaded batch for this

**Skymmer** · 11th January 2010, 16:15

If you want to know my opinion about this test then listen.
First of all, every new test for PNG optimizers is useless. It has been proved before and proved again that PNGOut is the best tool out there. It comes not from the fact that you can perform some extreme bruteforcing with it but from the fact that it uses custom written deflate algorithm.
As for the test itself... From my point of view its not very good. For example look at the Pic.1. Isn't that gap between some results is strange? Surely it is. Original image is 24bit one while some output files are 256 colors. Its because the original image has 195 unique colors only so some tools detect it and shrink down the depth of the picture. Maybe its good from the optimization point of view but it also means that output files from original and shrinked images will be completely different, which is not good from the lossless point of view.
Furthermore, I believe that no full bruteforcing with some tools have been performed. For example, for Pic.1 OptiPNG's result can be 9 787 bytes with -f0 -zc9 -zm4 -zs1 -zw32768.
Also, no versions and settings used is mentioned and some tools are missing. So I'll better make my own yet another useless test

**roytam1** · 11th January 2010, 16:38

For me, I used to combine them as a suite for daily use.
my script:

Code:

@echo off
for %1 %%i in (*.png) do (
 %~dp0binmay.exe -i "%%~i" -o nul -s "00 00 00 08 61 63 54 4c" 2> nul
 if ERRORLEVEL 1 (
  %~dp0touch.exe -r "%%~i" "%%~i.time"
  %~dp0optipng.exe -zw32k -zc9 -zm9 -zs0,3 -f0,5 -i0 "%%~i"
  if not ERRORLEVEL 1 (
   %~dp0advdef.exe -z -4 "%%~i"
   %~dp0deflopt.exe -b "%%~i"
   %~dp0pngout /y /b0 "%%~i"
   if not ERRORLEVEL 2 (
    %~dp0advdef.exe -z -4 "%%~i"
    %~dp0deflopt.exe -b "%%~i"
   )
  )
  %~dp0touch.exe -r "%%~i.time" "%%~i"
  if exist "%%~i.time" del "%%~i.time"
 ) else (
  ren "%%~i" "%%~ni.apng"
 )
)

full suite:
http://rtfreesoft.blogspot.com/2009/...009-05-29.html

**Black_Fox** · 11th January 2010, 17:33

SvenBent, roytam1: Thanks for your advice, I will try to produce something "good enough" for my needs.

SvenBent, I think you meant "pngout.exe "file.png" /b%c" and not "pngout.exe "file.png" /c%c"

**Surfer** · 11th January 2010, 18:57

Приглашал автора теста к нашей дискуссии, ему лень.

Originally Posted by Oleg Kikin

Мне уже написали несколько человек, что я не использовал лучшие параметры или что-то в этом духе.

Я вижу у вас там явно неправильные параметры народ использует:

for %f in (0,1,2,3,4,5) do pngout.exe "file.png" /f%f
for %c in (0,64,128,192,256,384,512,768,1024,1536,204

do pngout.exe "file.png" /c%c

Если посмотреть help к pngout, там написано:

/c# PNG output color type: 0=Gray, 2=RGB, 3=Pal, 4=Gray+Alpha, 6=RGB+Alpha
/f# PNG output filter type: 0=none, 1=⌂x, 2=⌂y, 3=⌂x&y, 4=Paeth, 5=mixed

Видно что параметр /c не определен выше 6, а вы передаете ему 64,128,192,256,384,512,768,1024,1536,2048

Про %f я не знаю деталей, возможно он может улучшить результаты.

Олег.

Не хочу сейчас всё это переводить, если русскоговорящие форумчане сделают это, то спасибо им.

**Skymmer** · 12th January 2010, 17:51

OK, let me practise in my lame English

Originally Posted by Surfer

I've invited test author to our discussion. He is lazy.

Originally Posted by Oleg Kikin

I've already been told that I didn't use best options or something like that.

As I see the people out there use incorrect options:

for %f in (0,1,2,3,4,5) do pngout.exe "file.png" /f%f
for %c in (0,64,128,192,256,384,512,768,1024,1536,204

do pngout.exe "file.png" /c%c

If you'll look into the PNGOut help you will notice:

/c# PNG output color type: 0=Gray, 2=RGB, 3=Pal, 4=Gray+Alpha, 6=RGB+Alpha
/f# PNG output filter type: 0=none, 1=⌂x, 2=⌂y, 3=⌂x&y, 4=Paeth, 5=mixed

Its obvious that /c option is not defined for values higher than 6 and you try to feed 64,128,192,256,384,512,768,1024,1536,2048

Don't know details about /f option. Probably it can improve results.

Oleg.

I don't want to translate it now. If Russian speaking forum members will do it then thanks to them.

**Black_Fox** · 12th January 2010, 21:33

Oleg Kikin, see my previous post in this thread.

**SvenBent** · 13th January 2010, 02:01

@skymmer

the author is partly right its was a small mistake because i was writing the commands out of memory.

the /c should be /b (block treshold)

if the author has used more then just 1sec looking at the built in help he would have easily seen the right syntax.
But maybe he is not able to read English?

But if that is the reason. Then not being able to proper read the instruction for a programs place you in no right to make test and publish it since, he is obvious not doing it right.

even worse is the facts facts that he does not even know about the delta filter types.

so let sum it up

- He has no basic knowledge of what is doing
- he doesn't know how to use the tools he is using.

What ever made him to publish this POS work?

anyway you are also off on some point skymmer

>i For example look at the Pic.1. Isn't that gap between some results is strange? Surely it is. Original image is 24bit one while some output files are 256 colors. Its because the original image has 195 unique colors only so some tools detect it and shrink down the depth of the picture. Maybe its good from the optimization point of view but it also means that output files from original and shrinked images will be completely different, which is not good from the lossless point of view.</i>

you are wrong on this one

Where is the difference in reading raw 24 bits "FF.FF.FF." than reading a palette "1A" and then look up in table "1A" = "FF.FF.FF."
You still lend up with the same 24bit value.

if there is a difference in the actual image it an error in the program. NOT because you remove unused colors.

There is no need for more then 256 24bits value if you only need to store 195 of them.

**Skymmer** · 13th January 2010, 11:21

First of all, I just translated the message from Oleg. So, if you want to tell something about his test then you better address it directly to him. You can find the contact I suppose.

Off-topic: Just visited the main page of the author and got little bit excited. Obviously he is designer and photographer and I like his style. The main page is the good example of minimalistic dark design which I like. Reading the 'About' page leads me to thoughts that, if we will meet someday, then we could smoke a good bud and have a good talk.

As for me... I'm not off as you said. Please remember that test is titled as "Comparison of lossless PNG compression tools". So decode the 1_original.png and 1_pngout.png and tell me is it lossless or not.

**SvenBent** · 13th January 2010, 11:36

Originally Posted by Skymmer

First of all, I just translated the message from Oleg. So, if you want to tell something about his test then you better address it directly to him. You can find the contact I suppose.

Off-topic: Just visited the main page of the author and got little bit excited. Obviously he is designer and photographer and I like his style. The main page is the good example of minimalistic dark design which I like. Reading the 'About' page leads me to thoughts that, if we will meet someday, then we could smoke a good bud and have a good talk.

As for me... I'm not off as you said. Please remember that test is titled as "Comparison of lossless PNG compression tools". So decode the 1_original.png and 1_pngout.png and tell me is it lossless or not.

I know I just assumed he didn't knew English and was hoping for you to translate to russian for me

The bmp output of both files are identical.

Im not sure how you define lossless in this act as no compression optimizing is lossless on file bit levels. but the picture it self can be decoded back to the exact same picture you decode from the original image.
Its the exact same pictures the lies in your ram when watching these to images.

In other words there is no output difference between original and optimzing png regarding the picture bits

-- edit --

i have just quickly testet the authors 1_orignal.pmg vs 1_pngout.png and yes the output seem different (differ md5 chekcsum in the decoed 2bit bmp pictures but same size)
i dont have my tolls here at this computer. but i'll look into it.

i can say that the verifications i made when i teste my png optimizng the pciture was bit idetnical (xor the pictures made 1 collors all black pictures "000000")

I'll be back on this one later

--- edit ---
update i figure out why my decoded bmps where not file bit identical.
I used ms paint and it i think it timestmaps the pictures or something similiar.

anyway doing two decode of original with an hours in between made two bitmap files that had different md5chekcsum.

**Skymmer** · 13th January 2010, 11:56

Originally Posted by SvenBent

The bmp output of both files are identical.

Excuse me, but how the output files from 256 colours and 24bit image can be identical? I decode that files with XnView v1.94.2 and got:

Code:

1_original.bmp	589 030
1_pngout.bmp	198 102

**SvenBent** · 13th January 2010, 13:27

it can if you just decode it back to a 24bit bmp.
There is not information loss on the picture.

try to look at these three 24 bit pixels valus

Pixel values (3bytes)
123.45.123
123.52.123
123.64.123

then look at these 256 colors palette

Palette (replacement list)
1 = 123.45.123
2 = 123.52.123
3 = 123.64.123

Pixels valus 1bytes
1
2
3

Are you telling me you cant see how to get back to the original 24bits value from the palette images ?

what i just did was convert a 3 pixels 24bit pictures into a palette images

and yes i can decode it back to the original

1... oh let me look into the palette thats a 123.45.123
2... oh let me look again thats 123.52.123
3... thats 123.64.123

so the 3 pixel in the pictures is
123.45.123
123.52.123
123.64.123

Does it differ from the pixels values above? NO the is no loss in going from 24bit image to 256 pallet image if you don't have more then 256 different colors.

If there is something/someone is doing it wrong

please forgive spelling errors as im witting with my left hand while working.

**Surfer** · 13th January 2010, 13:55

Author isn't interested in comparison anymore, I think.
Anyway, we can do our own test

With this or other samples.

**AiZ** · 13th January 2010, 16:29

Hi,

If you like that, playing endlessly with parameters and switches, I give you a (small) challenge : put the VGA pattern of my webpage below the 1K mark. Really easy, you only have to shave 4 bytes to win...

Then, if you can reduce the weight of all PNGs below 45K (46080 bytes), I'll give you... full credits in my homepage for this unbelievable breakthrough!!!

Have a nice day,

AiZ

**schnaader** · 13th January 2010, 16:54

Originally Posted by AiZ

[...]I give you a (small) challenge[...]

Hm... I would vote for a complete change of the site, f.e. create a small Java program or some kind of script that generates the pictures on the client - that should be far below 45K...

Procedural PNG format, anyone?

Hmm.. procedural image format perhaps? Ah, wait - SVG! And with SVGZ, you can still use zLib. Although I don't know if the fixed 1px vertical lines are possible in SVG, could perhaps be done with some patterns.

By the way:

Code:

all_17_pngs.zip           7116 bytes
all_17_pngs.rar           6570 bytes
all_17_pngs.7z            3438 bytes
all_17_pngs.paq8o8_3      3326 bytes
all_17_pngs.paq8o8_4      3130 bytes

Precomp hurts compression here as only 15 images can be recompressed correctly.

The XBM files make me think about a Precomp filter that converts C byte arrays to binary files (if XBM files had a header, they could be converted to BMP, but detecting only two defines and a array declaration would surely give too many mismatches).

**M4ST3R** · 13th January 2010, 17:34

Originally Posted by AiZ

Hi,

If you like that, playing endlessly with parameters and switches, I give you a (small) challenge : put the VGA pattern of my webpage below the 1K mark. Really easy, you only have to shave 4 bytes to win...

1021 bytes

**caveman** · 16th February 2010, 05:23

You'll find a thread about the pngslim script written by Andrew Dent in this forum:
http://www.jonof.id.au/forum/index.php?topic=846.45

pngslim uses most of the tools compared here and to my knowledge it gives the best results, it's available here:
http://people.bath.ac.uk/ea2aced/tech/png/pngslim.zip

**Intrinsic** · 16th February 2010, 11:16

I never posted about pngslim because it's a massive script that will brute force try and compress and can take hours to run on normal sized images of around 1280x1024 for example. For very very small images it is usable though but can be beaten by hand-tweaking of an image file as M4ST3R showed(would be cool to know what he used/how he got the file that small)

There is also PNGOpti, another script but a lot faster. http://midimaniacs.xhost.ro/pngopti/PNGopti.zip

You can add single file drag n drop file support to this script by adding the following lines at the top:

Code:

@echo off
setlocal enabledelayedexpansion
set PNGOptiDir=%~dp0
PATH %PNGOptiDir%;C:\Program Files\ImageMagick\;%PATH%
%~d1
CD %~p1
cls

in place of

Code:

@echo off
setlocal enabledelayedexpansion
PATH C:\Program Files\ImageMagick\;%PATH%
cls

**SvenBent** · 19th February 2010, 10:34

@ skymmer

Did you fix you 24bit vs palette issues ? or do you still believe that you need to store information about colors you don't use in the pictures?

The debate was never really ended. Just suddenly no response...

**M4ST3R** · 20th February 2010, 03:09

Originally Posted by Intrinsic

For very very small images it is usable though but can be beaten by hand-tweaking of an image file as M4ST3R showed(would be cool to know what he used/how he got the file that small)

pngoutwin

**Intrinsic** · 20th February 2010, 11:17

Originally Posted by M4ST3R

pngoutwin

Oh lol, i thought it was something special. I have that and was the only tool i didn't try heh. And just tried it and hit that number on the 1st job slot ;p

**caveman** · 22nd February 2010, 04:26

Originally Posted by AiZ

Then, if you can reduce the weight of all PNGs below 45K (46080 bytes), I'll give you... full credits in my homepage for this unbelievable breakthrough

pngout -n1 -f5
will get you down to 47698 bytes (47801 previously):

3529 fullhd.png
4059 qwxgapattern.png
1325 svgapattern.png
2884 sxga+pattern.png (-50 was 2934)
2739 sxgapattern.png
3544 uxgapattern.png (-17 was 3561)
1021 vgapattern.png (-6 was 1027)
6379 wqxgapattern.png
3214 wsxga+pattern.png (-6 was 3220)
2574 wsxgapattern.png (-3 was 2577)
3934 wuxgapattern.png (-1 was 3935)
1980 wxgapattern1.png
2103 wxgapattern2.png
2181 wxgapattern3.png
2158 wxgapattern4.png (-9 was 2167)
2167 wxgapattern5.png (-4 was 2171)
1907 xgapattern.png (-7 was 1914)

**AiZ** · 22nd February 2010, 12:32

Hello,

Originally Posted by caveman

pngout -n1 -f5
will get you down to 47698 bytes (47801 previously):

Merci ! I'd never thought that a "vanilla" pngout would take it any further...

Last script I've used to obtain my current set was plain ScriptPNG, after a (long) pass of a simplified pngslim.

AiZ

Thread: Comparison of lossless PNG compression tools

Thread Tools

Search Thread

Display

Comparison of lossless PNG compression tools

pngslim : one script to rule them all

Great!

Similar Threads

LZW, LZMW and LZAP comparison

unpackmp2 - a preprocessor for lossless compression programs

Interesting tools

exe prefilter quick comparison

Easy way for BMF to png

Tags for this Thread

Posting Permissions