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 specific plug-in instead of
adding unreasonable requirements to the GIMP core. The plug-in
could expose the reflection channel (A) as a separate layer. In
the same vein, POV-Ray abuses the TGA format for storing 16-bits
POV height fields by combining the 8 bits from the green channel
and the 8 bits from the red channel to create a 16-bits
grayscale channel. I think that the conversion to and from this
special TGA format should be handled by a specific plug-in and
not by the paint core, just like it should be done for the
special PNG images used by Tribes2.
