[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: optimizing PNGs



Hi Adam,

On Sun, May 26, 2013 at 05:56:06PM +0200, Adam Borowski wrote:
> A while ago, someone raised the possibility of recompressing PNG files. 

From my brief experience of working on games-thumbnails, I can appreciate that
the space savings may well be worth it at scale, but performing
compression/optimisation at package build stage is a major PITA. For
lossless-compression, there's no reason for the compressed PNGs to not be
integrated upstream (esp. in the case of local packages like games-thumbnails).

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

What isn't clear here is whether these packages full of PNGs are already
efficiently compressed or not.

> So here are the results:

How did you decide on which packages to sample from the above list?

> fonts-mathjax-extra  4  94.6%  90.0%

This (at least) didn't appear in the above list.
 
I think an ideal solution would be a central/separate PNG recompression service
that could alert maintainers if their PNGs were not optimal (bug perhaps? "Dear
maintainer, foo.png in your package could be more optimal! Perhaps replace it
with pngcrush.debian.net/v1/srcpackage/path/foo.png"?) rather than
maintainers/buildds paying the compression cost. If compressed PNGs could be
annotated with some metadata indicating that they were recompressed (or checked
for recompression), then that might help to avoid costly recompression
attempts. (foo.png is marked up that pngcrush.debian.net compressed it with
version 1 of it's preferred compression solution; bar.png with version 2¸
current is version 3, recompress both… or perhaps pngcrush.debian.net could
maintain checksums for files it has already checked.)


Reply to: