Re: 32-bit images in gimp - Alpha handling wrong?
On Wed, Jul 19, 2000 at 11:53:30PM +1000, David Hodson <[EMAIL PROTECTED]> wrote: > > No: > > No? If I render an object, and the edge of that object only covers > half of a pixel, why does it need more than half the colour range? I was talking about precision and not resolution. > is that I could load an image file containing pre-multiplied alpha > without being asked if the alpha should be un-multiplied. (Although > I still think there's a useful distinction between pre-mult alpha > and non-mult masks, and I would like to load an rgba image into > Gimp and then add a mask layer.) Pre-mulitplied alpha is a data representation which contains as much or less information than the un-multiplied version. The only reason to use pre-multiplied alpha is for speed, or ease-of-use. (unless you argue that out-of-gamut values make sense). Since pre-multiplying rgba images looses information (maybe a lot) there should be very good reasons to switch the representation used to store the data. As opposed to pre-multiplying image data to speed up display. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 32-bit images in gimp - Alpha handling wrong?
Marc Lehmann wrote: > > On Wed, Jul 19, 2000 at 11:18:27PM +1000, David Hodson <[EMAIL PROTECTED]> >wrote: > > It's arguable that the information isn't there to start with. > > No: No? If I render an object, and the edge of that object only covers half of a pixel, why does it need more than half the colour range? (This is getting a little off-topic, really.) > 1. image loading and saving > 2. internal data storage > 3. composition algorithms > It seems to me that we could agree on 1. being an interface issue and 2. > being opaque to the user. OK then, if I bow to the prevailing wisdom, what it boils down to is that I could load an image file containing pre-multiplied alpha without being asked if the alpha should be un-multiplied. (Although I still think there's a useful distinction between pre-mult alpha and non-mult masks, and I would like to load an rgba image into Gimp and then add a mask layer.) A quick glance at the targa file spec reveals nothing about the intended meaning of the rgba data. -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
Re: 32-bit images in gimp - Alpha handling wrong?
On Wed, Jul 19, 2000 at 11:18:27PM +1000, David Hodson <[EMAIL PROTECTED]> wrote: > It's arguable that the information isn't there to start with. No: > A pixel with an alpha value of 0.5 will only contribute to half the > colour of the pixel, so it only needs half the colour information. Since computers cannot store real numbers, there is inevitably loss of data associated with premultiplying. It seems to me that the disucssion should really be split into three areas, as people are talking about different areas: 1. image loading and saving 2. internal data storage 3. composition algorithms It seems to me that we could agree on 1. being an interface issue and 2. being opaque to the user. So the question is not wether gimp can handle premulitplied alpha (it can ;) but wether the combination modes allow for the behaviour you want (which has nothing to do with internal presentation). I might be wrong, of course... ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 32-bit images in gimp - Alpha handling wrong?
Thanks to everyone for the responses. A few comments: Jay Cox wrote: > > David Hodson wrote: > > the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff. > > All three of whom come from a 3d rendered graphics background. As do I. > For compositing and image warping pre multiplied alpha is great. for > color correction pre-multiplied alpha just gets in the way. Agreed. I'm kind of interested in compositing and image warping, though, and I'd like to see Gimp as widely useful as it can be. When I find something that it can't do, I try to fix it, subject to the prevailing design philosophies. Nick Lamb wrote: > I'm not aware of any other common interchange format which supports the > pre-multiplied alpha representation in storage. I suspect many image formats don't actually specify how rgba data is defined, though it's not something I've looked at for a while. > No the program which produced your example PNG image is broken. That would be Gimp :-) The original image was loaded from TGA and directly saved to PNG. Since Gimp didn't know that the targa was pre-multiplied, it left it alone. "Garry R. Osgood" wrote: > > [...] How would the unerase > tool deal with full transparent premultiplied alpha [A*R = A*G= A*B = A = 0]? This comes back to the distinction I was trying to make between masks and alpha. Gimp uses (what I refer to as) masks (not alpha) to combine layers. An rgba image has nothing to unerase where alpha = 0 - the image doesn't exist there. An rgba layer in Gimp would have a separate mask channel added, and unerase would still work where the layer had been erased. > Premultiplication buys its efficiency > by removing information content from the layer. It's arguable that the information isn't there to start with. A pixel with an alpha value of 0.5 will only contribute to half the colour of the pixel, so it only needs half the colour information. -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
Re: 32-bit images in gimp - Alpha handling wrong?
Calvin Williamson wrote: > Eg He shows that if you want to downsample and then composite an image over > a background, thats different from compositing first and then downsampling > if you are using un-premultiplied images (you get different results that is). > But with pre-multiplied images you get the same answer with either order. > So it depends on how you work with your images. You might not be > using the "compositing engine" part of the paint program at all. > You might need to edit/paint the RGBs and Alpha for a layer more > or less independently. In this case Alpha=0 and Color!=0 > channels might be fine. Maybe the correct Alpha channel isnt even there > yet. Or maybe you are going to paint the alpha channel yourself. Layer trees saw some play at GimpCon (http://www.gimp.org/gimpcon) where the unidirectional layer stack differentiates into something with branches. Users could composite/paint on one branch without disturbing others - I think the metaphor to make dependency trees was made. Anyhow, branches can distinguish themselves from others by having different compositional rules. Users with compositional aims may wish to work with a pre multiplied layer branch, knowing that certain tools are just not appropriate for that milieu. Conversely users with painterly aims, who think in terms of alpha masking, would find an unmultiplied layer branch to their liking - and mask-oriented tools like unerase become readily functional. To my mind, there is no absolute "rightness" to premultiplied layers, they are "right" only when they help users achieve particular aims. If Gimp (2.0) aims at being a general paint and compositing program, then its core needs to support both approaches to using alpha, and make the distinction of different kinds of layers visible in the user interface (becoming another beast in a layer menagerie that includes Gimp classic layers, text layers, structured vector graphic layers...) Be good, be well Garry
Re: 32-bit images in gimp - Alpha handling wrong?
On Tue, Jul 18, 2000 at 09:41:49PM -0400, Garry R. Osgood wrote: > David Hodson wrote: > > > "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. > > Calvin Williamson recommended "Image Composition > Fundamentals" by Alvy Ray Smith, for a review > and advantages of the technique. > http://www.alvyray.com/Memos/default.htm. Another great reference is Blinns two chapters on Compositing in his "Dirty Pixels" book. He gives some other arguments (aside from elegance and efficiency) as to why compositing and filtering with premultiplied alphas is better. Eg He shows that if you want to downsample and then composite an image over a background, thats different from compositing first and then downsampling if you are using un-premultiplied images (you get different results that is). But with pre-multiplied images you get the same answer with either order. So aside from efficiency there are some arguments for "correctness" when doing filtering operations and compositing. But of course pre-multiplied squashes out any color information that might like to hang around in the color channels temporarily on the way to a composite. So it depends on how you work with your images. You might not be using the "compositing engine" part of the paint program at all. You might need to edit/paint the RGBs and Alpha for a layer more or less independently. In this case Alpha=0 and Color!=0 channels might be fine. Maybe the correct Alpha channel isnt even there yet. Or maybe you are going to paint the alpha channel yourself. Compositing programs tend to use premultiplied, but for painting programs un-premultiplied is pretty common. Some paint programs do use premultiplied though. Calvin
Re: 32-bit images in gimp - Alpha handling wrong?
On Tue, Jul 18, 2000 at 09:41:49PM -0400, Garry R. Osgood wrote: > David Hodson wrote: > > 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, > > It can't be done, in my opinion. What we surmise to be [R*A, G*A, > B*A, A] Gimp assumes to be [R, G, B, A] and reads the color > components as near black for near transparent regions. That makes > black fringing unavoidable. The way I got around this was to regenerate my own "Alpha" channel by re-rendering my PovRay scene in black-on-white. That is, white background with all objects solid black. If I recall correctly, it was just a matter of setting the "colour" of each object to black and rendering with a very low quality setting. (erm, or maybe I did it in white-on-black and inverted it ... in any case the same result) This process gave me a white mask (b) for the background which could then be multiplied with whatever image (i) I wanted "behind" the PovRay scene. Adding this (b*i) to the premultiplied alpha image from PovRay gave the correct visual result. Actually, come to think of it, I didn't render the high-quality scene with any alpha at all. The addition did it. Cheers, Tom -- -- Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ -- "We promise according to our hopes, and perform according to our fears." -- -- Francois, Duc de la Rochefoucauld
Re: 32-bit images in gimp - Alpha handling wrong?
David Hodson wrote: > "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. Calvin Williamson recommended "Image Composition Fundamentals" by Alvy Ray Smith, for a review and advantages of the technique. http://www.alvyray.com/Memos/default.htm. > At the moment, as far as I can tell, the Gimp cannot handle > pre-multiplied rgba images. Yes. In fact, in generating the projection images (app/paint_func.c) Gimp pretty much does the "unmultiplied case" in the above cite, including the "second composition" step to recover an unmultiplied layer from a premultiplied intermediary result. From the premultiplied viewpoint, that's a lot of unnecesary multiply and divides. > 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, It can't be done, in my opinion. What we surmise to be [R*A, G*A, B*A, A] Gimp assumes to be [R, G, B, A] and reads the color components as near black for near transparent regions. That makes black fringing unavoidable. > 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.) If all we had to care about was an efficient pipeline, premultiplied is the way to go - but there's more to Gimp than its rendering pipeline. There are tools that are relatively simple to code with unmultiplied layers, but are difficult or impossible to do with premultiplied ones. How would the unerase tool deal with full transparent premultiplied alpha [A*R = A*G= A*B = A = 0]? Look for some back door on an undo stack? Premultiplication buys its efficiency by removing information content from the layer. The performance arguments advanced by Smith are compelling, and his pipeline is computationally cleaner, but the last time I did any serious performance measurement on the pipeline was a low-teens Gimp, and compositing to the projection was not a big comsumer compared to building buffered writes to the X server (this was, I recall, not built with threads enabled). My two U. S. cents Garry Osgood
Re: 32-bit images in gimp - Alpha handling wrong?
On Tue, Jul 18, 2000 at 10:39:26PM +0100, I wrote: > No the program which produced your example PNG image is broken. > The PNG specification requires straight RGBA, pre-multiplied alpha is > prohibited and this is spelled out several times. Gimp can't hope to > interpret an invalid image correctly. On further examination it looks to me as though the test image on your web page is in fact a _picture_ of an image file which you feel didn't load correctly. If I'm right, please provide the _original_ file, if you can't see the difference never mind, I assure you I know what I'm doing. If in fact that image file is the original image file, my previous recommendation remains, we must alert png-implement about this broken software or process immediately. Since you mentioned PovRay I looked at their code, I found it to be a tangled mess, but didn't see anything strikingly wrong with it. I would be most suprised if the PNG on your web page was produced by that code though. Nick.
Re: 32-bit images in gimp - Alpha handling wrong?
On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson wrote: > > Can you justify that (all images should be pre-multiplied)? > > Or is this just your unsupported opinion? > > Well, that was attempted editorial humour to some extent, but it's also > the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff. > I'd hardly call it unsupported. Ah, but as others have said, these are people working in a totally different area, and at least Tom Duff is most famous for a speed-up hack easily as ugly as pre-multiplied alpha (Duff's device). > > Gimp has no support for pre-multiplied alpha, > > Well, there's my answer. No support. ... and no need for it. With the exception of (IMHO useless) out-of-gamut RGB values, each is equally expressive, plug-ins and tools are free to convert to pre-mult if appropriate but the core uses ordinary RGBA. > A hack? I thought it was a mathematically elegant representation of > an image layer, which is why I see a reason to support it. I'm trying > to find out if anyone else agrees, or if I'm missing something that's > already there, or there's something specific about Gimp and the way > it's used that makes it unnecessary or not useful. Let's rather say "Not a priority" rather than "not useful", but I do not expect pre-mult alpha to be exposed to the user (as opposed to used in plug-ins or for speed-up hacks) in Gimp any time soon. > And even if you consider it a hack, don't people use pre-mult alpha? > Am I the first one to notice this and complain? Notice? I don't know. Complain, yes. You'll see why in a minute I think. > I have no love at all for the TIFF format. (I was present at the birth > of a similarly over-extended format. I should have complained more loudly.) > But that's irrelevant - or at least orthogonal - to the use of pre-mult > alpha. I'm not aware of any other common interchange format which supports the pre-multiplied alpha representation in storage. If we didn't have to load or save it, pre-mult would not be a problem for Gimp. > I've placed a page at: > > www.ozemail.com.au/~hodsond/alpha.html > > Images are just inline PNGs, just grab 'em as they appear; but it's not > really necessary, if you say that Gimp doesn't handle pre-mult alpha, > then that explains the results. No the program which produced your example PNG image is broken. The PNG specification requires straight RGBA, pre-multiplied alpha is prohibited and this is spelled out several times. Gimp can't hope to interpret an invalid image correctly. Please identify the program (name, version, vendor etc.) and I will pass the details on to png-implement. Hopefully we can arrange for them to issue an urgent update to their users and if necessary get publicity so that everyone knows not to use this broken program. > Do users have problems with pre- and non-mult alpha? Since they are equivalent I'd guess users remain comfortably unaware. Nick.
Re: 32-bit images in gimp - Alpha handling wrong?
>It depends on what you are doing weather pre multiplied alpha is useful >or not. For compositing and image warping pre multiplied alpha is great. for >color correction pre-multiplied alpha just gets in the way. Since >pre-multiplying the alpha does throw away a few bits of information my >preference is for non-pre-multiplied alpha. I know 3D software that outputs pre or non-pre, user selectable, but read only pre. The manual says all that, and recommends non-pre for "drawing programs". What I do not understand, is why I would like pre for compositing? If I have an image with pre, when I composite with another image, I will get damaged borders, instead of true composition based in the alpha, no? If software knows it, it can be fixed... but after lossing precission, no? GSR
Re: 32-bit images in gimp - Alpha handling wrong?
David Hodson wrote: > > Nick Lamb wrote: > > > > On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote: > > > 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. > > > > OK, but please provide some concrete examples... > > > > 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.) > > > > Can you justify that (all images should be pre-multiplied)? > > Or is this just your unsupported opinion? > > Well, that was attempted editorial humour to some extent, but it's also > the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff. > I'd hardly call it unsupported. All three of whom come from a 3d rendered graphics background. In the photo manipulation/retouching realm it is very uncommon (and inconvenient) to have a pre-multiplied alpha channel. > > > At the moment, as far as I can tell, the Gimp cannot handle > > > pre-multiplied rgba images. > > > > Gimp has no support for pre-multiplied alpha, > > Well, there's my answer. No support. It really shouldn't matter to the end user weather we use pre-multiplied alpha internally or not as long as we do the proper conversions on load/save (and of course do the image manipulation properly WRT. alpha) > > and I don't see any reason > > to change this because it's just a hack. > > A hack? I thought it was a mathematically elegant representation of > an image layer, which is why I see a reason to support it. I'm trying > to find out if anyone else agrees, or if I'm missing something that's > already there, or there's something specific about Gimp and the way > it's used that makes it unnecessary or not useful. It depends on what you are doing weather pre multiplied alpha is useful or not. For compositing and image warping pre multiplied alpha is great. for color correction pre-multiplied alpha just gets in the way. Since pre-multiplying the alpha does throw away a few bits of information my preference is for non-pre-multiplied alpha. > And even if you consider it a hack, don't people use pre-mult alpha? > Am I the first one to notice this and complain? I do quite a lot of graphics work and almost never use images stored with pre multiplied alpha. I think it is quite likely that gimp 2.0 will have some support internally for pre multiplied images if only for optimization reasons. Jay Cox [EMAIL PROTECTED]
Re: 32-bit images in gimp - Alpha handling wrong?
On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson <[EMAIL PROTECTED]> wrote: > A hack? I thought it was a mathematically elegant representation of > an image layer, which is why I see a reason to support it. I'm trying AFAICS premultiplied alpha is a speed hakc and nothing more, for cases where sacrificing precision for speed makes sense. > And even if you consider it a hack, don't people use pre-mult alpha? Gimp tries to convert pre-multiplied alpha back to normal alpha, as Nick said, so it is supported (or should be). This really sounds like a load (and maybe save) issue (most image formats do not support pre-multiplied alpha). Can you state any reason why premultiplied alpha should be directly supported as data representation? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: 32-bit images in gimp - Alpha handling wrong?
Nick Lamb wrote: > > On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote: > > 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. > > OK, but please provide some concrete examples... > > 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.) > > Can you justify that (all images should be pre-multiplied)? > Or is this just your unsupported opinion? Well, that was attempted editorial humour to some extent, but it's also the opinion of (for example) Jim Blinn, and Thomas Porter and Tom Duff. I'd hardly call it unsupported. > > At the moment, as far as I can tell, the Gimp cannot handle > > pre-multiplied rgba images. > > Gimp has no support for pre-multiplied alpha, Well, there's my answer. No support. > and I don't see any reason > to change this because it's just a hack. A hack? I thought it was a mathematically elegant representation of an image layer, which is why I see a reason to support it. I'm trying to find out if anyone else agrees, or if I'm missing something that's already there, or there's something specific about Gimp and the way it's used that makes it unnecessary or not useful. And even if you consider it a hack, don't people use pre-mult alpha? Am I the first one to notice this and complain? > The Gimp TIFF loader tries its > best to convert pre-multiplied alpha images, but loading TIFFs is an > unending struggle. The format should be put out of its misery ASAP (but > see all previous Gimp discussions on TIFF for reasons why it stills > stalks the earth). I have no love at all for the TIFF format. (I was present at the birth of a similarly over-extended format. I should have complained more loudly.) But that's irrelevant - or at least orthogonal - to the use of pre-mult alpha. > [...] Maybe you could send me some sample images off-list and I > will look at them. I've placed a page at: www.ozemail.com.au/~hodsond/alpha.html Images are just inline PNGs, just grab 'em as they appear; but it's not really necessary, if you say that Gimp doesn't handle pre-mult alpha, then that explains the results. > > At the same time, much of the code for handling alpha data seems to > > unscale and rescale the colour channels. [...] OK, just had a look at the transform code and realised what it does - the "unscale and scale" is actually converting the non-premultiplied alpha to pre-multiplied alpha to do the transform! Hmmm... Do users have problems with pre- and non-mult alpha? -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
Re: 32-bit images in gimp - Alpha handling wrong?
On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote: > 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. OK, but please provide some concrete examples... > (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.) Can you justify that (all images should be pre-multiplied)? Or is this just your unsupported opinion? > 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.) Gimp has no support for pre-multiplied alpha, and I don't see any reason to change this because it's just a hack. The Gimp TIFF loader tries its best to convert pre-multiplied alpha images, but loading TIFFs is an unending struggle. The format should be put out of its misery ASAP (but see all previous Gimp discussions on TIFF for reasons why it stills stalks the earth). > 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.) If I use an image with real alpha data it works. For your Povray image? Who knows. Maybe you could send me some sample images off-list and I will look at them. Povray may be broken, the file output for your chosen format in Povray may be broken, Gimp's file loader may be broken, and finally most unlikely you may have a broken Gimp version. For best results, as always, send me a test image (or two) and another image in a well-understood format like JPEG which shows approximately what's intended, as well as any text description. > 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. Haven't looked at this, perhaps someone who owns the transforms can comment. Nick.
Re: 32-bit images in gimp - Alpha handling wrong?
"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
