From: "Luis A. Florit"

I reported this bug in this list some time ago . . .

For philosophical questions, it is good to bring them up first on this list. But for actual bugs, in the sense of the program doing something that is clearly incorrect, it is best to file a Bugzilla report. The advantage, and disadvantage, of Bugzilla is that nothing reported there is ever forgotten -- and few reports are completely ignored.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Mon, 30 Apr 2007 01:51:17 +0200, Luis A. Florit wrote:

Pals,

I reported this bug in this list some time ago, and got no answer (I think), and the 2.3.16 version still has the same bug: The despeckle plugin shifts the image one pixel to the right, and one to the bottom. Consequently, it is essentially useless. If you draw in the middle of a white background a black cross like this:

x
xxx
x

and run the despeckle plugin with radius 1, you get this asymmetric output:

x
xxx
xx

Thanks,

Luis.

I suspect it got ignored since one pixel offset errors are pretty much to be expected. I dont recall you mentioning the distortion last time.

could you provide more instructions to reproduce the error , I just made a cross ran despeckle and see not difference at all.

gg

Thank David Hodson and Sven, I have finished the code of adaptering OpenCV code to Gimp plugin. I wrote a simple HOWTO, hope it is useful to anyone interested in it. http://www.blogjava.net/solotim/archive/2007/04/30/114853.html

Luis A. Florit wrote:

Pals,

I reported this bug in this list some time ago, and got no answer (I think), and the 2.3.16 version still has the same bug: The despeckle plugin shifts the image one pixel to the right, and one to the bottom. Consequently, it is essentially useless. If you draw in the middle of a white background a black cross like this:

x
xxx
x

and run the despeckle plugin with radius 1, you get this asymmetric output:

x
xxx
xx

Thanks,

Luis.

gg@catking.net wrote:

I suspect it got ignored since one pixel offset errors are pretty much to be expected.

One pixel offset errors are *not* to be expected. If they occur, they are important bugs.

-- Bill

Hi,
gimpdevel@luisflorit.endjunk.com (2007-04-30 at 2137.21 -0300):

could you provide more instructions to reproduce the error,

Well, cannot tell you more...
Adaptative, nonrecursive, 1 pixel radius, black=7, white=248. A 5 pixel cross in the middle of a white image, and I got a NONSYMMETRIC 6 pixel output like this:

x xxx
xx

I see what you describe, with the 5 pixels being grey #88888 and the bg #ffffff. A longer cross (3 pixels each arm plus the center pixel) also returns something interesting:

x x x xx
x xx
xxxxxxx -> xxxxxxx
x xxxxxx
x xx
x xx

Repeating the filter makes it grow to the bottom right a bit each time.

GSR

GSR - FR wrote:

Hi,
gimpdevel@luisflorit.endjunk.com (2007-04-30 at 2137.21 -0300):

could you provide more instructions to reproduce the error,

Well, cannot tell you more...
Adaptative, nonrecursive, 1 pixel radius, black=7, white=248. A 5 pixel cross in the middle of a white image, and I got a NONSYMMETRIC 6 pixel output like this:

x xxx
xx

I see what you describe, with the 5 pixels being grey #88888 and the bg #ffffff. A longer cross (3 pixels each arm plus the center pixel) also returns something interesting:

x x x xx
x xx
xxxxxxx -> xxxxxxx
x xxxxxx
x xx
x xx

Repeating the filter makes it grow to the bottom right a bit each time.

GSR

I once wrote a path for it, this included the possibility of disabling the histogram correction (by setting the values out of range). It seems that a more recent patch reversed this option. Probably the out of range option was not the best way of implementing it, however the function does make sense for line-art and B&W photo's see bug #72862.

Revision *16861* - (view
)
(annotate
)
- [select for diffs]

2005-03-11 Sven Neumann >

* plug-ins/common/despeckle.c: test intensity against white and black level, not only the red channel. Improved border behavior. Iterate over the pixels row-by-row, instead of jumping through the data column-wise.

...

Revision *15374* - 2004-10-30 Sven Neumann >

* plug-ins/common/despeckle.c: applied a patch from Geert Jordaens that improves the Despeckle algorithm. See bug #72862 .

Right now I don't have the tme to followup a bug report or create a complete patch.

for (v = ymin; v < ymax; v++) {
gint off2 = v * width * bpp;

for (u = xmin, off2 += xmin * bpp; u < xmax; u++, off2 += bpp) {
guchar value = pixel_luminance (src + off2, bpp);

/* if (value < black_level) Allow no histogram correction on line art or b&w*/ if (value < black_level && filter_type & FILTER_ADAPTIVE) {
hist0++;
}

/* else if (value > white_level) Allow no histogram correction on line art or b&w*/ else if (value > white_level && filter_type & FILTER_ADAPTIVE) {
hist255++;
}
else
{
buf[count] = src + off2; ibuf[count] = value; count++;
}
}
}

Geert Jordaens

Luis A. Florit wrote:

Pals,

I reported this bug in this list some time ago, and got no answer (I think), and the 2.3.16 version still has the same bug: The despeckle plugin shifts the image one pixel to the right, and one to the bottom. Consequently, it is essentially useless. If you draw in the middle of a white background a black cross like this:

x
xxx
x

and run the despeckle plugin with radius 1, you get this asymmetric output:

x
xxx
xx

Thanks,

Luis.

From: "Luis A. Florit"

For Bill:
[...]

Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. [...]

Fedora maintainance sucks. Please don't judge GIMP's bug handling by Fedora.

For gg:

I suspect it got ignored since one pixel offset errors are pretty much to be expected.

???!!!
Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts!

As I wrote before, you are quite correct, and gg is wrong here. Rounding errors are to be expected every so often, although they should be fixed when they are found if possible, but a systematic 1-pixel offset in a filter is a serious bug that must be fixed.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Tue, 01 May 2007 18:08:35 +0200, William Skaggs wrote:

From: "Luis A. Florit"

For Bill:
[...]

Well, I am really tired about reporting bugs at Bugzilla and not even getting an answer, specially for Fedora bugs. [...]

Fedora maintainance sucks. Please don't judge GIMP's bug handling by Fedora.

For gg:

I suspect it got ignored since one pixel offset errors are pretty much to be expected.

???!!!
Well, now this answer was indeed unexpected! For me this kind of bugs is enough reason to never use a program!!! You cannot apply a filter with masks if it has shifts!

As I wrote before, you are quite correct, and gg is wrong here. Rounding errors are to be expected every so often, although they should be fixed when they are found if possible, but a systematic 1-pixel offset in a filter is a serious bug that must be fixed.

-- Bill

Since everyone seems to quoting what I wrote but only reading half of the sentence I probably should explain what I meant.

Please note the "I suspect it got ignored since". As Bill says here systematic offsets are a bug that should be fixed but random rounding errors are unavoidable in many cases. That means they should be random ie in both directions and not trucations errors always in one direction or a definite pixel offset.

There is an underlying issue where both origin and offset of a region are stored as gint before any processing is done. This means two rounding and/or trucation errors can easily end up producing a one or two pixel error.

I'm rather surprised that anyone following this list should mistake my position since I have been quite critical of just this kind of point, even in the last 7 days.

Now Luis has given a specific case and replied to my request for the filter settings needed to reproduce it, it seems to be getting the attention he felt it missed last time.

gg

From: gg@catking.net

There is an underlying issue where both origin and offset of a region are stored as gint before any processing is done. This means two rounding and/or trucation errors can easily end up producing a one or two pixel error.

Yes, but there are other basic coding errors that can easily cause a filter to shift its result by one pixel, too.

I'm rather surprised that anyone following this list should mistake my position since I have been quite critical of just this kind of point, even in the last 7 days.

I actually understood what you *meant*, but what you *said* to Luis was misleading and needed to be corrected.

Now Luis has given a specific case and replied to my request for the filter settings needed to reproduce it, it seems to be getting the attention he felt it missed last time.

Well, it's getting attention, but it probably won't get fixed unless there is a bug report. By the time people get back from LGM, all this discussion will have disappeared in Dev-list limbo, and probably nobody is going to go back and re-read it. (Unless you fix it yourself, gg :-)).

-- Bill

gg

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Hi,

On Tue, 2007-05-01 at 10:35 +0200, Geert Jordaens wrote:

IMHO this comes from the histogram correction, try the same with a black (000000) cross and white (FFFFFF) background.

see :

2004-10-30 Sven Neumann

* plug-ins/common/despeckle.c: applied a patch from Geert Jordaens that improves the Despeckle algorithm. See bug #72862.

Do you suggest that we back out this change then? Note that I only committed it. Perhaps I even understood it at that point in time but now I am pretty much clueless on what those lines are supposed to be good for.

Sven