RaphaŽl Quinet <[EMAIL PROTECTED]> 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

>  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

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
Gimp-developer mailing list

Reply via email to