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.
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to