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

[Jonathan Stickel]

Have you looked at ImageMagick's "convert" utility?  It is a fairly 
powerful tool with many options.  As a brute-force method, converting to 
some format that doesn't support transparency, and then back again, 
might work for you.

Jonathan


Bill Kendrick wrote:
> 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!!!
>