Re: [Gimp-developer] caching considerations in gegl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe <ernstl@xxxxxxxxx> wrote:
> On Tue, 11 Mar 2003 09:46:49 +0000
> "Adam D. Moss" <adam@xxxxxxxx> wrote:
> I think that the user should be able to edit the alpha channel independent
> from the other channels. I don't think that it is unreasonable that a user
> initially makes some parts of the layer transparent, then makes some other
> edits to the layer and finally decides that the transparency boundaries
> should be slightly different, e.g. slightly more feathered. In most cases
> this will work fine but when some of the tiles have been scrubbed this
> will not work for these tiles. 

I think that it _is_ unreasonable to expect this to work.  If the user
wants to change the transparency boundaries, then the correct way to
do it would be to undo the steps that have shrunk the visible area
(and then it does not matter if the transparent tiles used in the
following steps have been scrubbed or not).  You seem to imply that
the user would use the "anti-erase" option as a normal feature.  I
always considered the "anti-erase" feature to be evil.

Ideally, the average user should see no difference if we suddenly
decided that the GIMP should work with pre-multiplied alpha (in which
all color information is definitely lost when making a pixel
transparent).  So I think that we should not suggest that the alpha
channel is like any other channel.  Making a pixel fully transparent
should be considered as a destructive operation for the corresponding
RGB data (or let's say that the behavior is unspecified, which is a
good description of what happens now).

-Raphaël

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux