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.) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20130528130106.GB20013@debian
