[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] unsharp mask
From:       gg () catking ! net
Date:       2010-11-24 21:47:28
Message-ID: 4CED87F0.6030302 () catking ! net
[Download RAW message or body]

On 11/24/10 17:48, Øyvind Kolås wrote:
> On Wed, Nov 24, 2010 at 4:25 PM, Bill Skaggs<weskaggs@gmail.com>  wrote:
>> Maybe it would help to have a general explanation of the principle behind
>> the filter.
>>
>> The basic idea of the Unsharp Mask is to enhance the difference between the
>> original image
>> and a blurred version of it.  The algorithm first blurs the image, then
>> calculates the difference
>> between the original image and the blurred version, and then alters the
>> original image by
>> moving each pixel farther away from its blurred value.
>>
>> The convolution is simply a way of blurring the image.  There are countless
>> ways of
>> doing a blur -- the filter is using a rather crude approximation of a
>> Gaussian blur, which
>> is the most commonly used blurring algorithm.
>
> In GEGL unsharp mask is implemented at a higher level of abstraction
> than low-level filters and reuses gaussian blur directly, thus speed
> improvements to gaussian blur in GEGL will also benefit unsharp mask
> directly. See http://git.gnome.org/browse/gegl/tree/operations/common/unsharp-mask.c
> this version of unsharp mask can already be used in GIMP through the
> GEGL-tool, it would probably be good if the unsharp-mask in GIMP was
> properly replaced with the GEGL one.
>
> /Øyvind Kolås

Hi Øyvind ,


congratulations on this solid body of work in designing and building the 
gegl library. I'm sure it will have a lot of benefit as gimp is slowly 
migrated to use it. It gives a great opportunity to restructure a code 
base that has to a large extent grown more by evolution than design. 
There always comes a point where things need a good shake down. I'm sure 
gegl migration will provide that opportunity.


For unsharp filter , yes it does seem considerably quicker at applying 
the filter to the whole image than the existing gimp filter but 
unfortunately it has the do the whole image all the time for the preview.

Wouldn't it be better to have a preview window similar to the existing 
gimp preview which vastly reduces the amount of work needed for a 
preview and also lets the user focus on a particular zone of interest in 
the image.

Most images have a focal point or some other critical area where any 
effect needs to be optimised. A shot of a person this will nearly always 
be the face. How it affects the grass behind the subject is often of 
much less interest. Being able to work on a close up of a critical part 
is very valuable.

I think the preview is doing far more work than is needed and with high 
quality images being large this can be quite a drag in previewing 
different parameter values to adjust the effect.

The comment I made earlier about the existing preview and  the benefit 
of caching when flipping the preview on and off applies here also. Even 
more so really since it is processing the whole image. On a larger image 
it is simply not possible to flip preview on/off to directly compare the 
two. It can take 10s to process the image but it needs to be fast.

The eye (or the brain) is very good at picking up the slightest 
difference where an image if flipped like that and it is a useful 
technique to be able to compare them directly.


A couple of quick points in passing:

1/ why is there no threshold slider? How is the threshold determined? 
This can be a useful control.

2/ I find the slider titles and hint texts very unclear. Std deviation 
is too specific to the coding implementation and is no help to someone 
needing to process an image.  The hint does not really help clarify.

std dev is scale factor , yet scale is strength :?

The old "radius" seems clearer in terms of what it does to the image 
(that there is not a radius in the code is irrelevant).

The old "amount" was a pretty unhelpful, muddy term but maybe simply 
"sharpness" would be better than scale. After all this is all about 
sharpening the image.

Could I suggest :

radius : range of the effect
sharpness: intensity of effect
threshold: sensitivity to detail


It looks like the underlying code has now reached a maturity where it 
could be used full time but I feel that there is a slight regression in 
the level of control of the parameters and the preview which is, of 
course, very important in terms of usability.

regards, gg/




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

[prev in list] [next in list] [prev in thread] [next in thread]