There's been some controversial discussion in bug #127930
<http://bugzilla.gnome.org/show_bug.cgi?id=127930>. RaphaŽl proposes a
discussion in this mailing list if we're not convinced about it. Well, I'm
not.

I couldn't agree more that the content of totally transparent pixels is
undefined. However I hardly see how "reviving" fully transparent pixels
could confuse users. The manual should just state clearly in big bold
letters that the RGB value of a fully transparent pixel is undefined, and so
one can expect anything arising from the exposition of previously
transparent areas. This approach was even taken by the PNG specification,
which specifies to maintain the full RGB data even for pixels with zero
alpha value (there's even an entry in the Rationale section aimed to explain
the reasons). The manual could also mention that in the current version the
RGB value in fully transparent pixels is kept intact with whatever was there
before assuming that it was initialized, that if it is not initialized at
all then the pixel could contain anything, that some filters could silently
alter the RGB data of the pixel, and that this behaviour could change in
future versions.

The proposal given by RaphaŽl in bug #128118
<http://bugzilla.gnome.org/show_bug.cgi?id=128118> does not allow the
possibility of increasing the opacity, so it's not valid as a way to edit
the alpha channel, which was the intention in bug #127930. The only solution
that I could perhaps admit discussing is the same applied in bug #127930 but
instead of just setting all the pixels in the alpha channel to alpha 255, do
the equivalent of applying the "threshold alpha" filter with a value of
zero, i.e. keep zeros as zeros and set all the nonzero values to 255, which
sounds more in accordance with RaphaŽl's ideas.

There's another problem that RaphaŽl mentions in bug #127930:

>There are other problems related to the consistency of the user
>interface: in the menu for creating the mask, the new option to
>"transfer" the alpha channel is the only one that has a side effect
>and this is not obvious to the user.  Putting this option in a
>separate group may solve this problem, but in any case I don't like
>the fact that it mixes different concepts.

I agree with him here; leaving this option just as it is results confusing
because that option is the only one which modifies the alpha channel.

My initial proposal aimed at solving this issue by using a different wording
for the options, but it was rejected: to use "Copy Alpha to Mask" (or "Copy
from Alpha channel") instead of the previous "Layer's Alpha Channel", and
call the new one "Move Alpha to Mask" (or "Move from Alpha channel"). The
rationale was that the strong opposition between the words Copy and Move,
the only word that changes between the two sentences, would make it evident
that the latter could have destructive side effects. OTOH most users are
familiar with the fact that if they *move* a file from A to B and then
delete it from B, they lose the file. This was also mentioned by RaphaŽl as
a drawback (what if the user discards the mask?, he argued), but I don't see
a problem here.

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

Reply via email to