Hi, RaphaÃl Quinet <quinet@xxxxxxxxxx> writes: > One thing that has not been mentioned in this discussion so far is > that there are two kinds of transparent pixels Transparent pixels are transparent pixels. There are no two kinds of transparent pixels; that would be a strange concept to introduce. > 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. > - 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. If such a background color is specified, transparent pixels should be filled with this color. Otherwise black seems like a good choice, but see below. > - 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. > - 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. > 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. > 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). 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? Sven
