[vox-tech] PNG tweaking - how to 'kill' RGB in 100% transparent pixels

Bill Kendrick nbs at sonic.net
Sun Mar 5 15:11:11 PST 2006


So I've got 355-and-counting PNG images in Tux Paint's 'stamps' collection.

Many of these were photos which were resized, and had the backgrounds
removed (using the Eraser and selection tools in The GIMP), and then saved
as RGBA PNG files.

By default, I GIMP saves PNGs with the following option set:
"Save color values from transparent pixels."

This is nice for editing later, since you can use the Eraser tool
in 'Anti-erase' mode, to bring those pixels page.
(In other words, when erasing, Gimp doesn't touch the RGB channels, just
the Alpha channel.  A solid erase simply makes Alpha 0.  Anti-erase brings
it back to 255.)

However, this is NOT nice when you no longer care about the erased pixels,
as it just ends up being wasted space in the PNG.  By that I mean the PNG
compression is wasting its time and energy (and disk space) worrying about
the RGB channels of pixels which are 100% transparent.

If it were a solid color, it would compress a lot more.
(I believe Gimp uses its, or the PNG's, "background" color when you
uncheck the "Save color values from transparent pixels" option.)


While I could simply load up all 355 PNGs into The GIMP and resave
them one by one -- making sure the "Save color values..." is unchecked --
that would take a long time.  Additionally, since the project is growing,
and I don't really feel like keeping track of which PNGs are "golden",

I was hoping to make a script that I could run on occasion (say, before
release, or after adding a batch of new PNGs).  My initial thought was
to use "pngcrush."

I have one immediate problem.  Debian/sid's pngcrush is currently b0rked:

  Warning: versions are different between png.h and png.c
    png.h version: 1.2.7
    png.c version: 1.2.8
  [...]
  pngcrush: relocation error: pngcrush: symbol png_read_data, version PNG12_0
  not defined in file libpng12.so.0 with link time reference


Worse, though, is that "pngcrush" on a Debian/stable machine I have
access to doesn't seem to actually remove the 100% transparent pixels,
nor do I see any obvious means by which to do so.  (The best crushing
I get on "stamps/animals/birds/ostrich.png" is 0.17%, if I recall correctly.)


NetPBM is pretty useless to me for this problem, since the PPM format
doesn't support Alpha -- it's only RGB.  ImageMagick's "convert" didn't
seem useful, either.

Aside from writing my own C app that loads a PNG and then rewrites it
(altering the RGB to some solid color for every 100% transparent pixel),
does anyone out here have any suggestions?

(I'm not against writing my own C app, but... if it's been done already,
why bother? ;^) )

Thanks!!!

-- 
-bill!                                    Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com                CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/       http://www.cafepress.com/newbreedsw


More information about the vox-tech mailing list