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 > transparent). 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 implementation. 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. greetings, Ernst Lippe _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
