"Steinar H. Gunderson" wrote: > GIMP already does this (32-bit = RGBA, the `extra' 8 bits is an alpha channel, > used for transparency information), and has done for a long time now. OK, this has been bugging me for some time. I'm convinced that Gimp's alpha handling is wrong, in more than a few places. (Minor disclaimer - I don't have the code in front of me right now, so I'm not going back to check details. And I'm not an expert on the Gimp, but I do know a fair amount about image processing.) To start with, there should be a clear distinction between alpha, which is a transparency channel in an image and should always scale the pixel colour values; and masks, which serve to select areas of an existing image. (Yes, I know not all rgba images are pre-multiplied. They should be.) At the moment, as far as I can tell, the Gimp cannot handle pre-multiplied rgba images. Example: render an rgba image. (I was using some PovRay output; I presume it does a reasonable job.) Now create a flat colour background in the Gimp, lay the rgba image on top, and try to get a clean composite without black fringing. I don't think it can be done, though I'd love to be proven wrong. (There could be issues here with different gamma handling between PovRay and the Gimp, but I suspect the problem is simply a failure to handle rgba properly.) At the same time, much of the code for handling alpha data seems to unscale and rescale the colour channels. This may be necessary for colour manipulations on pre-scaled rgba images, but for anything else (transforms, blurs etc.) it is unnecessary for either alpha or masks. Example: take the example above, but rotate the rgba image first. The result is fairly ugly. Any comments? -- David Hodson -- hodsond@xxxxxxx -- this night wounds time
