GNOME Bugzilla – Bug 701677
Artifacts along the lower edge of gegl:gaussian-blur when processed as chunks
Last modified: 2015-04-26 20:53:54 UTC
Created attachment 246116 [details] My modified gaussian-blur that honors the input color channels. While adapting the gaussian blur filter to only work on the channels that were given as input, did i notice that gegl_buffer_set() yield erronous results for the "RGB format". The test was done using my modified gaussian-blur.c operation, attached to this bug report and with the following pygegl script: import Gegl for gegl_format in ['RGB','RGBA']: gegl = Gegl.Node() node_uni = gegl.new_child('gegl:color') node_add = gegl.new_child('gegl:add', value=0.5) node_crop = gegl.new_child('gegl:crop', x=0,y=0,width=100,height=100) node_blur = gegl.new_child('gegl:gaussian-blur') node_convert = gegl.new_child('gegl:convert-format', format=gegl_format + " float") node_save = gegl.new_child('gegl:ppm-save', path='bug-save-'+gegl_format+'.ppm') (node_uni >> node_add >> node_crop >> node_convert >> node_blur >> node_save).process() The results for the two different formats is attached in the image RGBvsRGBA-100x100.png Note that when the size for crop additional artifacts appear at the tile borders.
Created attachment 246117 [details] Image showing the difference between RGB and RGBA
When you process this graph you get a 100x100 output. gaussian-blur needs output + radius input pixels, however there are only 100x100 input pixels so it ends up reading from the abyss for those edge pixels. When the input has an alpha channel the abyss pixels are transparent and don't affect the result, but when it's RGB they're solid black and bleed in to he result. If you move your crop node after the gaussian-blur node you'll get the expected result, because it will generate output + padding pixels from color. Though considering all this I'm not sure non-alpha gaussian-blur is useful without extra logic to not read those abyss pixels.
Regarding the image boundaries, it makes somewhat sense for the RGB case, though perhaps it would be nice to be able to set additional boundary conditions, like wrap around, or additional colors. On the other hand, I'm still not at ease with the RGBA case, but I have to think about. But in practice as long as you crop after your blur, that's no problem. But, and I really should have shown that in the initial boundary report, not only do you get the effect at the image border. You get a similar darkening effect at tile borders, which is certainly wrong. You can see that by changing the size of the crop area from 100x100 to 1000x1000. I tried changing increasing the size of the area in prepare, but it didn't help. See the attachement RGBat1000x1000.png .
Created attachment 246126 [details] The image illustrates a bug at tile boundaries.
Those aren't tile boundaries, there are about 4 vertical tiles in each of those bands (default tiles are 128x64). I suspect those are the work chunks process() cuts it into. Are you sure that buffer area (area->left etc.) set in prepare matches what you're expecting? On further testing I can replicate the errors with the unmodified blur on a RGBA surface. It's easier to see with a different background, like gegl:checkerboard. The issue goes away if I use node_blit to do the entire image as one chunk, though I think I've ruled out any errors in process() itself.
Created attachment 247078 [details] Test case showing glitching at the edge of gaussian-blur without calling process. I think this a bug somewhere in gaussian blur, and probably some other area filters. I've attached my test case for blitting in chunks without involving the process() mechanics. If the entire thing is done as one chunk there are no errors.
The op with the problem is not used anymore, closing bug. commit a73037253476dca595a700d64f3c95aa877e3fad Author: Øyvind Kolås <pippin@gimp.org> Date: Sun Apr 26 16:10:51 2015 -0400 gaussian-blur: replace with the new one from workshop