GNOME Bugzilla – Bug 72852
Incorrect RGBA resampling in randomize (Hurl/Pick/Slur) plug-in
Last modified: 2005-01-01 21:56:06 UTC
If two pixels have different opacity values (alpha channel), then their colors are not averaged correctly by the randomize plug-in (implementing the options Noise->Hurl, Noise->Pick and Noise->Slur). 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.
I'm afraid the alpha channel bugreport template is wrong here. Situation is worse, the algorithm doesn't make any sense in terms of pixels, only in terms of individual channels. The channels are averaged independently, with some probability. I don't know what is the correct handling of Alpha when (eg.) Red components are averaged, but Green and Blue are kept intact. Should it be averaged? Kept? Averaged with weights 2/3 and 1/3? And why? Currenly the plug-in takes Alpha just as any other channel (ie. it' averaged with some probability), with obvious consequences.
I tend to agree with David that we should close this one as NOTABUG.
I don't think that we should simply close it. One option would be to disable this plug-in for all images that have an alpha channel, because the way the alpha channel is handled can give unexpected results. Another option would be change the plug-in so that it converts the image to pre-multiplied alpha, then applies its algorithm to the RGB channels only (not alpha) and then converts the image back to post-multiplied alpha. The result would be that the alpha channel would never be affected, and the RGB values of the fully transparent pixels would make the image darker but would not produce values that should never be seen. See the following attachment for an example of the unexpected results. I applied the Slur filter on the test2 image provided in bug #70335. The only way to explain the results shown on the right side of the screenshot is to know the internal representation of the RGBA images and to know that the fully transparent pixels can have arbitrary RGB values. This is not something that should be expected from most users.
Created attachment 14607 [details] test2-results.png (36 KB) - screenshot of filter applied to test2 image
Raphaël, or whoever with the politically correct view of RGBA space, please answer the question I raised in the first comment. I accept `whatever it would do if Alpha was premultiplied' as an answer, but: since the plug-in idea makes no sense in premultiplied Alpha and no one wants the plug-in to randomly darken the image instead of real noisification, I'll make it accept only RGB and Gray (no Alpha) images in this case.
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.
Hurl actually has no problem. For Pick and Slur, the real problem is that they shouldn't handle different channels independently, it isn't what they were intended to do and makes them almost useless for practical purposes, because for anything except an opaque grayscale layer they create anomalous colors. I made some changes in the code to make Pick and Slur operate by pixel rather than by channel. Hopefully it will be enough to resolve this bug. Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/randomize.c: Changed algorithm for Pick and Slur to treat all channels within a pixel in the same way; intended to fix bug #72852.
Let's close this as FIXED then.