[Digikam-devel] [Bug 127374] unsharp mask: max. radius way too small!

Caulier Gilles caulier.gilles at kdemail.net
Tue May 16 22:51:12 BST 2006


It's very intructive Peters. Thanks for these informations.

Gilles

Le Mardi 16 Mai 2006 11:12 PM, Peter Heckert a écrit :
> Hello,
>
> While I am not a specialist I have done a lot of investigation about
> gaussian filters and
> graphics blur- and sharpening filters in common.
> So I feel I should comment some of your questions.
>
> Matthias Wieser schrieb:
> > What does this mean?
> > It seems to be impossible now to use a radius below 1 pixel.
>
> Yes, that depends on the algorithm used. Real Gauss filters would have
> infinite resolution.
> This is impossible, because the pixel data has finite resolution.
> therefore gaussian filters
> with radius < 10 pixels always arent real gauss filters, but an rough
> approximation for
> the theoretic gauss filter.
> Some do this approximation in pixel granularity, others try to do an
> approximate
> sub-pixel interpolation, but they all are inaccurate at low radius.
>
> Also they all differ in accuracy. However there is only one application
> where high
> accuracy is required: Edge detection.
> For the simple purpose to blur an image, or to sharpen an image I would
> prefer less
> accurate, but faster algorithms, for example multi pass boxfilters.
>
> Thats the other point: All gaussian filters as implemented in gimp,
> cinepaint or
> digikam are way too slow for a 100 pixel radius blur. Gimp would need
> 1/2 hour
> for a multi-megapixel image, photoshop needs 1-2 seconds ;-)
>
> I have written some investigation and little rants about this: ;-)
> <http://www.hphsite.de/dcamnoise/theory.html>
> <http://www.hphsite.de/dcamnoise/Gaussian-blur.html>
>
> I believe, it would be the best to use simple boxfilters for gaussian
> blur and for
> USM, because they are very fast, regardless of radius size (if well
> programmed)
> and because they are absolutely numerical stable at low radius, and
> because an
> isotropy error of some percent wouldnt be noticeable for this type of
> application.
>
> > Btw.: Is it intentional that most plugin dialogs do not state which units
> > are used?
>
> Normally the standart deviation in pixel units is meant for "radius".
> It is really difficult -if not impossible- to calcultate this for low
> radius, and the
> exact definition of radius doesnt exist.
>
> > Sharpness: 0 - 100: Percent? Some other unit?
>
> Gaussian blur: 0 - 100: Radius in Pixel?
>
> > Noise reduction: ?? (How do I reduce the strength of the default noise
> > reduction to e.g. 50%? No idea, maybe I should look into the handbook...)
>
> There is no adjustment for 50% noise reduction.
> The amount of noise reduction depends from the noise granularity and
> from the
> images gamma value and from other imponderables.
> The user must find the best threshold level by trial and error.
>
> I try to overcome this, however this would require to process the whole
> image
> twice, there is a lot of work to do.
> Currently I believe, that the noise reduction algorithm would be better
> used in
> gimp or some other image editing application, where the regions of
> interest can
> be masked.
>
> In Noise reduction i implemented a gaussian blur recipe taken from here:
> <http://www.ph.tn.tudelft.nl/~lucas/publications/1995/SP95TYLV/SP95TYLV.pdf
>> (There you can see how complicated this stuff can be ;-)
>
> Recently I have found out, that this algorithm is fine for edge
> detection, because it
> has good isotropy at large radius, but it is bad for sharpening, because
> it is
> numerically unstable at low radius.
> <http://groups.google.de/group/comp.graphics.algorithms/browse_thread/threa
>d/abda3a7841349a52/350b81531d7f1512>
>
> Here are the impulse responses of a gauss-iir filter:
>
> Example:
>
> Radius 0.25:
> 55    -0.000000
> 54    0.000001
> 53    -0.000046
> 52    0.001762
> 51    -0.055922
> 50    1.108410
> 49    -0.055922
> 48    0.001762
> 47    -0.000046
> 46    0.000001
> 45    -0.000000
> 44    0.000000
>
> (It's interesting that this has 2nd derivative as a component.)
>
> Radius 0.5:
> 56    0.000001
> 55    0.000007
> 54    0.000086
> 53    0.001093
> 52    0.012896
> 51    0.122505
> 50    0.726826
> 49    0.122505
> 48    0.012896
> 47    0.001093
> 46    0.000086
> 45    0.000007
> 44    0.000001
>
>
> So I switched to boxfilters in my new version.
>
> > Unsharp mask:
> > Radius: 0 - 100: Pixel?
> > Amount: 0 - 1: Strength normalized to 1?
> > Threshold: 0 - 1: Pixel color normalized to 1? But the histogram shows
> > pixel colors in the range from 0 - 255 (for 8 bit images). Should be the
> > same, should'nt it?
>
> Most of them try to mimic photoshop and use arbitrary estimated values.
> If you want to know exactly, look into the source.
> This will get worse, when it comes to 16-bit images. Is the treshold
> meant as percent,
> is it meant as a 0-255 intensity value or is it meant as a 0-65536
> intensity value?
> (Even photoshop isnt clear here and also the curves tool misbehaves when
> the image
> has gamma=1 and 16 bit)
>
>
> greetings,
>
> Peter
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel



More information about the Digikam-devel mailing list