Hi folks!

A while ago, someone raised the possibility of recompressing PNG files. 
Unlike xz, this would save space not only on mirrors but also on live
installed systems.  PNGs are nearly incompressible so this is mostly
independent from xz.

At least by number, there's a lot of PNG images:

zgrep -i '\.png ' Contents-*gz|wc -l
 577815
zcat Contents-*gz|wc -l
4296965 (including 3*35 lines of header)

This massive number of files seems to be concentrated mostly in a limited
number of packages:

  35276 widelands-data
  28827 libjs-mathjax
  22225 ns3-doc
  19968 jsmath-fonts
  13395 openclipart2-png
  13296 freefoam-dev-doc
  10271 w3-recs
   9877 uqm-content
   9643 wesnoth-1.11-data
   9015 wesnoth-1.10-data
   8120 openclipart-png
   6773 oxygen-icon-theme
   6546 lxde-icon-theme
   6272 mixxx-data
   5890 gnome-icon-theme
   5068 triplea
   4641 tuxfootball
   4505 gnome-themes-extras
   4180 gnome-colors-common
   3780 lilypond-doc

Some time ago, I tested a number of png optimizers, and the best results, by
far, come from using "optipng -o4 -i0 -fix" then "advpng -z4".  The former
attacks the payload well, then advpng (package advancecomp) has good deflate.
-o4 is there because higher optipng levels mess only with zlib arguments,
-i0 because advpng is afraid of interlaced files (why?), -fix because advpng
refuses to touch files with certain errors like cruft after the end, as
Adobe tools like to leave.

I did test the alternatives quite thoroughly, but the corpus I needed that
for was quite specific.  It's possible some other set of tools might be
better in general; these settings are the highest for optipng+advpng that
make sense, though.


So here are the results:

              size(MB)      o    o+a
widelands-data     105  95.1%  93.4%
libjs-mathjax       29  99.0%  98.5%
openclipart2-png   476  99.6%  99.4%
w3-recs             16  88.4%  84.2%
wesnoth-1.11-data   89  98.3%  98.1%
fonts-mathjax-extra  4  94.6%  90.0%
(sizes include .png images only, o is optipng, o+a optipng+advpng)

Nothing stunning, I'm not sure if savings of this kind are worth a lot of
heed.  I'd probably be good to have a common tool somewhere, to not reinvent
the wheel for every package.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130526155606.gb2...@angband.pl

Reply via email to