GNOME Bugzilla – Bug 433251
Despeckle producing strange results
Last modified: 2008-01-15 14:11:41 UTC
Please describe the problem: The "Despeckle" filter seems to be producing unexpected results, as follows: 1) Using the "Adaptive" option appears to make the filter do nothing 2) Using the "Recursive" option appears to "smear" the image out of all recognition. Steps to reproduce: Actual results: Expected results: Does this happen every time? Without checking the "Adaptive" and "Recursive" options the filter appears to work as one would expect. Other information: This is using Debian Sid. I'm happy to supply sample results if this problem is unusual in any way.
The algorithm could definitely be improved. But I don't follow all your observations. The plug-in does things, even with the "Adaptive" option checked. The behavior with "Recursive" checked is however somewhat unexpected.
Recursive also seems to work reasonably for larger radii.
OK. I'll allow that Adaptive might be working (the radius setting doesn't appear to have much effect on it but maybe that's normal). Recursive, however, seems to produce no usable results for me even with the radius set to 20 (the maximum available in the normal interface). I just tried it here on an untouched image from my camera and ended up with everything basically smeared rightwards & downwards. This tutorial here: http://www.gimpguru.org/Tutorials/RemovingHotPixels/ shows quite different effects using a radius of only 3. Would you like me to attach any samples, or do any further debugging of the problem?
Since I very much doubt that we will find time to debug this, any further debugging will be very much appreciated. Note that the algorithm has been changed since GIMP 2.2. It is thus not surprising that the tutorial shows different results.
Referring to Comment #26 from bug #72862 To summarize. When using the white and black values one influences the median filter. -With highly saturated images the white level should not be chopped off becaus it will have a big influence on the image however one can safely chop off with the black level since this would not make a big difference. -Mostly white images : stay of the white level (set it to 256) If dark spots have to be removed one can play around with the black level. -Mostly black images : stay of the black level. (set it to -1) If white spots have to be removed one can play with the white level. The possibility of setting the values to -1 and 256 was removed in a more recent patch. The correct implementation in my opinion should be allow the black / white level correction on a individually. Right now I don't have the tme to followup a bug report or create a complete patch. However the problem according to me is that the else statement is not executed correctly. Things to fix : 1. The else statement should always be executed if filter adaptive is not set. 2. Black and White leves correction should be chosen on rules above. 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); /* Only correct histogram if filter adaptive is set cannot be less than 0 so setting black-level to -1 should disable this correction. */ if (filter_type & FILTER_ADAPTIVE && value < black_level) { hist0++; } /* Only correct histogram if filter adaptive is set value cannot be greater than 255 so setting white-level to 256 should disable this correction. */ if (filter_type & FILTER_ADAPTIVE && value > white_level) { hist255++; } /* If the adaptive filter is active only consider pixels having a value between black and white level. The new value will be the median of the values in ibuf. */ if ( !(filter_type & FILTER_ADAPTIVE && value > white_level)|| !(filter_type & FILTER_ADAPTIVE && value < black_level)|| ) { buf[count] = src + off2; ibuf[count] = value; count++; } } }
Created attachment 87417 [details] [review] Restores 2.2 behavior Patch that restores 2.2 behavior, gui changes +2.2 are included. - known issue : - Does not work well on small images < 2 * radius + 1. Then again who needs a despeckle plugin for such a image the bad pixels can be hand picked. - Borders are not despeckled (radius).
Setting on milestone 2.4 so we don't forget to do something about what looks like a regression. Geert, can you explain shortly what your patch does?
Pleas do not yet apply the patch, yesterday evening I already had a 20h day, there the adaptation of the radius should still be fixed. basicly, I merged the latest version of the despeckle plugin and the version of 2.2 that I worked on. The main changes are in : - The parameter "black" can be set to -1 : -1 disables the histogram correction on the black side. - The parameter "white" can be set to 256 : 256 disables the histogram correction on the white side. - Used function despeckle_median from 2.2 version and modified it. The main difference is that the histogram correction is handled correctly. Only values between black and white level are selected for determining the median. - The adaptation of the radius is not yet correct. Should be as below. (REGRESSION !!!) if (value <= black_level) hist0++; if (value =< white_level) hist255++; - Border handling is different for 2.2 and latest version. (REGRESSION !!!)
Created attachment 87484 [details] [review] Despeckle plug-in improved recursive / edge handling Patch should be ready now for general acceptance. basicly, I merged the latest version of the despeckle plugin and the version of 2.2 that I worked on. The main changes are in : - The parameter "black" can be set to -1 : -1 disables the histogram correction on the black side. - The parameter "white" can be set to 256 : 256 disables the histogram correction on the white side. - Used function despeckle_median from 2.2 version and modified it. The main difference is that the histogram correction is handled correctly. Only values between black and white level are selected for determining the median. - The adaptation of the radius is corrected. - Border handling is different as in current version.
Thanks a lot for that patch. Works much better now. 2007-05-03 Sven Neumann <sven@gimp.org> * plug-ins/common/despeckle.c: applied patch from Geert Jordaens plus some minor cleanups. Fixes bug #433251.