Intro
There are three color modes available in PNG. The mode with the fullest color space is RGB 24 bit. The second mode is indexed. It allows you to use 8 bits or less for up to 256 colors. Additionally, it allows you to choose the palette. The last mode is grayscale. As the name implies it's black and white, but allows a gradient of grays. By comparison, a 1 bit indexed mode would only allow full black or full white, no grays.
Generally, switching to indexed offers a pretty big savings in file size. However, you can often get even greater savings by going to less than 8 bit color. Doing so will generally require generating a custom palette to take full advantage of the reduced color space. If the file is black and white, it can sometimes be worth it to switch to grayscale or to 1 bit indexed.
There really is no simple way to know which will be best, besides trial and error. Doing this for one file is a bit annoying, but doing it for many files is pretty unreasonable. As such, many PNG compressors have popped up to help automate this process.
It turns out that the compression process is not so clean cut, and thus many of the various programs perform differently on various files. I decided to look into if my current program was a good choice. I found a few old comparisons, but not any from the last few years. I decided to just download a bunch of programs and try them out.
I didn't download too many, preferring those that either had recent development, or were spoken highly of somewhere.
Programs Tested
So without further ado, here are the candidates:
TinyPNG - Has been my go to. It's the only web based option here. It's quite fast and has a great interface.
pngquant v1.8.3 - Some research showed that pngquant was the library being used at TinyPNG. I figured if I could have the same compression as TinyPNG as a command line tool, that would be ideal.
pngcrush v1.7.9 - This is the standard PNG compression utility.
optipng v0.7.4 - Another standard utility, based on pngcrush.
pngout 20130221 - Based largely on the recommendation of this 6 year old Jeff Atwood post. It is still being developed though.
Before I get into the results I should note the command line switches used. In all cases its none. Some of the utilities are geared more towards automatic use than others. There is no doubt you could achieve much better results if you were willing to experiment with the options. However, that wasn't the use case I was testing here. I was concerned with processing dozens or more files quickly and easily.
If you want to see the images used I uploaded them to imgur here. Unfortunately, imgur is no dummy, they compressed the files themselves. They also resized the largest ones and converted some to jpg when that made sense. If you want all the files, both the original and the results, I uploaded them as a zip to mediafire.
Results
Filesizes in KB:
| Name | Original | optipng | pngcrush | pngout | quantpng | tinypng | t2o | smallest | |
 | a.png | 885 | 765 | 879 | 769 | 335 | 329 | 328 | 328 |
 | b.png | 5.74 | 3.22 | 5.05 | 2.77 | 3.36 | 3.27 | 3.27 | 2.77 |
 | c.png | 2727 | 2723 | 2720 | 2582 | 2725 | 2587 | 2583 | 2582 |
 | e.png | 84.6 | 32.4 | 84.6 | 37.2 | 33.2 | 32.4 | 32.4 | 32.4 |
 | f.png | 22.9 | 19.7 | 20.9 | 16.4 | 19.6 | 18.1 | 16.6 | 16.4 |
 | g.png | 44.2 | 17.6 | 23.6 | 31.3 | 15.0 | 14.0 | 13.5 | 13.5 |
 | i.png | 717 | 550 | 616 | 529 | 189 | 181 | 181 | 181 |
 | m.png | 30.7 | 29.1 | 29.1 | 26.8 | 29.4 | 27.9 | 27.1 | 26.8 |
 | n.png | 48.0 | 47.9 | 48.0 | 42.5 | 26.6 | 25.6 | 24.0 | 24.0 |
 | o.png | 22.2 | 22.2 | 22.2 | 19.1 | 22.2 | 22.2 | 19.1 | 19.1 |
 | p.png | 1044 | 1019 | 1019 | 973 | 288 | 281 | 281 | 281 |
 | r.png | 545 | 188 | 243 | 174 | 188 | 174 | 174 | 174 |
 | s.png | 476 | 311 | 316 | 352 | 156 | 147 | 146 | 146 |
 | t.png | 11.6 | 11.6 | 11.6 | 11.6 | 12.6 | 12.0 | 11.6 | 11.6 |
 | w.png | 79.4 | 58.7 | 59.9 | 73.7 | 39.8 | 36.5 | 36.1 | 36.1 |
 | x.png | 60.7 | 60.7 | 60.7 | 60.2 | 61.9 | 58.6 | 58.6 | 58.6 |
 | y.png | 90.0 | 78.9 | 90.0 | 70.8 | 48.0 | 45.1 | 42.2 | 42.2 |
 | z.png | 104.6 | 104.6 | 104.6 | 102.1 | 52.6 | 50.8 | 50.0 | 50.0 |
| sum | 7000 | 6043 | 6354 | 5873 | 4246 | 4045 | 4027 | 4025 |
Ratio to the best compression method:
| Original | optipng | pngcrush | pngout | quantpng | tinypng | t2o | |
| a.png | 270% | 233% | 268% | 234% | 102% | 100% | 100% |
| b.png | 207% | 116% | 182% | 100% | 121% | 118% | 118% |
| c.png | 106% | 105% | 105% | 100% | 106% | 100% | 100% |
| e.png | 261% | 100% | 261% | 115% | 102% | 100% | 100% |
| f.png | 140% | 120% | 127% | 100% | 120% | 111% | 101% |
| g.png | 326% | 130% | 174% | 231% | 111% | 103% | 100% |
| i.png | 397% | 304% | 340% | 292% | 105% | 100% | 100% |
| m.png | 114% | 108% | 108% | 100% | 109% | 104% | 101% |
| n.png | 200% | 200% | 200% | 177% | 111% | 107% | 100% |
| o.png | 116% | 116% | 116% | 100% | 117% | 117% | 100% |
| p.png | 372% | 363% | 363% | 347% | 102% | 100% | 100% |
| r.png | 314% | 108% | 140% | 100% | 108% | 100% | 100% |
| s.png | 326% | 213% | 217% | 241% | 107% | 101% | 100% |
| t.png | 100% | 100% | 100% | 100% | 108% | 103% | 100% |
| w.png | 220% | 162% | 166% | 204% | 110% | 101% | 100% |
| x.png | 104% | 104% | 104% | 103% | 106% | 100% | 100% |
| y.png | 213% | 187% | 213% | 168% | 114% | 107% | 100% |
| z.png | 209% | 209% | 209% | 204% | 105% | 102% | 100% |
| sum | 174% | 150% | 158% | 146% | 105% | 100% | 100% |
| geo | 201.0% | 152.0% | 174.1% | 152.2% | 109.0% | 103.9% | 101.1% |
In the first table sum for all columns is just the sum of the column. In the second table sum is the ratio of sum to the smallest sum. In other words, a sum ratio of 100% should indicate a perfect score, but it's skewed by the large file sizes. The geometric mean solves this for the normalized ratios. Or does it? Yeah, probably.
Analysis
I think the take away here is that TinyPNG is the winner. That being said, you'll note there were three cases where it did significantly worse than pngout. Images b and o were both black and white, and pngout turned b into grayscale, but both left o as indexed. What's more, e was grayscaled by pngout for worse size than the indexed tinyPNG version. Pretty clear evidence that grayscale vs indexed isn't clear cut.
quantpng is consistently a few percent higher than TinyPNG, lending credence to the idea that TinyPNG is using quantpng, but then also doing something else to squeeze a bit of filesize out. On the other hand, quantpng actually made a few files worse, so maybe there is some overhead on its end.
The alert reader will have noticed there is a seventh algorithm listed which wasn't defined above. t2o is a response to the fact that either TinyPNG or pngout was the optimal algorithm. It is the TinyPNG files ran through pngout.
While it almost always does better than TinyPNG or pngout alone, you'll note the one case where it failed to return to the level pngout had achieved on the raw file.
I suppose my strategy will be to continue to use TinyPNG, and if I really need to minimize a file, run it through pngout independently, and compare the results.
No comments:
Post a Comment