On Tue, 11 Mar 2003 17:12:14 +0100
RaphaŽl Quinet <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Mar 2003 09:46:49 +0000
> > "Adam D. Moss" <[EMAIL PROTECTED]> 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.
Why? Normally operations on the alpha don't influence the state
of the other color components, so I don't really see why it
would be reasonable to assume that changing to full transparency
is a priori different.
Also it is the simplest way to implement the whole thing.
> 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).
The point was that fiddling with the boundaries as a final step after you
have made other modifications to the layer looks like a pretty normal scenario
to me. In your proposal it is safe to make the area smaller, but there
is no way to make it bigger or use a slightly different feathering.
The only way to undo a wrong initial decission is to undo all subsequent
edit steps. I am very certain that I would not be too happy about having
to start all over again.
> You seem to imply that
> the user would use the "anti-erase" option as a normal feature.
Why not? It is very easy to give good semantics for this 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
But how do you handle the case when a user would try to make a transparent
pixel non-transparent. This pixel should then get a color, but which
one? White and black are possible choices, and in most cases the user
will want neither of them. Perhaps every operation that potentially
could change a transparent pixel should have an additional argument
that specifies the color for those pixels?
> 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).
In general unspecified behavior is not a nice thing to have
(I am almost tempted to write EVIL). In most cases where a system
has unspecified behavior the user makes assumptions on how it
works and is unpleasantly surprised when in a few cases the system,
for unknown reasons, behaves very differently.
I think that we both have reasons to be unsatisfied with the current
The main point for me is that the current implementation
leads to irreproducible behaviour.
When it is desirable to remove all color information from transparent
pixels the right place to implement this is in the operation that modifies
the alpha and not somewhere hidden in the tile caching.
Gimp-developer mailing list