Raphaël Quinet (quinet@xxxxxxxxxx) wrote:
> Here is a long overdue and long-winded update to the discussion about
> editing the alpha channel and how transparent pixels should be
> handled...
Let me respond to this. I don't think, that your proposal is
as urgent as you make it and I seriously believe that it has a
fatal flaw.
> 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.
I fail to see why this is such a fundamental difference.
> 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.
As you wrote: "However, if". While a undo brush certainly would be
a nice thing to have, it certainly does not cover the same area as
an anti-erase mode.
> 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:
[...]
> So the concept "alpha = hiding" does not work for case (2).
So you basically claim that our uncertainity of what happens to the
data outside the GIMP makes it impossible for us to work with that
data inside the GIMP.
This is nonsense. We always had the general approach to empower the GIMP
user to do non-obvious stuff. Right now we don't discard RGB-information
when A=0 in the core, and stuff like Anti-Erase usually just works good
for power users. The new Alpha-to-mask feature you are complaining about
in #127930 works and empowers users to handle Tribes2 textures.
The point that you perceive this as an abuse of the PNG format is
irrelevant: PNG does not discard the RGB information by itself, and
there is no point in preventing our users to use it.
> 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).
Right, we need to think about it, when we actually implement that fancy
compression stuff. I'd love to know if layers really shrink
automatically in Photoshop. When we implement this I certainly would
let the user decide, if he wants automatic shrinking or not.
> 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).
I strongly disagree here. Just because we cannot rely on external tools
to handle the RGB information for A=0 in a consistent manner, that does
not mean that we should prevent the usage of that information.
The user has to select the tools he want to use. And it is his
responsibility to select his toolchain to handle that case in the way he
wants to get it handled. Gimp should not artificially limit the way the
user wants to interact with invisible information.
> 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.
Undo Brush can only work if there actually *is* an undo history. Since
Gimp might get used together with external tools this is not always the
case, making it necessary to have other ways to reveal potentially
important information (for pixels where A was =0).
> This is is why I was suggesting to remove the bug introduced by
> #127930 before it makes it into a stable release,
Let me emphasize this:
THIS IS NOT A BUG!
A bug is not defined as "might lead to unexpected results when used in a
very specific manner".
> 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.
As mentioned above the scope of these two tools is not the same.
> 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).
This would severily impact the scope of the GIMP, since it would prevent
its use in cases where the user knows exactly what the alpha channel is.
> 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.
This is when you assume "normal" composition mode. For other modes your
argument breaks apart into pieces.
> 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.
Since there is no such plugin and I somehow don't see you jumping up and
implementing it and right now the GIMP core can handle that case just
fine I don't see why we should restrict the user in that kind of
operation.
To summarize:
Raphaël outlined where the treatment of A=0 pixels could lead to
problems in the future (automatic layer shrinking), but I believe
that these problems could be solved by exposing the policy to the user.
The Gimp core right now allows us to store RGB information in pixels
where A=0 and retrieve them later. This is useful in some cases and thus
must not be called a bug. In my opinion we should not limit the scope of
the GIMP by imposing artificial restricitions on the User.
And please note that I'll go berzerk when I am no longer able to make
A=0 pixels more opaque via the curves dialog.
Bye,
Simon
--
Simon.Budig@xxxxxxxxxxx http://www.home.unix-ag.org/simon/
