On Sat, 28 Apr 2007 13:56:33 +0200, Jasper Schalken
<[EMAIL PROTECTED]> wrote:
>> I presume you are saying that there is some difference with the new
> No this was present in the previous version, however trivial in
> comparison to the darkening bug.
>> Perhaps a more explicit description would be helpful if a couple
>> of sentences could save us downloading a movie. It is also better for
>> list archive since your ogg link may no longer be available in the
> Okay. When blurring, 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).
> Here is a perfect example:
> http://schalken.wubbles.net/gimpblurnearedge2.ogg (you can handle
> (or pic: http://schalken.wubbles.net/gimpblurnearedge2.png , it was
> originally just a blue square before blurring in the region show)
Thanks , that speaks a thousand words.
I have not dug into the code but it's pretty clearly that the code is
mirroring the image (and adding an offset bug in the other axis)
It may be a good feature to add various options for dealing with boundary
to the interface since this is clearly a mess on an example like yours.
Here continuing the edge colour would be a better choice for example.
This is a case where it needs to be chosen according to the nature of the
image. There is no "most people want to do ..." solution here.
Your case would represent a block graphic image type and the result is
clearly unacceptable for the Gimp's "top end application" aspirations.
Thanks for the detail.
> 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.
Gimp-developer mailing list