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. sigh 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?
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 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?
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?
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. sigh 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?
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 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?
"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
