GNOME Bugzilla – Bug 343047
Gaussian blur introduces gray/black artifacts when used on a layer with alpha.
Last modified: 2008-01-15 13:08:17 UTC
Please describe the problem: Gaussian blur when used on certain images will produce a black halo around certain things. Steps to reproduce: 1. Create a white circle on a transparent layer. 2. Apply the blur or gaussian blur filter. 3. You can see that there is a blackish gray additive to the edges of the circle. You can test this by looking at the histogram. since it's white it should be only to the right side of the histogram, but there are more colors in the histogram than just white. Actual results: you get a gaussian blur with gray or black added to it. Expected results: it should just blur it, and not add any black to it. I wonder if it's adding black to every image? mabey it's only noticable on a transparent image. or mabey it only happens on transparencies. Does this happen every time? yes. Other information: You can work around this problem by adjusting the levels to only output white.
What versions of GIMP are you seeing this problem with? Have you tried the development version? Looks a lot like a duplicate of bug #70335 and friends.
The version i am using comes with the latest ubuntu. version 2.2.11 Sorry in advance if this one's already fixed.
The symptoms you describe are bug #72849 but that's supposed to be fixed.
This problem is in my opinion unfixable. The Gaussian blur plugin uses an algorithm that is very fast but does not allow for variations in transparency. It does the best it can, by pre-multiplying the transparency channel before blurring -- but the best is not perfect, and the scenario you have set up is exactly the one that shows the imperfection in the worst possible way. We have discussed this question before, and the conclusion has always been that the benefit of making the plug-in do exactly the right thing does not compensate for the cost of making it take up to 100 times as long to run in common situations. There is, however, something else going on here. In my experiments into replicating this, I have found that not just the edges, but even the *center* of the circle are somewhat darkened. This indicates an error in normalization, which it would be nice to fix. It is pretty subtle though, and would hardly be noticed in most situations. Attaching example below.
Created attachment 66474 [details] example image XCF file with two layers. The top one is the result of IIR-Gaussian blur with radius 10, applied to a solid white circle on a transparent background. The bottom layer is solid white, for contrast. Note that the interior of the circle has been darkened slightly.
Created attachment 69367 [details] Example image 2
I think this problem has gotten a lot worse over the last couple of stable releases - previously the "halo" was very small and almost invisible - now its a big fat black line Check out my attachment - its a simple white square layer, gaussblur'ed by 17*17 and with a green background-layer - and it looks horrible! I realize, from the above posts, that its pretty mcuh meant to do this, however i think, if the "damage" to the image is this bad, there should be a "quality blur" option which doesnt do this - i would wait every time.
Setting version accoring to comment #2.
*** Bug 349452 has been marked as a duplicate of this bug. ***
I had the same problems using ubuntu. > The version i am using comes with the latest ubuntu. version 2.2.11 You can solve this problem easily, because the older versions did their job very well. You can copy the old gaussian plugin files to the plugin-directory of Gimp. (Ubuntu uses /usr/lib/gimp/2.0/plug-ins) After you restartet Gimp, they will be added to the menu automatically - and do again their job even with transparency. I added these files as attachment.
Created attachment 71232 [details] [review] correctly working gaussian blur plugin files Copy the containing files to /usr/lib/gimp/2.0/plug-ins (IF YOU USE UBUNTU) Look for the GIMP PLUGIN DIRECTORY if you use another distribution.
(In reply to comment #4) Why do the older versions work, while the newer ones don't? If you made the algorithm better, there must be some mistake. But maybe it's actually faster. Please look at the example files: The result CAN BE NOTICED definitely! I use this function very often together with transparency. As there is well working source code, why don't take it for the newer versions?
I think that there should be two gaussians - one old and a new - thats certainly how im gonna try and setup my gimp now...thanks for the old files btw :D
Timo, thanks for helping, but since attaching a binary file is at best a very short-term solution, perhaps you would be so good as to tell us where you got the source code for it, or where you got it from?) Note, by the way, that in a legalistic sense you are actually violating the GPL by distributing a binary file in this way without making the source code for it available. The main reason for asking, though, is that if we can compare the source code of the current version with the version you've attached, it may help us figure out what the problem is.
The only change to the gauss plug-in that we did during the 2.2 release cycle is the fix for bug #331051. Could this be related? Timo, when you claim that the old plug-in worked better, what version are you refering to?
I'm sorry because I haven't provided the source code as well. The files are extracted from an RPM Package, made for SuSE 9.2. The Gimp-Version is 2.0.6, but I read somewhere, that the 2.2.10 files should work as well (but was not able to find them and try.) This old version doesn't have a preview-window, so you have to guess well the radius - or must use CRTL-Z. That's a pity, but, most important, it works.
Thanks for the info. Looking over the cvs log, it seems likely to me that the problem appeared either in version 1.32 or 1.31 of gauss.c. Version 1.32 appeared with the following ChangeLog message: 2006-02-18 Sven Neumann <sven@gimp.org> * plug-ins/common/gauss.c: applied patch from Stephane Chauveau. Code cleanup and major performance improvements (bug #331569). And version 1.31 with this: 2006-02-14 Sven Neumann <sven@gimp.org> * plug-ins/common/gauss.c (gauss): apply multiply_alpha() on the source buffer, not the destination (bug #331051, spotted by Stephane Chauveau). Note that both of these changes were also backported to the stable branch. Version 2.2.11, which has the problem, was released after they were made; version 2.2.10, which is apparently okay, was released before them. Since Stephane is perhaps in the best position to figure this out, I will add a comment to bug #331051 asking if he is still around and able to take a look at it.
Only the change from bug #331051 was backported to the stable branch.
The gauss plug-in from the development version doesn't have the problem, but I have been able to reproduce it with the one from the stable branch. After reverting the backported fix, the problem is gone. The change should probably never have been backported to gimp-2.2. I have reverted the plug-in back to the state of the 2.2.10 release: 2006-08-22 Sven Neumann <sven@gimp.org> * plug-ins/common/gauss.c: reverted change from bug #331051 that shouldn't have been backported to the stable branch.
I just added a comment to bug #331051. The backport was incomplete. By the way, I do not think that reverting the backport in 2.2.13 really fixed anything since the backport was only applied to the horizontal pass and the shadow problem is clearly vertical. I also do not believe that the problem was worsening in the last releases. That is more a matter of having transparent pixels of the rigth color (ie. transparent black versus transparent white).
Reverting the backport did definitely remove the artefacts shown in comment #5. Stephane, if you think that you have a better fix, please attach a patch against 2.2.13 or CVS branch gimp-2-2.
*** Bug 360898 has been marked as a duplicate of this bug. ***