0> In article ,
0> Jasper Schalken ("Jasper") wrote:

Jasper> ... blurring an image with the blur tool in 2.3.15 darkens it Jasper> as well as blurs, ...

Sounds suspiciously like an accumulation of rounding down in integer arithmetic... anyone?

Hi,

On Wed, 2007-04-25 at 02:41 +1000, Jasper Schalken wrote:

This is what I thought was a bug (I posted herehttp://bugzilla.gnome.org/show_bug.cgi?id=432978) but Sven Neumann says I should discuss it on here first.

Your video shows the blur tool being used on large areas of black color and small areas of white color. The average of this is a dark gray. Now when you continue to blur, you are mixing a dark gray with black. If you go further, you end up with all black.

But there could very well be rounding errors in the blur tool code. There are even most definitely rounding errors as we are only working with 8bit per channel and rounding errors are unavoidable then. But please take a look at the code and see if there's anything we could change to improve this.

Sven

On Tue, 24 Apr 2007 20:57:43 +0200, Sven Neumann wrote:

Hi,

On Wed, 2007-04-25 at 02:41 +1000, Jasper Schalken wrote:

This is what I thought was a bug (I posted herehttp://bugzilla.gnome.org/show_bug.cgi?id=432978) but Sven Neumann says I should discuss it on here first.

Your video shows the blur tool being used on large areas of black color and small areas of white color. The average of this is a dark gray. Now when you continue to blur, you are mixing a dark gray with black. If you go further, you end up with all black.

But there could very well be rounding errors in the blur tool code. There are even most definitely rounding errors as we are only working with 8bit per channel and rounding errors are unavoidable then. But please take a look at the code and see if there's anything we could change to improve this.

Sven

Jasper , your bug says:

It's algorithm
appears to favour dark colours when they are included in the blur.

Why do you say that? Does it still favour dark colours if the image is predominantly white?

From my understanding, the average lightness of a given image should always
remain constant as it is blurred.

What is your understanding , of what blur tool? Is there some specific blur algorithm that you believe does preserve lightness or is this just an assumption you were making?

Maybe you could be more precise about what blur you are refering to , there are several IIRC.

Please try to be a little more specific about what you are reporting.

Thanks.

just did a simple test

* 16x16 rgb image * select half (vertically in my case) and fill in * run the Gaussian blur, 1 blur pixel * Hold Ctrl+F to rerun the filter many times

- Image will eventually turn black - Happens for RLE and IIR

If its a rounding error, you could see if theres some way to give a more accurate result (cast to float?) - you probably alredy do that..

At worst, you could dither so every second pixel rounds up.

gg@catking.net wrote:

On Tue, 24 Apr 2007 20:57:43 +0200, Sven Neumann wrote:

Hi,

On Wed, 2007-04-25 at 02:41 +1000, Jasper Schalken wrote:

This is what I thought was a bug (I posted herehttp://bugzilla.gnome.org/show_bug.cgi?id=432978) but Sven Neumann says I should discuss it on here first.

Your video shows the blur tool being used on large areas of black color and small areas of white color. The average of this is a dark gray. Now when you continue to blur, you are mixing a dark gray with black. If you go further, you end up with all black.

But there could very well be rounding errors in the blur tool code. There are even most definitely rounding errors as we are only working with 8bit per channel and rounding errors are unavoidable then. But please take a look at the code and see if there's anything we could change to improve this.

Sven

Jasper , your bug says:

It's algorithm
appears to favour dark colours when they are included in the blur.

Why do you say that? Does it still favour dark colours if the image is predominantly white?

From my understanding, the average lightness of a given image should always
remain constant as it is blurred.

What is your understanding , of what blur tool? Is there some specific blur algorithm that you believe does preserve lightness or is this just an assumption you were making?

Maybe you could be more precise about what blur you are refering to , there are several IIRC.

Please try to be a little more specific about what you are reporting.

Thanks. _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

OK thanks for specifying what filters are doing this .

I just did a test with a rect that was just under half black half white with 2.2 . Using gaussian blur
repeatedly it ended up an even grey (114,114,114) after about 20 cntl-F reps. After 100 or so it was at 112.

It should have been lighter than 128 , this does seem to be consistant with a rounding error.

gg.

On Wed, 25 Apr 2007 01:08:21 +0200, Campbell Barton wrote:

just did a simple test

* 16x16 rgb image * select half (vertically in my case) and fill in * run the Gaussian blur, 1 blur pixel * Hold Ctrl+F to rerun the filter many times

- Image will eventually turn black - Happens for RLE and IIR

If its a rounding error, you could see if theres some way to give a more accurate result (cast to float?) - you probably alredy do that..

At worst, you could dither so every second pixel rounds up.

gg@catking.net wrote:

On Tue, 24 Apr 2007 20:57:43 +0200, Sven Neumann wrote:

Hi,

On Wed, 2007-04-25 at 02:41 +1000, Jasper Schalken wrote:

This is what I thought was a bug (I posted herehttp://bugzilla.gnome.org/show_bug.cgi?id=432978) but Sven Neumann says I should discuss it on here first.

Your video shows the blur tool being used on large areas of black color and small areas of white color. The average of this is a dark gray. Now when you continue to blur, you are mixing a dark gray with black. If you
go further, you end up with all black.

But there could very well be rounding errors in the blur tool code. There are even most definitely rounding errors as we are only working with 8bit per channel and rounding errors are unavoidable then. But please take a look at the code and see if there's anything we could change to improve this.

Sven

Jasper , your bug says:

It's algorithm
appears to favour dark colours when they are included in the blur.

Why do you say that? Does it still favour dark colours if the image is predominantly white?

From my understanding, the average lightness of a given image should always
remain constant as it is blurred.

What is your understanding , of what blur tool? Is there some specific blur algorithm that you believe does preserve lightness or is this just an assumption you were making?

Maybe you could be more precise about what blur you are refering to , there are several IIRC.

Please try to be a little more specific about what you are reporting.

Thanks.

Hi,

On Wed, 2007-04-25 at 15:26 +0200, gg@catking.net wrote:

OK thanks for specifying what filters are doing this .

I don't think Jasper was talking about any filters. As far as I understand him he is talking about the Smudge/Blur tool. I fixed the rounding error there today.

I also tested the Gaussian Blur plug-in on a pattern of white and black stripes and it yields 50% gray.

Sven

On Wed, 25 Apr 2007 01:08:21 +0200, Campbell Barton wrote:

just did a simple test

* 16x16 rgb image * select half (vertically in my case) and fill in * run the Gaussian blur, 1 blur pixel * Hold Ctrl+F to rerun the filter many times

- Image will eventually turn black - Happens for RLE and IIR

http://caoutchouc-detail.com/test-rect-histo.png

400 x 200 rect , half black / white.

todays cvs build 2.3.17 repeated gaussian blur filter RLE

as reported earlier, after scores of repeated blur grey value at 112 not 128.

gg

Hi,

On Wed, 2007-04-25 at 09:08 +1000, Campbell Barton wrote:

just did a simple test

* 16x16 rgb image * select half (vertically in my case) and fill in * run the Gaussian blur, 1 blur pixel * Hold Ctrl+F to rerun the filter many times

- Image will eventually turn black - Happens for RLE and IIR

As explained already, that's slightly off-topic as we were discussing the Blur tool, not the Gaussian Blur plug-in. But since you are bringing it up, let's have a look at the plug-in as well...

What you describe sounds like a very artifical test. As I outlined already, small rounding errors are hard to avoid. So it is not too unlikely that, even for a rather stable algorithm, you can create a test that, when repeated often enough, will give an error. Your test image is very small, so the contribution from the border is large. But of course, an ideal blur algorithm should deal correctly with that.

If we look at a larger test image filled with stripes of white and black color, the plug-in seems to do its job rather well. So I don't think there's urgent need to review the plug-in. But of course we will appreciate any patches that improve the result without hurting the performance.

Sven

On Thu, 26 Apr 2007 08:38:42 +0200, Sven Neumann wrote:

Hi,

On Wed, 2007-04-25 at 09:08 +1000, Campbell Barton wrote:

just did a simple test

* 16x16 rgb image * select half (vertically in my case) and fill in * run the Gaussian blur, 1 blur pixel * Hold Ctrl+F to rerun the filter many times

- Image will eventually turn black - Happens for RLE and IIR

As explained already, that's slightly off-topic as we were discussing the Blur tool, not the Gaussian Blur plug-in. But since you are bringing it up, let's have a look at the plug-in as well...

It seems that the initial report has pointed out a similar error in the filter. I said some time back that the use of gint() rather than round is fairly indemic in gimp and is an area that needs following up.

The errors are not aweful, slap in the face errors but it seems very many operations are degrading the image somewhat.

What you describe sounds like a very artifical test.

That is a comment that you often put forward in replies to bugs but it is necessary to develop specific test cases to pinpoint and quantify a problem.

There is little point in trying to blur a "real" image like a photo and then say it "it seems a bit darker".

Nearly all tests are necessarily artifical.

As I outlined already, small rounding errors are hard to avoid.

Trying to eliminate truncations of 8 bit data would be a big help. The only thing that would be hard is finding them all ;)

So it is not too
unlikely that, even for a rather stable algorithm, you can create a test that, when repeated often enough, will give an error. Your test image is very small, so the contribution from the border is large. But of course, an ideal blur algorithm should deal correctly with that.

If we look at a larger test image filled with stripes of white and black color, the plug-in seems to do its job rather well. So I don't think there's urgent need to review the plug-in.

I described a large image not affected by border issues and posted a histogram showing the mean 112 grey level . Since it is not too disimilar from your test case it's surprising that the results are so different.

Maybe you could post your test image somewhere so that we can compare the results and see why there is a clear difference.

/gg

But of course we will
appreciate any patches that improve the result without hurting the performance.

Sven

Hi,

On Thu, 2007-04-26 at 12:38 +0200, peter@piments.com wrote:

I said some time back that the use of gint() rather than round is fairly indemic in gimp and is an area that needs following up.

Yes, and I said in response that we are well aware of the fact that a lot of the algorithms used in GIMP just plain suck and that there's a lot to do all over the place. Now what's your point in repeating that over and over again? Please point out specific problems and, preferably, come up with patches.

What you describe sounds like a very artifical test.

That is a comment that you often put forward in replies to bugs but it is necessary to develop specific test cases to pinpoint and quantify a problem.

Artificial was the wrong term to use here. Sorry about that. What I meant to say is that the proposed test is not well chosen since it doesn't test the problem pointed out here. Instead it focuses on the behavior at the image border which is a different problem.

I described a large image not affected by border issues and posted a histogram showing the mean 112 grey level . Since it is not too disimilar from your test case it's surprising that the results are so different.

I couldn't reproduce your test, probably because you didn't provide all parameters (like for example the blur radius). But I think it suffers from the same problem. In order to blur two large areas in a way that yields a single (almost) solid colored area, you need to use a large blur radius. Your test image is then small compared to the blur radius and again you are mainly looking at the border behaviour.

Maybe you could post your test image somewhere so that we can compare the results and see why there is a clear difference.

Any image with a test pattern that is smaller than the blur radius will do. You can use the Stripes pattern or create a pattern using the Grid or Checkerboard plug-ins.

I have reduced the rounding errors in our blur plug-ins today. The results are a lot more stable now, even after multiple iterations.

Sven

On Thu, 26 Apr 2007 18:47:42 +0200, Sven Neumann wrote:

Hi,

On Thu, 2007-04-26 at 12:38 +0200, peter@piments.com wrote:

I said some time back that the use of gint() rather than round is fairly indemic in gimp and is an area that needs following up.

Yes, and I said in response that we are well aware of the fact that a lot of the algorithms used in GIMP just plain suck and that there's a lot to do all over the place.

It's not the algorithms that suck (to use your term) it's way it's coded. Not the same thing.

Now what's your point in repeating that

over and over again? Please point out specific problems and, preferably, come up with patches.

Over and over , I think not. I repeated it here since you were suggesting this sort of thing was unavoidable and saying it was the algorithms. I disagree, so I explained why.

What you describe sounds like a very artifical test.

That is a comment that you often put forward in replies to bugs but it is
necessary to develop specific test cases to pinpoint and quantify a problem.

Artificial was the wrong term to use here. Sorry about that. What I meant to say is that the proposed test is not well chosen since it doesn't test the problem pointed out here. Instead it focuses on the behavior at the image border which is a different problem.

I described a large image not affected by border issues and posted a histogram showing the mean 112 grey level . Since it is not too disimilar
from your test case it's surprising that the results are so different.

I couldn't reproduce your test, probably because you didn't provide all parameters (like for example the blur radius). But I think it suffers from the same problem. In order to blur two large areas in a way that yields a single (almost) solid colored area, you need to use a large blur radius. Your test image is then small compared to the blur radius and again you are mainly looking at the border behaviour.

Maybe you could post your test image somewhere so that we can compare the
results and see why there is a clear difference.

Any image with a test pattern that is smaller than the blur radius will do. You can use the Stripes pattern or create a pattern using the Grid or Checkerboard plug-ins.

I have reduced the rounding errors in our blur plug-ins today. The results are a lot more stable now, even after multiple iterations.

Sven

Excellent work! I just reran my test case (which was centred on the b/w boundry in the middle of the image) and it works almost perfectly after a very large number of reps.

Now the mean grey values are 129.9 , a very credible result for 8bit processing.

The gimp now has a much better implementation of the gaussian blur algorithm. Great news.

and thanks to Jasper Schalken for bringing up the whole blur darkening issue.

/gg

Hi,

On Fri, 2007-04-27 at 15:59 +1000, Jasper Schalken wrote:

So this is fixed in cvs? For the tool, plugins, or both?

We aren't using CVS any longer (for a few months now). If you want to check the state in SVN, there's http://svn.gnome.org/viewcvs/gimp and http://developer.gimp.org/ChangeLog.

And no, we aren't going to backport these changes to the stable branch.

Sven

Jasper Schalken ha scritto:
...

Anyone have a page for me to look at to compile GIMP from SVN?

Have a look at http://developer.gimp.org/ and particularly at http://developer.gimp.org/svn.html for subversion access and http://developer.gimp.org/HACKING for compilation but take into account that your mileage may vary depending on the platform you are on.

I am successfully compiling unstable GIMP on Ubuntu Linux for example.

Ciao

Hi,

On Fri, 2007-04-27 at 22:06 +1000, Jasper Schalken wrote:

Anyone have a page for me to look at to compile GIMP from SVN?

http://developer.gimp.org/svn.html

Sven

On Sat, 28 Apr 2007 09:43:45 +0200, Jasper Schalken wrote:

It seems to blur/spread even further:

I presume you are saying that there is some difference with the new version. 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.

I also noticed a marked increase in the spread of values in the histogram but I ignored it thinking it was due to the rather arbitary number of reps I did on the Cntl-F key. Std deviation now 35 against 6.0 before.

Maybe it is in fact an artifact of the changes in the code. Now whether that is a bug or an improvement in the code I am not sure.

http://caoutchouc-detail.com/test-rect-histo.png http://caoutchouc-detail.com/test-rect-histo-fix.png

gg

On Sat, 28 Apr 2007 13:56:33 +0200, Jasper Schalken 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.

On Sat, 28 Apr 2007 18:42:50 +0200, Jasper Schalken wrote:

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.

You could have a look at the matrix convolution filter code. (Be warned there are some minor bugs concerning edge effects IIRC) but it will serve as an introduction to the different ways of treating edge data.

Many algorithms , from the various interpolation methods to the many filters based on matrix convolution of which blur is an example, can require data outside the image to function upto the edge.

This has quite simply to be made up by one means or another. There are several strategies whose suitabilities generally depend on the image content.

So in short , no, they cant just be ignored.

gg

For info on different technics of handling the edge you could always have a look at :

http://www.cs.cornell.edu/Courses/cs465/2003fa/lectures/04filt-resamp/

Geert

On Sun, 29 Apr 2007 07:30:42 +0200, Jasper Schalken wrote:

The bug report: http://bugzilla.gnome.org/show_bug.cgi?id=434279

On 29/04/07, Jasper Schalken wrote:

You could have a look at the matrix convolution filter code. (Be

warned

there are some minor bugs concerning edge effects IIRC) but it will

serve

as an introduction to the different ways of treating edge data.

Is that "void convolve_region(...) {...}" in /gimp/trunk/app/paint-funcs/paint-funcs.c?

It doesn't have many comments, so I'm not sure what its doing nor what a convolution matrix is. I thought it would be along the lines of "for each pixel in the region make it the average of all the pixels within a certain radius". However, that gives a box blur and it may be Gaussian instead.

I think I will just put this in a bug report and let someone who knows have a look. :S

500 Internal Server Error
Looks like bugzilla is still in bed ;)

The filter I was refering to is in the following file: gimp/plug-ins/common/convmatrix.c

The variable names should be explicit enough to make the code self documenting but if you dont know what convultion or convultion matrix is you may want to read up a bit. The implementation is not far from what you outlined above, so it's not as intimidating as it sounds.

The lanczos interpolation that was recently added works in a similar way with a larger matrix (and suffers from a similar "one size fits all" border extrapolations).

On a large images these border issues are generally not a worry, but on small graphics like web buttons and glyphs they can become very visible as you have noted. This is probably worth a bug report if there is not one already since it will need to be dealt with more thoroughly for gimp to fullfil it's aims to be a top end application.

HTH.