(Sorry for yet another long mail. I will try to be more concise in
my other replies, by not repeating the points already stated here.)
On 09 Dec 2003 20:32:25 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:
> RaphaŽl Quinet <[EMAIL PROTECTED]> writes:
> > 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.
> There is no such thing as undefined RGB data. GIMP doesn't use
> premultiplied data, so the data is always there and I don't think you
> can argue that it would be undefined.
Well, of course there is always some data there. The value of every
pixel is always set by the GIMP or by the plug-in that loads the file
or obtains the data from an external source. My point was that the
RGB data is undefined *from the user's point of view*. Or to put it
in another way, the value of the RGB data for some of the transparent
pixels (mainly those that were made transparent outside the GIMP) is
arbitrary and could change if:
- some internal implementation details of the GIMP (or GEGL) change,
- some internal implementation details of the plug-in change,
- the file is saved and re-loaded (the load and save plug-ins could
- the file is processed by some other software,
- the RAM or CPU is exposed to cosmic rays or alpha radiation. ;-)
> > - 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.
> The RGB data can hardly be discarded, it can only be replaced with
> other data.
I agree. I know that the pixels will not suddenly disappear, but what
happens to the RGB data is an arbitrary decision. Most of the
standards for image formats do not require the RGB data of fully
transparent pixels to be preserved when saving the image, and what we
and other software authors do with it is an implementation detail. In
most cases (not all cases, I agree), the user will not and should not
know what happens to these pixels.
If we consider the example of RGBA PNG files mentioned above, the PNG
specification says: "The alpha channel can be regarded either as a
mask that temporarily hides transparent parts of the image, or as a
means for constructing a non-rectangular image." If the image matches
the first case, then we should preserve the RGB data. If the image
matches the second case better, then the PNG specification recommends:
"fully transparent pixels should all be assigned the same color value
for best compression." Of course, the best match (first or second
case) depends on the history of the image (how it was acquired and
edited) and the intent of the user. So the best solution for PNG
could be to add an option in the save plug-in allowing the user to
select if the RGB data of transparent pixels should be cleared or not.
But this is just a guideline (not a requirement) for the PNG file
format and we can choose to follow it or not. The plug-ins for other
file formats or the other programs manipulating PNG images could
arbitrarily clear or preserve the RGB data of transparent pixels.
> > - 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.
> We should probably set up a policy on how plug-ins should implement
> this then. The policy could say that transparent pixels should be left
> untouched (leaving it up to libgimp to initialize them) or
> alternatively be initialized to 0.
Yes, this is a good idea. However, this is just something that we
would choose to do now and we could select a different policy in the
future if that could bring other advantages. Setting the color to
black is probably a good choice, but I don't think that the user has
to be aware of this.
> > 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).
> This is indeed an interesting point. Basically the only advantage that
> I could find in your concept so far but indeed a compelling one.
Thanks. Note that even if this could be important in the future, I
did not want to insist too much on the implementation details such as
how to allow layers to grow/shrink dynamically. I am more concerned
about the perception that users have of the alpha channel: is it right
for the users to think that the alpha channel can always be considered
as a simple hiding mechanism? As I tried to show above, this can be
wrong so it would be safer to support a different point of view:
transparent pixels are gone but can be rescued via the undo stack (if
they were cleared within the GIMP).
> I don't see why you want to limit GIMP in this way. It is an image
> manipulation program. Manipulation IMO includes being able to reveal
> the content of transparent areas. The information is there; why
> shouldn't the user be able to use it?
I don't want to limit the GIMP, because the same results can easily be
obtained in a slightly different way while still giving us the freedom
to change the internal implementation in the future. Also, I wouldn't
mind if some way to edit the alpha channel directly was still
available, as long as it would be among the advanced/weird/potentially
dangerous/hackers' features. It should not be the preferred way to
alter the transparency of an image, and especially not for rescuing
pixels that have been erased by accident.
This is a matter of perception. Being able to edit the alpha channel
directly and exposing the internal data associated with transparent
pixels is fine in a hacker's tool, but it does not really fit in a
program that can rival with other professional image editors. The
GIMP is a bit of both, of course. That's why it is nice to have some
semi-hidden features that can allow the advanced users who are not
afraid of looking under the hood to perform some operations that would
confuse the average user. But I would like to avoid having these
special features among the "normal" features, especially if the mere
presence of these features would create or reinforce a perception that
is incorrect (or not always correct).
Gimp-developer mailing list