Raphaël Quinet <quinet@xxxxxxxxxx> wrote: >But as you mention a "proposed change", I will just repeat that this >discussion started because of a change that was introduced during the >feature freeze and that is (IMHO) controversial and goes against the >model that we should try to promote. That's a point where we diverge. I've found some users telling me that sometimes they use Photoshop, sometimes Gimp, depending on what they're intending to do. That's because both do things in different ways. If we try to just clone Photoshop's features, we'll be always one step before it. I think that offering the feature in bug #127930 doesn't break anything to the user. > I was hoping that more >developers would see that the rest of the world around us (e.g., >Photoshop) does things in the right way That's not the right way in my opinion. If I want to make a certain shape look sharper in Photoshop, I can't use a tool like the central slider in the Levels tool in Gimp. Are you sure that that is the "correct" behavior? > and that we should not >introduce new features that have not be thought out carefully and that >break this model The model was already broken before the addition. Anti-erase, Curves, Levels and the plug-in-threshold-alpha with -1 arg hack can all be used to resurrect totally and partially invisible pixels. >Interestingly, the only new arguments (from Pedro, about Photoshop) >are actually supporting what I wrote, even if Pedro does not like it. That was not "the only new argument"; read my message again because it seems that you overlooked some. My new arguments were: - Photoshop does it (that's supporting your argument, provided that "others do it" means supporting your argument). - There are things that can be done only by using alpha and things that can be done only by using layer masks (more on this later), and a means of conversion between them is desirable so that one can take advantage of both and not be limited by what can be done with the flavour he's using. - I have found practical situations where I needed to edit the alpha channel, and the way that Photoshop does things wouldn't have helped me. I even gave an actual example. - Other users have asked me for such a feature as the one implemented in bug #127930, so there's a real need for it in the users' side. >> I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice >> addition/work around the optimization problem - I have yet to try it >> out, though. > >I haven't tried it either, but it could indeed be a nice addition to >the PNG plug-in. And what about the TGA and the TIFF and the <insert-your-favourite-format-with-alpha-here> formats? Isn't it better to solve the issue in a more general way, so that the user doesn't get confused if such-and-such load plug-in doesn't include the option to load the alpha as a mask? > But alas this is far from solving the real problem, >which is a problem of model/perception. The real problem is that some >GIMP developers and users see alpha as a simple hiding mechanism, >which is wrong (or not always right, depending on your point of view). As Mask and Alpha are quite different things, are you saying that the Apply Mask option should be removed? Or the Create Mask as a Copy of Alpha option? Why should they exist in the first instance, if they're so different and so unrelated? (and why does PS have them?) >As this will be my last message in this thread, I would like to end it >with a question (but I suggest that you do not respond - just think >about it): Why do we need layer masks in the GIMP? Wouldn't it be >easier to paint directly into the alpha channel and simply get rid of >this intermediate step (mask)? Quoting myself (as you seem to have missed it): "I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons." > Why were masks introduced in the first >place? mmm... because Photoshop had them? }:-) Seriously though, I agree that they're conceptually different and for this reason they don't behave in the same way. This leads to what I already said: there are things that can be done only by using alpha and things that can be done only by using the layer mask. Which, in turn, leads to the need for some mechanism to convert one into the other and vice versa, addressed by bug #127930. I'll just mention some of the things that come to my mind that can be done with Alpha but not with a layer mask: - Use the Eraser as a quick way to hide pixels. With Mask, you have to select the mask, change to the Brush tool, change the current FG color (which you probably were using for other purposes), change the current brush (which you probably were using for other purposes), ensure that the brush options are suitable for the erase operation (or lose your previous settings which you probably were using for other purposes), then paint. - Apply filters that behave consistently to their weighted R,G,B. The filters in the Distorts section come immediately to mind, but of course many filters are affected by the same reasoning. I've even found a filter (Curve Bend) that silently applies the mask before processing and keeps it applied even if cancelled. I consider that a bug, and I'm taking note of it for reporting it later, but it gives a clue on what the user (or the plug-in author in this case) would want masks to do but don't. For the vice versa (things that can be done with a layer mask that can't be done with alpha), the best example is just to use paint tools on it. My usual workflow is to always use alpha because it does what I need, except when I need to make some adjustments by hand. I used my alpha-to-mask script for that task before; now I don't have to. I have yet to see a reasoned argument against this one, which is the one that led me to developing the partial patch for #127930, even knowing that it might lead to exposing undefined data just as Levels, Curves and Anti-erase can do so far. The problem with our positions seems to be a "you should not" vs "there's no reason why you can't if you need to", applied to exposing conceptually undefined data. Note that the user does not necessarily expose it when he's focusing on what he's wanting to modify (it didn't happen to me when I did the modifications that I wanted in the example I gave). It can happen accidentally but I don't think that's an issue, given the gains obtained. Plus, undefined data can be actually defined data, given proper specifications and plug-in behaviour. > That's why one is not >encouraged to edit the alpha channel directly (there are ways around >that if you know how to do it). If PS has a way around that (I was unable to find it), why can't gimp have it too? >I hope that it is not too late to correct the mistakes made in the GIMP. It's never too late *if* they are mistakes. Currently you and Adam seem to be the only ones in the thread who think so. Pedro Gimeno
