pngquant
pngquant is a batch conversion utility to quantize and dither truecolor PNG images, especially those with a full alpha channel, down to "RGBA-palette" PNGs (i.e., PLTE + tRNS in PNG parlance). Such images are usually two to four times smaller than the full 32-bit versions, and partial transparency is preserved quite nicely. This makes pngquant especially useful both for Web sites and for PlayStation 2 development, where one of the texture formats is RGBA-palette-based (though not PNG-compressed).
| Tags | Graphics Graphics Conversion Utilities PNG Compression |
|---|---|
| Licenses | BSD Original |
| Operating Systems | Windows Windows POSIX |
| Implementation | C C99 |
Recent releases
- 23 Dec 2011 13:21
Release Notes: This release changes the dithering algorithm to add noise only on flat areas of the image, makes remapping adapt to contrast and noise in the image, increases the quality of post-processing palettes, and improves speed.
- 23 Dec 2011 13:21
Release Notes: This release changes the dithering algorithm to add noise only on flat areas of the image, makes remapping adapt to contrast and noise in the image, increases the quality of post-processing palettes, and improves speed.
- 23 Dec 2011 13:21
Release Notes: This release changes the dithering algorithm to add noise only on flat areas of the image, makes remapping adapt to contrast and noise in the image, increases the quality of post-processing palettes, and improves speed.
- 12 Jun 2002 12:55
Release Notes: Version 1.0 is primarily confirmation that 0.95 was more than stable enough to have been called 1.0 itself. The Unix makefile has also been cleaned up, and the Linux/glibc binary was recompiled against zlib 1.1.4 for karmic maximization.
- 30 Jan 2001 06:13
Release Notes: This release includes a couple of palette-size and sample-depth bugfixes, and Win32 is now supported.
Recent comments
I've made several improvements to the algorithm: pornel.net/pngquant
Re: problems with colour selection algorithm
I know photoshop doesn't do 8-bit pngs with alpha-transparancy, but my point was that the palette reduction algorithm is poor.
I now use Web Image Guru which has both good colour selection and alpha transparancy.
Thanks for your help anyway
Re: problems with colour selection algorithm
(Wow, freshmeat's quote-formatting sucketh greatly...)
I've looked at your test images in fair detail, and there are at least two issues at play here (though they're related). The first is simply that the Photoshop version is basically a GIF. That is, it's formatted as a PNG, but it may as well be a GIF: it's got one completely transparent palette index, and everything else is completely opaque. I assume you tried displaying it against a background color that's not black; it looks like crap. There's no antialiasing at all.
The second issue is the color selection for the opaque parts. You're correct that both pngquant and pngnq have done a poorer job of that than Photoshop did, but what you have to realize is that it's a zero-sum game: if you want a small palette and nice colors, then you give up anitaliasing (Photoshop); if you want a small palette and decent antialiasing, then you give up the nice color selection (pngquant/pngnq); and if you want both nice colors and decent antialiasing, then you spend some bytes on a decent-sized palette--say, 128 to 256 entries (pngquant/pngnq with appropriate target, not present in your test set).
In short, PNG does not support indexed color with a separate alpha channel--it's a single (index) channel backed by an RGBA-palette. If you want more than one shade at the edge to have some level of transparency, then you need to spend a palette entry on each and every one of those pixels.
As a side note, keep in mind that every palette entry is potentially an approximation in all four samples. In particular, you can end up with some formerly opaque pixels becoming slightly transparent--typically those that are shared between the interior and the edge in a case like this. This is visible to some extent in all three of the pngquant/pngnq images (or do something like "pngtopnm -alpha foo.png | xv -expand 8 -" to inspect just the alpha "channel", for example).
Re: problems with colour selection algorithm
>
> % I noticed that some images converted
> by
> % pngquant are lower quality compaired
> % with the photoshop "save for
> % web" feature. [...]
>
>
> If you have a sample image (original,
> pngquant version and corresponding
> command, and Photoshop version), you
> could send it to me. But I suspect
> you've simply run into a fundamental
> limitation of the median-cut algorithm.
>
> A modified pngquant that instead uses
> the NeuQuant algorithm is also
> available; check the PNG
> image-converters page or your favorite
> search engine for "pngnq". Please let
> me know if you find its quality
> significantly better (or worse ;-) ).
>
> Greg
Hi Greg,
Thanks for your answer.
Yeah, I tried out pngnq as well. Didn't notice any improvement on the images I am using.
These are the results I got:
origonal 16-bit image:
8-bit image created with photoshop "save for web" feature ( with black
matt colour)
8-bit image created with pngnq 32 colours
8-bit image created with pngnq 64 colours
8-bit image created with pngquant 32 colours
Re: problems with colour selection algorithm
> I noticed that some images converted by
> pngquant are lower quality compaired
> with the photoshop "save for
> web" feature. [...]
If you have a sample image (original, pngquant version and corresponding command, and Photoshop version), you could send it to me. But I suspect you've simply run into a fundamental limitation of the median-cut algorithm.
A modified pngquant that instead uses the NeuQuant algorithm is also available; check the PNG image-converters page or your favorite search engine for "pngnq". Please let me know if you find its quality significantly better (or worse ;-) ).
Greg
pornel
28 Dec 2000 11:30
Heartbeat
- Popularity Score
- 66.14
- Vitality Score
- 7.24
- Subscriptions
- 5
