On 11/24/10 17:48, Øyvind Kolås wrote:
> On Wed, Nov 24, 2010 at 4:25 PM, Bill Skaggs<weska...@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
> 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
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.
Gimp-developer mailing list