GNOME Bugzilla – Bug 72864
Incorrect RGBA resampling in Emboss plug-in
Last modified: 2005-03-25 19:38:05 UTC
If two pixels have different opacity values (alpha channel), then their colors are not averaged correctly by the Distorts->Emboss plug-in. The preview window ignores the alpha channel completely, so the transparent pixels are shown as if they were opaque. It looks like the RGB channels are resampled without taking the opacity into account. As a result, the (invisible) color of a transparent pixel can bleed into an opaque pixel. The resulting image is incorrect. See bug #70335 for some test images and a longer description of the problem. This problem affects many other tools and plug-ins.
The emboss algorithm doesn't average pixels. It computes *differences* between pixel values (more or less). I don't know how to take alpha into account and not get negative alpha or even worse nonsense. And I think nobody knows. But I'd be glad to see a proof of the opposite. Imagine following situation: a completely white image, only with alpha changing from 0 on its left egde to 255 on its right edge. What should be the result? The same image, only perhaps in a different shade of gray? This is how it works now, so the answer is probably no? Or a horizontal transparent-black-to-opaque-white gradient? But why, when the value doesn't change at all. Or something else? IMHO this plugin should not accept drawables with alpha channel at all.
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
Bumping the milestone for this bug, and all that depend on it, to 2.2. In the absence of someone actively working on this, there is no point keeping it on the 2.0 milestone. If someone wants to work on this, fixes to this family would also be accepted on the stable branch. Dave.
To use Dave's famous words: In the absence of someone actively working on this, there is no point keeping it on the 2.2 milestone.
This plug-in now uses a GimpDrawablePreview, so the preview aspect can be removed from the bug title.
I am unable to detect any bleeding of colors from transparent pixels in this plugin. (It does show edge-darkening in some circumstances, but as pointed out in comment #1, that's not necessarily wrong.) I propose closing as INVALID unless somebody can come up with an example of the problem. (I haven't found any changes to the algorithm in ChangeLogs more recent than the bug report, so FIXED would not be appropriate.) Meanwhile setting to NEEDINFO.
(I'm using stable Gimp, but I suppose it makes no difference here.) There are two modes: Bumpmap and Emboss. Try attachment #6776 [details] with both. Bumpmap clearly creates some red and green pixels from nothing. If it doesn't do this in CVS Gimp, then *something* must have changed which fixed it (and Gimp version matters then, and the rest of this comment is to be ignored). Emboss is grayscale. So bleeding is not so evident, but the result is weird. Anyway, information from transparent pixels was used in both cases, because it computed value differences between opaque and transparent pixels and got different results for (opaque_white, transparent_red) and (opaque_white, transparent_green) pixel pairs. As I said in comment #1, it can be fixed (by definition) once a consensus is reached how operation `subtract pixel values' should be defined for pixels of various opacities. Or it can stop accepting layers with alpha if consensus is reached the operation doesn't make any sense at all.
For additional fun, try attachment #6802 [details] with both modes. Like the other attachment, this is a *.xcf.gz file.
The amusing effect for attachment #6802 [details] turns out to have been caused by an off-by-one-row error in the code. I have fixed this, and also changed the code to use premultiplied alpha when computing the normals, so that the colors of transparent pixels can't affect the result. Also, looking at the code revealed that in RGB images, the embossing was only affected by the red channel -- I changed it to be controlled by the value. Seems to do the right thing with the attached example images now. The changes are complex enough that other bugs may pop up as a result, but hopefully this one can be considered fixed now. For cvs HEAD: 2005-03-25 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/emboss.c: fix usage of RGBA data, change to premultiplied alpha for embossing, hopefully fixes bug #72864.