Here is a long overdue and long-winded update to the discussion about
editing the alpha channel and how transparent pixels should be
handled...
One thing that has not been mentioned in this discussion so far is
that there are two kinds of transparent pixels: those that have been
made transparent during the current GIMP editing session, and those
that were already transparent when the file was loaded from disk or
obtained from a plug-in.
1) For the pixels that have been made transparent during the current
editing session, one point of view could be to consider the alpha
channel as a hiding mechanism that does not modify the RGB data.
However, if the goal is to be able to un-erase some pixels that
were accidentally made transparent, then an undo brush would be a
more appropriate solution to that problem. So the concept of
hiding without destroying is not really necessary if the same
data can be retrieved from the undo history with the same
convenience.
2) For the pixels that have been obtained from an external source,
then the hiding concept does not fit because the RGB data is
undefined. For the files loaded from disk, the RGB values of
transparent pixels depend on the file format, on the programs that
have previously processed the file, on the current implementation
of the plug-in, etc. There are several cases:
- Some indexed formats (e.g., GIF) associate a default color with
the transparent areas to be used by programs that are not able to
handle transparency correctly. Note that nothing requires a GIMP
plug-in to store this color in the image, because the GIMP
supports transparency.
- Some other formats (e.g., RGBA PNG) store full RGBA data, so the
transparent pixels may contain some RGB values. However, these
values may be discarded by other image processing software or by
tools such as pngcrunch. A GIMP plug-in could also discard the
color of transparent pixels while loading or saving an image in
order to improve the compression.
- In some other formats (e.g., WAD textures), the transparent
pixels are simply not stored: they are defined as a number of
pixels to skip in the current row or column, so there is not even
a concept of default color for these pixels. In this case, the
RGB values depend only on internal implementation details of the
plug-in used to load the file.
So the concept alpha = hiding does not work for case (2). In
addition, even case (1) has some problems because sticking to that
model would prevent the GIMP or GEGL from optimizing the memory usage
by clearing and freeing tiles that are fully transparent (this would
be useful if we want to implement layers that grow and shrink on
demand, as requested in bug #93639 and bug #98776).
It is better to consider the transparent pixels to have undefined RGB
values and to make sure that these RGB values are never exposed to the
user (that would be a bug). Other well-known programs have solved the
problem of un-erasing pixels by introducing an undo brush. I would
like the GIMP to reach or exceed the quality of these professional
programs by making sure that the features are implemented in the right
way instead of introducing new bugs.
This is is why I was suggesting to remove the bug introduced by
#127930 before it makes it into a stable release, and instead
implement what I suggested in bug #128118. Beyond the next release,
this is also why we should consider removing the anti-erase mode of
the eraser tool in a future release and replace it by an undo brush.
This would improve the quality of the GIMP and make sure that the
users do not consider the alpha channel to be something that it cannot
be (not always, at least).
-Raphaël
P.S.: I would also like to add that this discussion applies also to
the pixels that are partially transparent, not only those with
alpha=0. For a pixel with alpha=1, the only thing that matters
for the R, G and B values is whether they are greater or lower
than 128 because the result after composition would be the same.
A program could decide to replace any value between 0 and 127 by
another value in the same range if that would improve the
compression of the image. Same for alpha=2, alpha=3, and so
on... So we could consider the RGB values to be defined only to
the extent that they make a difference after composition, which
means that the undefined color range for a pixel is the full
range when alpha=0 and gets smaller as alpha increases.
P.P.S.: In a comment added to bug #127930, Guillermo S. Romero
mentions that some games such as Tribes2 use RGBA PNGs and store
some information in the A channel that is not alpha (reflection
effect), so it would be useful to be able to edit alpha
directly. However, I disagree because this kind of abuse of the
file format should be supported by a
