Evidence? - amake

Care to support that claim of "more stable and effective?"

Reply to This

Sunday, May 29 2005 @ 06:47 PM PDT

There's an alternative... - polymnemonic

they are the same, in every respect (except application icon, and the fact that pngcrushrrrrrr doesn't overwrite your original file), both use the pngcrush command line application and presumably the same options. every test i ran took the same time (within 10 seconds or less of each other), both are exceedingly time consuming, photoshop went from 156mb psd -> 30mb png faster than either went from 30mb png -> 29mb png (this may have more to do with the pngcrush source than either application though), ended up the same exact size (in bytes), and retained the same quality. i tried on the full spectrum of of input files, from > 800k 1680x1050 screen shots up to 30mb 6000x4000 24-bit semi transparent compressed psd's.

Reply to This

Friday, June 10 2005 @ 01:09 AM PDT

There's an alternative... - amake

Actually that's not quite right. I took a look at his code, and found that there are 3 major differences:
1) PNGCrushrrr is written in Python instead of Bash
2) PNGCrushrrr calls pngcrusher with the -brute option, which makes it significantly slower without much improvement in compression
3) PNGCrushrrr doesn't replace your original files.
Python vs. Bash doesn't make any difference for an app this small, and the other two points are moot now that PNGCrusher uses the superior OptiPNG.

Reply to This

Friday, June 10 2005 @ 02:33 AM PDT

There's an alternative... - polymnemonic

they are the same, in every respect (except application icon, and the fact that pngcrushrrrrrr doesn't overwrite your original file), both use the pngcrush command line application and presumably the same options. every test i ran took the same time (within 10 seconds or less of each other), both are exceedingly time consuming, photoshop went from 156mb psd -> 30mb png faster than either went from 30mb png -> 29mb png (this may have more to do with the pngcrush source than either application though), ended up the same exact size (in bytes), and retained the same quality. i tried on the full spectrum of of input files, from > 800k 1680x1050 screen shots up to 30mb 6000x4000 24-bit semi transparent compressed psd's.

Reply to This

Friday, June 10 2005 @ 01:15 AM PDT