> > Unfortunately, the code has more that one bug, or the correction
> > I made didn't solve the issue completely.
> I think we should then replace the example by something simpler. The
> point of this tutorial is not to show how to implement a blur. It is
> supposed to show some basic concepts of plug-in development. The code
> that is used as an example should be simple and bug-free. The current
> blur code doesn't seem to fulfill these requirements. So perhaps it
> should be replaced by a more local operation.
Perhaps... But what can be simpler than a blur...
> Another option would be to add a comment to the tutorial that points
> out that, for the sake of simplicity, the blur code is simpler than
> it would have to be and that it introduces a shift for that reason.
It's not only the shift. There is that grey band below the dark one...
The two dark ones are just because the first and last lines are
duplicated (radius) times. But the grey one?
> > Now: Could anyone please show me a SIMPLE code where the tile
> > handling is properly implemented, without bugs? I mean, the same
> > blurring plugin would be just perfect, but without bugs... From
> > this buggy example, I just don't understand how they work, so I am
> > not able to find the bug.
> The GIMP source code includes more than hundred plug-ins. I am sure
> you will find one or two that can serve as examples.
Perfect. I got blur.c.
> > 1) The old 1-pixel-down shift.
> > 2) The two dark bands (20 lines each) at top and bottom of the image.
> > 3) Even much intriguing is the grey band right below the top one,
> > also of 20 lines! And it is homogeneous (no likes inside)...
> try a square grid to see if you get the same grey band on x.
Good point. The two dark bands are still present (by the same reason),
but the grey one is not.
> > My 'solution' (change 'x1, y1,' in line 241 by 'x1, y1+1,')
> > took care of the shift, but not of the banding.
> > The homogeneous grey band just moved to the bottom...
> > (you cannot imagine the mess this does in my code!)
> This is what's known in the trade as a frig factor!
> You are arbitarily making an adjustment to correct one subjective
> error. You will likely find that on a different image it bahaves
> differently unless you understand why this adjustment is necessary
> and that +1 is a generally valid fix.
Absolutely. I am rewritting the code because of this.
> I cant comment on whether this is a bug in the tile code of the
> example or elsewhere. I suggest you look at some of the built in
Thanks to both,
Gimp-developer mailing list