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.


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 D. Moss   . ,,^^   [EMAIL PROTECTED]   co:3
busting makes me feel good
kthx bye

Gimp-developer mailing list

Reply via email to