RaphaŽl Quinet <[EMAIL PROTECTED]> wrote:

>> You consider that in certain circumstances this behaviour could
>> be considered a bug.
>
>Yes, because presenting undefined data to the user should be avoided.

I mostly agree with you, but there are reasons for me wanting the feature
implemented as the result of bug #127930. Here's my point of view of the
situation.

Conceptually, I agree that alpha = 0 means that the RGB value of the pixel
is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone.
Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding
pixel is inexistent, as we already agree (I think).

However both alpha and mask accomplish the same goal, i.e.
opacity/transparency of individual pixels. Personally, the first time I saw
it I found confusing and irritating to have two different elements for the
same functionality.

Being the things as they currently are, the problem that I see is that you
can use alpha to do things that you can't do with mask, and vice versa. 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. As
they are currently implemented, the only way to be able to get the
advantages of both is to implement some mechanism for converting one into
the other and vice versa. There was already one direction, accomplished with
"Apply Mask". The only missing one was the reverse, which is what bug
#127930 addresses.

Now that I can convert from one to another and the other way around, I can
take full advantage of both. I'm aware that this operation might expose
undefined data, and I agree that there's some problem with that. Indeed I
proposed an alternative implementation of #127930 in an earlier message that
you haven't commented on, though now I doubt it's even useful. My current
idea is rather to try to solve it by defining the guidelines for zero-alpha
pixel handling as was mentioned earlier in this thread. In my previous
message I suggested to specify them as undefined, but maybe it's not a good
idea after all as you seem to defend.

I tried PS to see how it handles Alpha. I became quite frustrated. Once I
deleted a part of the image and saved and reloaded it, I found *no* way of
increasing the opacity of partially transparent pixels, not to mention
totally transparent ones, except by painting. All adjustment tools had RGB
but no A. Maybe it's just that I'm missing something because I'm not
experienced with it but now I think that PS is not my kind of program.

But I have sometimes found myself needing to do alpha editing. Here's an
example. I drew a closed figure in a layer and as an approximation I put a
grayscale copy of it as a mask then I applied the mask (i.e. converted it to
alpha) to continue work on it. I went on drawing; when working on the
background I suddenly realized that there were small spots within the figure
that were partially transparent and I wanted them fully opaque. The figure
was complex; if I used the anti-erase I could neglect to opacize the whole
figure. My alpha-to-mask script became very handy in that situation. With
the threshold preview I could identify the spots that were not fully opaque
and remove them.

As a final note, I've run into the same request from Gimp users for such a
mechanism as the one implemented in Bug #127930 several times already.

  Pedro Gimeno
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to