Page 1 of 1
Posted: Thu Jan 19, 2006 2:52 pm
This program is a frontend for PNGout, but is much easier to use. Simply run it, choose some files to turn into optimized PNGs, choose a destination folder, check the brute force option, and go. This results in files that are usually at least 15~20% smaller than even an already optimized PNG. When converting BMPs (like from many emulators), it can result in files that are only 1~2% of the original filesize.
PNGGauntlet requires the .NET framework. This should already be installed on XP, but 9x users will need to install it (don't know about NT/2k). PNGGauntlet is only about 200k, and seems to include PNGout (which is only about 40k anyway).
Posted: Wed Jan 25, 2006 4:15 am
It seem "brute force" doesn't use "/d" option.
I tried with a series of GIF files (retrived from here
) which all of them are 4 bit (have less than 16 colours). PNGGauntlet use "/d4" to all those GIF files in stead of "/d8".
I suspect that PNGGauntlet will use the bit depth depend on how many colours are used in that file. Actually, sometime, using "/d8" will give the best result for ≤8-bit PNG.
Posted: Wed Jan 25, 2006 12:45 pm
I think it does choose the bit depth based on the number of colors in actual use (although not on the bit depth of the input image). When I first tested it, I used it on some 24bit BMPs. Some of the BMPs only used a handful of colors while some used quite a few colors (they were video game screenshots), pnggauntlet made the images 2, 4, or 8bit color depending on how many colors were in use in that image.
Posted: Thu Jan 26, 2006 11:21 pm
So, Does that mean PNGGauntlet don't use every possible way to make the smallest output?
Even though input files are in 2 or 4 bit, the smallest filesize can be achieve by using 8 bit colour depth. Well, with brute force, PNGGauntlet should try every option to produce the best output.
Posted: Fri Jan 27, 2006 1:05 pm
I have never seen a case where 8bit depth achieved a smaller file than 2 or 4bit depth.
If you start out with an image that's in 24bit mode (but has 256 or fewer colors in actual use), pnggauntlet will try several color modes. I haven't noticed on other starting bit depths.
Just watch the status window while it's compressing the image (or scroll back through it after it's done) and you will see messages like "trying 8bit...no. tryinging 4bit...no, etc).
Posted: Sun Jan 29, 2006 12:41 pm
Drahken wrote:I have never seen a case where 8bit depth achieved a smaller file than 2 or 4bit depth.
I tested with this file
. It is 4-bit GIF file containing 15 colours. I converted it to PNG with PNGOUT (12/26/2005 version) which resulted in 8-bit file is smaller than 4-bit file. These are screentshots of results; 4-bit
. However, the difference is not significant, just 451 bytes.
Posted: Mon Jan 30, 2006 12:40 pm
Very strange. What's even stranger is that I ran it through pnggauntlet and got very similar (yet different) results. The 4bit version came out the exact same size as yours did. The 8bit version did come out smaller, but only by 100bytes.
Posted: Tue Jan 31, 2006 1:22 am
Additionally, with some 1-bit files, 4-bit mode could give better compression. For example, this 1-bit GIF file
. I tried compressing it with all bit depth. 1-bit mode gives the worst compression whereas 4-bit mode produces the smallest filesize. (results
I found a post
about this behaviour in another forum as well. This statement was posted since 2003.
Dioxaz wrote:...PNG had been designed to compress palette images better in fewer bit depthes when they display 16 colors or less and grey images in 16-color greyscale or less. But that's not always true. Oddly, most 16-color or 2-color images I have on my hard disk compressed better when saved... in 8-bit mode!!