On Sat, 28 Apr 2007 13:56:33 +0200, Jasper Schalken  

>> I presume you are saying that there is some difference with the new
>> version.
> 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  
>> the
>> list archive since your ogg link may no longer be available in the  
>> future.
> 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
> 500KB?)
> (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

Reply via email to