(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 <sven@xxxxxxxx> wrote: > Raphaël Quinet <quinet@xxxxxxxxxx> 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 be different), - 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). -Raphaël
