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
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
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
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