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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         
           Summary: unsharp mask: max. radius way too small!
           Product: digikamimageplugins
           Version: unspecified
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: mwieser gmx de


Version:           unknown (using KDE 3.5.2 Level "a" , SUSE 10.0 UNSUPPORTED)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.13-15.8-default

The radius of the "unsharp mask" digikam-imageplugin filter (svn version, as of 15.05.2006) is limited to a radius of 10 which is way too low.

The unsharp mask filter has too uses: to sharpen a image (radius 0.1 to ~5 pixel) and to apply a local contrast enhancement (radius ~5% of image width). The second use case is not possible with digikam's unsharp mask plugin.

Example:
Take a 5MPixel image done at a day with bad weather and apply an unsharp mask with radius: 90 pixel, strength: 0.3, threshold:0. (you can do this with gimp, too)

Would be nice, if someone could remove this artificial constraint of digikam's unsharp mask.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From caulier.gilles free fr  2006-05-15 18:54 -------
All old settings limits have been restored from 0.8.x serie. Note : this plugin use a new algorithm based on ImageMagick implementation to support 16 bits image, not gimp algorithm !
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From caulier.gilles free fr  2006-05-15 18:54 -------
closed
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From mwieser gmx de  2006-05-15 23:14 -------
Hi,

> ------- Additional Comments From caulier.gilles free fr
> All old settings limits have been restored from 0.8.x serie.


Thanks for the quick response!

> Note
> : this plugin use a new algorithm based on ImageMagick implementation to
> support 16 bits image, not gimp algorithm !


What does this mean?
It seems to be impossible now to use a radius below 1 pixel.



Btw.: Is it intentional that most plugin dialogs do not state which units
are used?

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...)

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?

Anti-Vignetting:
Density: 1 - 20: Percent? Not really, seems to be something other

Distortion effect:
Iteration: 0 - 100: ?? Seems to have no effect... (Bug?)
[...]

Regards,
  Matthias
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

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/thread/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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From rfkd fietze-home de  2007-07-04 18:50 -------
E.g. as of http://redskiesatnight.com/Articles/IMsharpen/ the radius as defined in gimp, Photoshop or ImageMagick are the same, so digikam should be able to use a smaller radius than 1 and other non integral values.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From arnd.baecker web de  2007-07-04 18:58 -------
This bug is marked as closed, should this be re-opened
or would it be better to set up a new one?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From mikmach wp pl  2007-07-04 19:16 -------
> or would it be better to set up a new one?


Setup new one with expanded version: also minimal radius of 1.0 pixel is
too big. In many texts about USM radius smaller than 1 pixel is
recommended for some tasks.

m.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=127374         




------- Additional Comments From arnd.baecker web de  2007-07-13 10:42 -------
Roman,

could you please file a new bug for you wish?
(Otherwise it gets lost because this bug is closed.)

Many thanks, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel