let me introduce you a new tool called Huffmix.
As you probably know PNG and Gzip compression is based on Deflate.
A Deflate stream is made of one or more blocks.
PNGOUT/KZIP lets you choose how many blocks it produces (-n option, or -b to set the block split threshold).
PNGOUT/KZIP also has a random switch (-r randomized initial tables "good for many trials with same options", this is -rn in KZIP).
PNGSlim alike scripts used to run hundreds of random trials in a row and only kept the smallest PNG file produced (this takes a lot of time).
Huffmix compares two files produced in random mode and cherry-picks the smallest blocks to combine them into a new file.
For instance if we have 3 blocks.
block 1: 110 bits
block 2: 317 bits
block 3: 272 bits
Overall: 699 bits
block 1: 104 bits
block 2: 312 bits
block 3: 289 bits
Overall: 705 bits
Until now optimization scripts would have kept File A and deleted File B (since A is smaller than B), Huffmix combines File A and File B into File C by picking the smallest blocks, this gives:
block 1: 104 bits (from File B)
block 2: 312 bits (from File B)
block 3: 272 bits (from File A)
Overall: 688 bits
We end up with a smaller file and managed to take profit of the calculations done to produce the biggest file, it works like a catalyst.
Of course since there's randomness involved it will not always work as demonstrated, nevertheless my first tests suggests that it actually works pretty well.
After about 20 cycles of pngout + deflopt + defluff + huffmix these 3 already optimized files are now a few bytes smaller:
bigmac.png 33906 -> 33902 bytes
getadrink.png 65317 -> 65293 bytes
mouse.png 105035 -> 104866 bytes
Huffmix 0.6b1 is available for testing.
Usage: huffmix [options] file1.[png|gz] file2.[png|gz] output.[png|gz]
-k Keep same block sequence as in first file
output can be the same as file1 or file2 (this is a fast and easy way to screw your file if there's a bug in Huffmix, you have been warned)
- solves some "Could not find matching sub-blocks" problems
- internal number of Deflate blocks limit set to 1024
- a memory allocation bug correction (led to rare segfaults or unexpected EOF)
- handles .gz files (gzip files created by kzip2gz)
- internal number of Deflate blocks limit set to 600
- a memory allocation bug correction (led to rare segfaults)
- new -k and -q options
- Huffmix has its own webpage : http://frdx.free.fr/huffmix/
- no longer copies the input file if it's the same as the output.
- allows you to combine files with different numbers of blocks (e.g. -n3 and -n5).
Occasionally this will produce files that have different blocks compared to those produced by PNGOUT, use the -k option to preserve the block sequence.Code:File Type C-Offset C-Length U-Offset U-Length A 2 0 289296 0 200724 A 2 289296 11622 31014 46169 A 2 300918 34023 3c46d 54457 File Type C-Offset C-Length U-Offset U-Length B 2 0 110543 0 75987 B 2 110543 104305 128d3 67393 B 2 214848 75383 23014 57344 B 2 290231 11608 31014 46169 B 2 301839 34029 3c46d 54457 File C-Offset C-Length A 0 289296 B 290231 11608 A 300918 34023 IDAT new size 41872 (0xa390) bytes, saved 14 bits, output file size 41929 bytes
To ensure that PNGOUT will not modify filter or palette entries it has to be called with these options:
pngout -ks -kp -f6
There was a bug in PNGOUT in -f5 mode. Use the latest version of PNGOUT (May 2012 or February 2013) with Huffmix.
For instance a simple Huffmix roundtrip looks like this:
Start over again.Code:pngout -force -ks -kp -f6 -r -y my_file.png my_temp_file.png defluff <my_temp_file.png >my_defluffed_temp_file.png huffmix my_file.png my_temp_file.png my_file.png huffmix my_file.png my_defluffed_temp_file.png my_file.png or kzip -rn -y my_temp_file.zip my_file kzip2gz my_temp_file.zip my_temp_file.gz defluff <my_temp_file.gz >my_defluffed_temp_file.gz huffmix my_file.gz my_temp_file.gz my_file.gz huffmix my_file.gz my_defluffed_temp_file.gz my_file.gz
- FreeBSD version
- Code clean up
- Handle type zero blocks
- Add support for full .zip files
- Remove limitation on internal number of Deflate blocks (1024 since 0.5b4)