On Sun, Sep 17, 2000 at 02:34:08PM +0200, Mattias Engdegård replied to
> >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
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.
> 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
> 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 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]