"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  --  [EMAIL PROTECTED]  --  this night wounds time

Reply via email to