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 <hodsond@xxxxxxx>. 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" mismatching among their tools. We should also mention this issue in new and improved Gimp documentation (I should check this...). Future Gimps should also accommodate pre-multiplied images, and this is being included for the Gimp 2.0 discussed at GimpCon; it is not a feature that will easily retrofit to 1.x Gimps, unless some few people become tremendously brave (but not during the freeze, pleeze). Thank you for asking! Be good, be well Garry
