GNOME Bugzilla – Bug 434279
Blur tool seeps colors from the edges
Last modified: 2007-05-06 03:34:13 UTC
(from the mailing list) When blurring with the blur tool, colours involved in the blur (that is, are under the brush) seep from the edges of the image, regardless how close these colours are to the edge. This is not dependant on the colours and does not happen with any of the blur plugins (even when repeated over time). It is likely to be linked with the way the blur code handles pixels outside the image (that is, pixels that don't exist). If it decided to treat these pixels as the average of all the colours under the brush, then that would produce these exact symptoms.
Created attachment 87219 [details] A perfect example
Created attachment 87220 [details] It was just a blue square before blurring in the circle.
It seems that mirroring has been chosen as default (only) border extrapolation. This is clearly unsuitable for this kind of graphic. There is also a notable offset in the opposing axis, ie the reflected data is shifted to one side as well.
Actually if you look closely you'll find the blurring region (the circle) does not touch where the blue rectangle's "reflections" would be and hence the blue rectangle's reflections would not be included in the blur. Is there any internal documentation regarding how the algorithm actually handle's borders? Another characteristic of this bug is that, in this example, the less blue there is in the blurring region the less blue seeps in from the edges.
This depends on the brush - the dotted line specifies the 50% gray level of the brush, so it very well might extend into the "mirrored" source area.
The brush used in this example has 100% hardness, meaning 100% opacity right to the edge, hence all pixels under the brush blur at a constant rate. And even with 0% hardness the dotted line represents 0% opacity, not 50% like the marching ants of a selection.
"meaning 100% opacity right to the edge, hence all pixels under the brush blur at a constant rate." -- it doesn't mean that; there are partially-covered pixels at the edge, and these will blur at a lesser rate. Hardness is roughly a control of the power of a brush blurring filter, which operates on a mask that is already antialiased. In my own work and my observations of others' work, it seems that blur is rarely used for tile-type graphics; Hence an 'extend' type seems like the most useful default (border pixels are used when samples beyond the border of the image are wanted.) "even with 0% hardness the dotted line represents 0% opacity, not 50% like the marching ants of a selection." Not that I've ever observed; It's always been 50%, evidenced by the fact that drawing a single dab can produce effects obviously beyond the outline. What version of GIMP are you using?
Can you show us an example of the blur tool blurring outside the brush outline? I compiled my version from SVN ~5 days ago (2.3.17).
Could you please discuss things on the mailing-list and use the bug-tracker to keep record of the facts. Thanks.
I cannot reproduce the problem and I checked the code and what gg claims in comment #3 is definitely not true. The code deals with edges by extending the region and filling it with the color under the center of the brush. This is probably not the most clever solution and the code could probably be improved. But we need a reproducable test case first.
Sven, it seems you are exactly right. The colour that seeps in from the sides is always the color directly under the cursor (not the average of all the colours under the brush as I suggested). In my example case, that colour is blue. The bug can now be stated as: When blurring with a brush touches the edge of the image, the colour beneath the cursor seeps in from where the brush overlaps the edge. A reproducable test case is: Take a blank canvas of colour A and draw a square on it of colour B. Then take a brush whose radius is larger than the distance of the black square to the edge of the image, place the center of the brush anywhere on the square (colour B) where the brush also overlaps the edge, and blur. Colour B will seep in from where the brush overlaps the edge.
We should improve the border behavior of the convolve tool then. It should extend the border pixels instead of using the brush center for this.
I formed the wrong conclusion from the image posted in #2. By coincidence the segment of the circle where it intersects with the edge of the image is about the same length as the end of the rectangular box. This gave the impression that it was mirroring part of the image. The offset I refered to is also an erroneous conclusion for the same reason. The bug is simply, as Sven says, the colour under the brush centre being used.
2007-05-05 Sven Neumann <sven@gimp.org> * app/paint-funcs/paint-funcs.c (convolve_region): instead of just copying the border pixels, convolute the full region and extend the borders. * app/paint/gimpconvolve.[ch]: removed broken code that used to deal with the image borders. Fixes bug #434279. Also reduced the matrix sizes to 3x3 as only the inner 3x3 values were nonzero.
I confirm that this bug has been fixed. Very nice, Sven. :)