GNOME Bugzilla – Bug 411599
RGB information removed from transparent pixels when merging layers
Last modified: 2008-01-15 13:24:56 UTC
Pixels fully transparent in the alpha channel will have their RGB data destroyed when saved to non-XCF image formats with alpha support. There are times when this is a sensible compression method, and there are times when this is harmful, such as when the alpha channel isn't going to be interpreted as transparency. It doesn't seem to matter how I apply the transparency: the Eraser tool, Clear command and layer masks all result in the colour data being discarded. A third-party plug-in that allows me to save in the DDS format doesn't have this issue, and I note that while the Save As dialogue for TIFF has a "Save colour values from transparent pixels" checkbox, it doesn't work. Pixels with at least 1% alpha have their colour data preserved, so there is a workaround of sorts for this that stops me marking it as a major. But it's really fiddly having to avoid total transparency all the time, and perhaps for someone out there 1% won't be an option? There should be a global option to decide whether or not RGB data is preserved for transparent pixels when saving to alpha-enabled formats.
Aha! This bug is actually related to the merging of layers (which is why DDS wasn't affected: it supports layers). ***When an image is flattened, RGB data is removed from fully-transparent pixels.*** It doesn't matter whether the other layer(s) are enabled or not, or what's in them. If there is more than one in the image, you'll hit this bug.
A flattened image doesn't have any transparent pixels. Your bug report doesn't make sense. Save plug-ins are a different issue. We support this toggle in the PNG plug-in. Other plug-ins might be enhanced to also show this behavior but this doesn't count as a bug. Feel free to submit a patch for your favorite save plug-in.
The toggle in the PNG plug-in doesn't work in a layered image because of this bug. Try it. The fact that this issue isn't with the flattening process means that it's with the export process, not that it doesn't exist. There needs to be a way to save a multi-layer image to a single-layer format without destroying this RGB data. Perhaps the export process should only _merge_ the layers? That's actually what it says in the Export File dialogue, if you look: "Merge Visible Layers", not "Flatten Image".
Fully transparent pixels are supposed to be fully transparent. They are not supposed to still have some color information associated with them and GIMP does not promise that it will preserve it. It happens to work for some operations and not for others, but GIMP is allowed to discard the color channels of fully transparent pixels at any time. It just happens to preserve the colors now for some operations, but this is not a promise and it is even likely to change (and discard colors) in future version of GIMP. In summary, what you are attempting to do is not something that GIMP has to support, so this is not a bug.
Created attachment 83260 [details] Image with transparency
Created attachment 83261 [details] Original image exported from a multi-layer image. Try to anti erase within the blank square
If you don't want to support this, that's your choice and I'll use another app. But as I said in the first comment, there ARE situations where this behaviour is harmful. Feel free to delete the attachments I made. You commented while I was uploading.
Currently, merging multiple completely-transparent pixels gives a resulting pixel colour of black (albeit still completely transparent) - a useful alternative would be to use the lowermost layer's colour. I've had an idea for a lowest-colour-preserving layer-merge script-fu thingy which does just this, however - which I'll have a go at writing in a little while. I've already run through the stages manually, and it works just fine. Fully transparent pixels may well be fully transparent, but it's nice not to invent new colour values for them. Textures for modern 3D graphics do all sorts of horrendous things with the alpha channel, only some of which actually involve transparency.
Adding comments this closed bug report is not very useful because it is unlikely that any developer will look at it. If you really want to discuss these issues, please join the gimp-developer mailing list (http://www.gimp.org/mail_lists.html). However, these issues have been discussed before so I doubt that anything significant would change soon. The color values of transparent pixels is simply undefined (they are multiplied by alpha=0) so there is no reason for GIMP to preserve these values, especially when preserving them would prevent some optimizations (runtime optimizations reducing CPU or memory usage, or file size optimizations).
Raphaël, you keep saying this as soon as the issue comes up :) And I disagree, and apparently so do others. We don't live in the world of premultimplied alpha here...
I should perhaps add that in this case we don't have much choice but to do this.
Mitch: As you certainly know, there are several places in the code that take some shortcuts if alpha=0. There is no need to do expensive operations on the color channels if the results will not be visible anyway. Also, even if this is not a major issue, the case of merging two layers that are transparent in the same area brings a dilema: which "invisible colors" should be preserved, and how do you justify that decision? Should GIMP keep the RGB values from the top layer (as if that layer was opaque) or the RGB values from the bottom layer (as if the top layer was transparent and the bottom layer opaque)? I am not arguing that GIMP should discard these values for the sake of discarding them. I am arguing that GIMP should not promise to preserve them. Of course they will be preserved in many operations, but not all of them. Requesting to change GIMP so that it always preserves the RGB values of transparent pixels is an idea that I am opposed to, because it would prevent some of the current optimizations and would also prevent some future enhancements such as automatically growing/shrinking layers or layers without visible boundaries, avoiding the storage of fully empty tiles, etc.
"There is no need to do expensive operations on the color channels if the results will not be visible anyway." The point of this bug report is that there are situations where the results _are_ visible; where alpha is not interpreted as transparency. "Should GIMP keep the RGB values from the top layer (as if that layer was opaque) or the RGB values from the bottom layer (as if the top layer was transparent and the bottom layer opaque)?" It should merge values from all visible layers. "Requesting to change GIMP so that it always preserves the RGB values of transparent pixels" It need only be an option.
(In reply to comment #13) > "There is no need to do expensive operations on the color channels if the > results will not be visible anyway." > > The point of this bug report is that there are situations where the results > _are_ visible; where alpha is not interpreted as transparency. In GIMP, alpha _is_ interpreted as transparency (or opacity). If you use some file formats for which alpha has a different meaning in some other application, then that's fine as long as you keep in mind that alpha==opacity as far as GIMP is concerned. In other words, GIMP makes no promise that the RGB values of fully transparent pixels will be preserved. They may be preserved in some cases and may be optimized away in other cases. We just cannot make promises. There are cases in which it would cost too much to make sure that the invisible contents of fully transparent pixels are preserved. Besides, there are cases in which the semantics are not clear at all, such as merging two or more transparent layers. > "Should GIMP keep the RGB values from the top layer (as if that layer was > opaque) or the RGB values from the bottom layer (as if the top layer was > transparent and the bottom layer opaque)?" > > It should merge values from all visible layers. Merge how? Imagine that you have 3 layers A, B, C that happen to be all transparent in the same area. I will assume that you ignore the fact that they are fully transparent (in which case RGB=0, as in the current GIMP) and insist on preserving some invisible RGB values from these layers. Depending on how you interpret the layer compositing rules and how you imagine that their opacities are converging towards 0, then you have equally good reasons to think that the final RGB values of the result should be equal to the top layer, equal to the bottom layer, or equal to some arbitrary combination of the three layers (including, but not limited to 1/3 of each). So if (a, b, c) are the relative weights associated with the colors of the layers A, B, C and if you do not want to accept that (a, b, c) = (0, 0, 0), then picking (1, 0, 0) or (0, 0, 1) or (1/3, 1/3, 1/3) are all equally good (or bad) choices. You could even pick (0, 1, 0) just for fun and keep the middle layer only: after all, the other two layers are transparent so why not pick the middle one? > "Requesting to change GIMP so that it always preserves the RGB values of > transparent pixels" > > It need only be an option. Adding such an option would not only introduce regressions when it is active, but it would also make the code more complex and harder to maintain. We would also need to take arbitrary decisions in cases such as the one described above, unless we make them configurable as well (and make the code even more complex). Anyway, if you insist that such an option should be added, feel free to submit a patch that implements it. However, keep in mind that such a patch is very likely to be ignored because it would make the code less maintainable and because it does not support any of the use cases that GIMP is designed for.
We should add a note about this to the developer FAQ and point to the relevant discussion on the mailing-list. Then we don't need to waste time with such bug reports.