Nick Lamb wrote:
On Tue, Mar 11, 2003 at 04:38:13PM +0100, Ernst Lippe wrote:
I think that the user should be able to edit the alpha channel independent
from the other channels.
Agreed.
Then don't be shy of layer masks, they're a lot more flexible
than operating directly on the pixels' alpha data. The meaning
of a pixel's colour is tied very closely to its alpha (ie. the
relationship, precision aside, is such that you can use any pair
of the RGB, the alpha, and the weighted result to derive the third),
and a colour becomes undefined when it loses all weight. This is
the *RGBA PIXEL*'s alpha, a property of the pixel, not an arbitrary
value that we carry around in the same word as the RGB data simply for
purposes of rendering convenience. If a pixel is RGBA it's as fair
to say that its RGB values become undefined when its A hits 0 as it
is to say that an HSV pixel's H becomes undefined when its V hits 0.
If there is a bug then it is in the remaining tools and plugins that
1) Use the RGB value of an utterly transparent RGBA (or indeed GREYA)
pixel (try to tell me that this is a desirable feature in the
blur plugins, for example), or
2) Try to allow a user to resurrect the colour of an utterly
RGBA transparent pixel (e.g. anti-erase AKA the 'should have
used a layer mask in the first place, or how do you see what
you're interactively unerasing until you've unerased it?' tool).
If you want to tweak a layer's alpha values forever without the risk
of sending the RGB part of RGBA pixel data to la-la land, use a
holy layer mask and/or the undo tool!
If you want an auxilliary per-pixel channel that doesn't have
fixed semantics tied to a pixel's RGB values at all, use an
auxilliary channel.
--Adam
--
Adam D. Moss . ,,^^ adam@xxxxxxxx http://www.foxbox.org/ co:3
busting makes me feel good
kthx bye
