Kevin Turner wrote: > <snipped...> > Thing is, gimp does erase/clear by setting the alpha component to fully > transparent, but doesn't touch the other channels. So you can load up > that image again, move the alpha channel back to opaque, and the > background you erased comes back in full detail. > > This isn't a bug, True <snippage...> > The "GIMP That's Smarter Than You > Are" (sponsored by the Corporation for Using Technology to Further Human > Inferiority Complexes) could detect this fairly trivially, and ask if > you really meant to be saving that stuff. The semi-lossy filter could > be as simple as this mathmap[1] filter: > > if alpha(origVal(xy)) == 0 then rgba:[0,0,0,0] else origVal(xy) end <snippage...> IMHO, this is ninety-five percent a documentation problem. (1) Much of Gimp treats the 'A' as just another color component (some parts don't) and if there is high information content in R, G, B, then - among other things - lossless compression won't compress much. (2) I trust the user in choosing between information content and compression, so long I walk the mile in telling her that this is a choice to be considered. Then she can write/invoke the macro or deliberately set R = G = B = A = 0 in all regions deemed transparent before writing out to file. (3) If someone wants to write something in Gimp core or the png plug-in to automagically clean up after the user, it's presence should be made known and its activation optional. My two cents. Be good, be well Garry Osgood
