Re: gradients and pre-multiplied alpha
On Mon, Sep 18, 2000 at 05:24:20PM -0400, "Garry R. Osgood" [EMAIL PROTECTED] wrote: Gimp should do premultiplied alpha. Not because it cures acne or extends human life expectancy by an astounding 3000 precent, but be helpful to that crowd if the dear little creature would only eat pre-multiplied alpha and composite with it. One must realise, however, that this only gives a speed improvement (possibly), and that the visual result is identical (except for rounding errors, which are only problematic in premultiplied alpha). Everything that currently results in visible artefacts with non-preemultiplied alpha will do the same with pre-multiplied alpha, and would need to be fixed anyway (or is a misconception of the user). a slot for an alpha premultiplied flag. And premultiplied pixels are otherwise indistinguishable from unmultiplied ones. So it is doubtful to me that any paint program any time soon can automagically determine One could argue that a file format that has no way of specifying wether alpha is premultiplied or not is hardwired to one alternative - if people use it in a wrong way (like in the png case) they have incorrect files. For files that *are* commonly used in both types and cannot distinguish between them (e.g. raw bytes!) a switch might be helpful. This, however, is a just an import issue. Gimp happily reads indexed images with 500 colours, but of course cnanot store them in that way. In this dicussion, we should draw an exact line between import/export issues (where premultiplied alpha is a file format feature, and incorrect handling would be a bug somewhere) and using pre-multiplied alpha for the internal representatioin (which is *just* a speed hack, if implemented in a fast way ;). If Gimp would create different results (modulo rounding errors) when working in pre-multiplied space this would be a bug. a clear statement that Gimp is an unmultiplied compositor (though certain tools and plug-ins necessarily have to internally play the premultiplied game - blur comes to mind) and (c) If you care about While this might be interesting from a technical perspectibve, since both compositors must result in the same image, this is not really a priority. The only thing one could mention is that gimp's result will be more correct with unmultiplied alpha. Perhaps a later Gimp will know how to consume premultiplied alpha (you'll have to throw some switches) the 1.x Gimps of the next two years or so won't know how to do it. But it is probably just a single line in the file load/save functions, so it should be easy to implement. If you mean that gimp should have another set of compositing modes, very much like the dissolve mode which does a kind of "incorrect" alpha composing (namely dithering) but adds a useful visual effect, then this might be a worthhwhile addition. However, changing gimp's behaviour in RGB mode depending on file format features is like saying: well, format xy saves pixels in the wrong order, so you have to turn your monitor 180", as gimp is a top-down-compositor. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: gradients and pre-multiplied alpha
On Thu, Sep 21, 2000 at 03:44:51PM +0200, Marc Lehmann wrote: On Mon, Sep 18, 2000 at 05:24:20PM -0400, "Garry R. Osgood" [EMAIL PROTECTED] wrote: a clear statement that Gimp is an unmultiplied compositor (though certain tools and plug-ins necessarily have to internally play the premultiplied game - blur comes to mind) and (c) If you care about While this might be interesting from a technical perspectibve, since both compositors must result in the same image, In Gary's defense, I am not yet convinced this is true. Plug-ins do not have access to GIMP's rendering pipeline, really (except the selection mask is handled for them), so they implement compositing functions in any way they choose. However, for functions such as the blend tool, there's a strong pressure to use the existing gimp_image pipeline. Now I am a plug-in guy, and thus not at all familiar with the paint core, but in my preliminary investigation I found no clean way for the blend tool to do premultiplied compositing. I await with much anticipation to see how Federico gets it done. -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Re: gradients and pre-multiplied alpha
On Thu, Sep 21, 2000 at 02:51:28PM -0700, Kevin Turner [EMAIL PROTECTED] wrote: While this might be interesting from a technical perspectibve, since both compositors must result in the same image, In Gary's defense, I am not yet convinced this is true. Premultiplied alpha is a _representation_ of a colour (including alpha). Just like you can represent colour using 8 or 16 bits per channel, or RGB and CMYK. Some representations are equivalent, most aren't. premultiplied alpha is equivalent to RGBA, _except_ that it's spatial resolution is lower. So, if both types of compositing result in different images then they are simply two different algorithms to do compositing. both ways can work with both representations, it just happens to be that the current compositing modes do not include them (just as there are no effect layers). I fail to see what the internal representation has to do with that. Now, if somebody came and claimed that fkat RGBA compositing modes make no sense for premultiplied RGBA comp. modes and vice versa, he'd have a point, but... core, but in my preliminary investigation I found no clean way for the blend tool to do premultiplied compositing. Since you can always convert between the two representations, it "just" has to convert flat RGBA to premultiplied RGBA. RGBA is all you need. IF your algorithm works better in premultiplied RGBA, then just convert. Usually you can reformulate the algorithm to work in RGBA, preserving the resolution. (The only exception I can see is layer/channel compositing, but as I mentioned, if there are two different common ways to compose layers then you can do both using both representations, and gimp could easily support both at the same time). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: gradients and pre-multiplied alpha
Nick Lamb [EMAIL PROTECTED] writes: Probably some UI improvements needed in the gradient editor then, other packages I've seen use a separate edit bar for alpha. I would not advocate such a change to Gimp, but it is at least inspiration. The gradient editor's user interface sucks harder than a realdoll plugged to a pneumatic pile driver set on reverse. Whoever wrote it should be put in a mental institution. Oh, wait. That would be me. Anyways, it is due for a rewrite. The code sucks. It was my first GTK+ application :-) I would be very happy to take suggestions for a better user interface. And yes, the blend tool should do the right thing with alpha values, i.e. premultiply them before compositing them in. I'll submit a patch for it in the afternoon. Federico
Re: gradients and pre-multiplied alpha
Federico Mena Quintero wrote: And yes, the blend tool should do the right thing with alpha values, i.e. premultiply them before compositing them in. I'll submit a patch for it in the afternoon. rant_and_rave I don't think this episode uncovered an alpha-related bug, so what needs to be fixed? Mr. Turner's example (unwittingly, perhaps) specified two different gradients (in the unmultiplied color space). And two different results were obtained. What went wrong? *Should* the gradient tool work in the premultiplied space, while GIMP mostly functions in the unmultiplied one? Won't this give users different alpha characteristics in different places? Won't they be better served with a consistent alpha channel behavior of the unmultiplied space in *most* places? Especially since - for better or worse - the rendering pipeline functions with unmultiplied alpha only? The gaussean blur HAS to pull premultiplied tricks. No surprises there either, for just as Mr. Lamb observed with premultiplied alpha, the unmultiplied space is no cure for the blues either. They happen to be two (mutually exclusive) conventions that can be applied to the alpha channel, and one has a Real Slick compositing algorithm associated with it, blessed by the Computer Graphics Gurus. In light of this, then, I think we should be very careful in preserving a consistent behavior when it come to how the alpha channel behaves, and warn users when inconsistencies (invariably) arise. /rant_and_rave Be good, be well. Garry
Re: gradients and pre-multiplied alpha
On Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb [EMAIL PROTECTED] wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. If at all, it will only create even more visual artifacts due to greatly reduced colour resolution for nearly-transparent pixels. The point of not using premultiplied alpha is freedom to change and edit your images, similar to providing 12, 16 or more bits per colour component. Using 8 bits (or using premulitplied alpha) is simply a performance issue, NOTHING else. (Sorry, Nick, when I just re-iterated your point, but I had to provide a strong "me too" ;-) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: gradients and pre-multiplied alpha
On Mon, Sep 18, 2000 at 05:24:20PM -0400, Garry R. Osgood wrote: Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Perhaps a later Gimp will know how to consume premultiplied alpha (you'll have to throw some switches) the 1.x Gimps of the next two years or so won't know how to do it. This is exactly what I was worried about -- Gimp already DOES convert premultiplied alpha from the one source I'm sure uses it, TIFF. It is trivial (though perhaps sometimes costly) to convert TIFFs during loading so we (almost) always do. Support _internally_ in Gimp (which you're proposing for 2.0) is orthogonal to loading external data correctly. If someone finds me an MS internal document dictating that BMP uses pre-multiplied alpha I'll add the conversion functions in days -- to the BMP loader. For undisciplined formats a load-time option is not a sensible way to go, we'll probably have to provide a plug-in which does the conversion and include help that explains what it's for / how to use it to handle either case, some heuristics in the plug-in can help. I'm not willing to write such a plug-in not only because I'm already too busy, but because I think the film/ rendering communities brought this on themselves. I've seen too much evidence that says they don't care about standards, or interoperability. Nick.
Re: gradients and pre-multiplied alpha
Hi, Kevin Turner wrote: Should the blend tool use premultiplied alpha for custom gradients? Make a custom gradient that is white on one end and transparent on the other. (Go on, use the RGBA 0, 0, 0, 0 option provided on the menu.) Very well. As a consequence of this, of course, the midpoint of my gradient is R = G = B = 127, for I am asking the gradient editor to ramp on all four channels from 255 = 0. My midpoint, therefore, is a neutral gray that is half transparent. Now use it with the blend tool on a white canvas. The result is a gray band. No surprises there. In comparison, with the foreground set to white, use the blend tool's "FG to Transparent" on a white canvas. Isn't that better? "better" always is a function of how well results matches intent. I have no idea how people generally intend to use Gimp or what their overall expectations are, so I won't even venture an opionion. But I do know that "FG to Transparent" does what it advertises. It leaves the R G B to whatever those values have been set to, then ramp A from 255 = 0, for if were to alter R, G, or B (the FG components) in any way whatsoever, it would be changing "FG" to something else, in violation of what the user interface legend says. So the two examples actually ask Gimp to blend with two different kinds of gradient; I am not surprised that two different results are obtained. So, I'd call the lack of premultiplied alpha for custom gradients a bug. But I seem to recall a recent debate about when it was and wasn't appropriate for gimp to use premultiplied alpha, so I figured I'd ask first. What was thought to be a bug, I surmise, is actually arising out of two different operations that were misconstrued to be the same. To make them actually the same, one would set the gradient editor to blend from [255, 255, 255, 255] = [255, 255, 255, 0]. The gradient doesn't offer the target as a preset, as Mattias Engdegård observed, but one can set the example by hand. There also seems to be a little vagueness here about what premultiplied alpha means. A premultiplied alpha pixel represents points in color space as [R*A, G*A, B*A, A]. It is a representation convention that happens to ease the task of compositing images (see references below). As a consequence of this representation, the first three components of a premultiplied alpha pixel cannot be any larger than the fourth. (also, fully transparent pixels necessarily look like [0, 0, 0, 0]). The current Gimp rendering pipeline is of the unmultiplied type, and it's pretty well hard wired. That is, the RGBA paint functions assume unmultiplied sources, be they TempBufs that tools make or upper layers, they composite a local foreground/background image pair to get a premultiplied intermediary, then divide out the alpha to prepare for the next pairwise composite one step downstack, until they've flattened all layer imagery onto the projection (see references, cited below, for the math). It is at this juncture that premultiplied alpha compositors take the lead in the race: they aren't constantly converting from the premultiplied to the unmultiplied world. All composition is premultiplied composition. Given that Gimp has an unmultiplied rendering pipeline, all facilities at the very top of the image chain must feed it unmultiplied sources, otherwise an image "type mismatch" arises, leading to upsetting results. This issue was given voice last July by David Hodson [EMAIL PROTECTED]. He observed that many image generators in the film and 3D animation industry, particularly 3D modeling tools, all premultiply alpha when making images. (See Alvy Ray Smith's "Image Composition Fundamentals", http://www.alvyray.com/Memos/default.htm. See also Jim Blinn's "Dirty Pixels", Ch 16, 17, and 20, and Ron Brinkmann's caveats in "The Art and Science of Digital Compositing" page 74-75.) Smith and Blinn both illustrate that compositing images with premultiplied alpha pixel data involves less multiplication, is mathematically more elegant, and requires less code. Since compositing digital imagery is a massive chore in the film imagery, it comes to no surprise that their compositing tools and paint boxes are familiar with premultiplied image data and can be asked to accomodate them. Wilber is naive about premultiplied alpha. Feed him a premultiplied image and he just thinks it has some very nearly transparent pixels very near the black point. Gimp uses the alpha channel rather more as a mask; he interprets the alpha component simply as a scale factor by which to make the R, G, and B components more or less invisible (but he leaves R, G, and B magnitudes otherwise unchaged). Given the difference in interpretation, there is a good deal of black fringing visible in premultiplied images that have been fed to Gimp. As Brinkmann points out, users of image tools have to be aware of the distinction between the two uses of one alpha channel and be aware of the possibility of "image type"
Re: gradients and pre-multiplied alpha
On Sun, Sep 17, 2000 at 02:34:08PM +0200, Mattias Engdegård replied to me, saying: Make a custom gradient that is white on one end and transparent on the other. (Go on, use the RGBA 0, 0, 0, 0 option provided on the menu.) This could be remedied by allowing the gradient editor to use alpha=0 with colours other than black. I have sometimes been forced to edit gradient files manually for this. Heavens, there's no need to edit the gradient file manually. You can easily use the colorselector the gradient editor supplies to set the RGB values independant of the alpha value, to make RGBA 1.0, 1.0, 1.0, 0. However, you have to first recognize the necessity of doing this. So you can call it an education issue, if you like. One that's easy to get confused about, since all fully-transparent "colours" *look* the same, and so "why can't I just use the transparent color from the pop-up menu?" Then on Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Well, yes, that was my intention, actually. The basis for my thinking comes from something Raph sent me when I asked when it is and is not desirable for plug-ins to work in premultiplied alpha space. From http://plugins.gimp.org/doc/Writing/html/appendix-alpha.html: The reason why it's interesting is that linear combinations of pixels (i.e. a1p1 + a2p2) work better in premultiplied alpha space than in separate alpha space. (Compositing a gradient over the image with the blend tool is one such linear combination.) For example, taking the 50/50 blend of white and transparent works like this: White is (1, 1, 1, 1) and transparent is (0, 0, 0, 0) in both spaces. So the 50/50 blend is (0.5, 0.5, 0.5, 0.5). In separated space, that's half-transparent gray, but in premultiplied space, that's half-transparent white, which is what you expect. [...] The symptom of getting alpha wrong is gray fringes when you work with transparent layers. You'll notice that plug-ins such as gaussian blur do do this, because while you *might* expect someone to be aware "what color transparent" they're using when constructing a gradient with a handful of points, you certainly do not expect them to know "what color transparent" surrounds their subject in the image they're blurring. You *cannot* expect them to get this right, really, because their subject is most likely different colors on different edges, and getting the "right color of transparent" set on each edge would be a trying and senseless task. So if it's not reasonable to expect people to know "what color transparent" when creating a gradient on their canvas with the blur tool (or filter), I don't feel they should have to worry about it when creating a gradient on their canvas with the blend tool either. It is most definately not only "a performace hack" here, because GIMP's internal representation is *not* in premultiplied alpha form (and I am not advocating that it should be), so you have to convert in and out of this space when applying your filter. Alas, spending cycles on such conversions does not boost performance ;) but it may reduce time spent in zen-like pondering on the color of clear. Am I making sense yet? - Kevin -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Re: gradients and pre-multiplied alpha
Heavens, there's no need to edit the gradient file manually. You can easily use the colorselector the gradient editor supplies to set the RGB values independant of the alpha value, to make RGBA 1.0, 1.0, 1.0, 0. This is embarrassing, I had actually not found that colour editor before. Thank you. (Perhaps it shows the value of keeping data in plain text files, for the clueless but determined user.)
Re: gradients and pre-multiplied alpha
On Sun, Sep 17, 2000 at 02:12:22PM -0700, Kevin Turner wrote: Then on Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Well, yes, that was my intention, actually. The basis for my thinking comes from something Raph sent me when I asked when it is and is not desirable for plug-ins to work in premultiplied alpha space. Kevin, that's a reply to Garry that you're quoting, in a message about file level pre-multiplied alpha, and possible architectural changes in Gimp 2.0. Not particularly relevant to your present concern. Nick.
