Isn't it possible for the code to simply disregard pixels outside the image? That is, instead of pretending they actually exist and have a colour (if it works as I described above, that colour being the average of all the other pixel's colours), just don't include them in the blur at all. Only blur with pixels that do exist. But someone should have a look at the code before I take my assumptions/theories too far. I will have another look and see if I can understand what it is doing. On 28/04/07, gg@xxxxxxxxxxx <gg@xxxxxxxxxxx> wrote: > On Sat, 28 Apr 2007 13:56:33 +0200, Jasper Schalken > <jasperschalken@xxxxxxxxx> wrote: > > >> 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. > > gg > > > > > 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
