RSS/Atom feed Twitter
Site is read-only, email is disabled

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

15 of 15 messages available
Toggle history

Please log in to manage your subscriptions.

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 03 Dec 17:34
  Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Teo Mazars 03 Dec 19:10
   Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Joao S. O. Bueno 03 Dec 19:45
   Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 03 Dec 20:40
    Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Teo Mazars 03 Dec 21:14
   Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 04 Dec 20:58
    Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Teo Mazars 04 Dec 21:50
     Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Joao S. O. Bueno 04 Dec 22:27
      Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 04 Dec 23:15
       Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 05 Dec 17:14
        Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Elle Stone 05 Dec 19:03
        Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Teo Mazars 05 Dec 19:08
         Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Michael Henning 06 Dec 01:03
          Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Teo Mazars 06 Dec 10:24
  Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues Joao S. O. Bueno 03 Dec 19:40
Elle Stone
2013-12-03 17:34:08 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

Hi all,

As Gimp 2.10 seems to be closer to being a reality, I wanted to bring up some minor but annoying useability issues with Gegl Gaussian Blur and Unsharp Mask.

Gegl USM slider range - can't use the slider for small values:

There are many algorithms to add "local contrast enhancement" to an image. But my favorite algorithm remains high radius low amount USM (http://www.luminous-landscape.com/tutorials/contrast-enhancement.shtml).

For a sample camera-generated jpeg, in Gimp 2.8, Radius 50.0, Amount 0.15, Threshold 0 does a nice job. Experimenting, the Gimp 2.9 USM settings that produce a similar result are Std. Dev. 4.00, Scale 0.20. These are very small values on a very large slider range.

For regular sharpening I use values like 0.5/0.3 or 0.75/0.25. The Gimp 2.9 Gegl USM sliders aren't useable for modifying these small values to see whether "a little more, a little less" might be better. And typing in "slightly larger, slightly smaller" values is awkward.

No doubt there are use cases for very large (10 or 20 or higher) USM slider values, but they would seem to fall into the category of special effects rather than normal image editing. Normal image editing would be easier if the sliders were easier to use when dialing in small values.

It would help a lot if the max value for the slider ranges could be set to say 10 (or a user-specifiable value), with an option to multiply by 10 or 100 to get larger max values.

Gegl Gaussian Blur slider range:

Many times a large radius blur is needed. Many times a small radius blur is needed. The Gegl blur "unit" is larger than a single pixel and it's not easy to choose a small value using the slider. So to test the effect of various small radius blurs, the only alternative seem to be to type the values in.

A smaller "max value", perhaps 255, might help, perhaps with a check box to multiply the values by 10 for a maximum of 2550, if anyone actually uses values that large (my computer would crawl into a corner and croak if I tried to use a 2550 blur radius).

Masks and Gaussian Blur:

Many times seeing the effect of blurring on the image is the most important thing, which the new Gegl Gaussian blur makes possible (yeah!). But when modifying a mask, it's important to see the amount of mask blur directly.

The old, non-Gegl Gaussian Blur dialog shows a small box at 100%. Albeit with a lot of scrolling around, that little box helps avoid situations where too small a blur on a mask creates a line of abrupt tonal transition in the image, that might not become obvious until later in the editing process or when the image is viewed at 100%.

Keeping the old dialog would help, but it would be fantastic to see the entire blurred mask rather than just a tiny portion of it at a time.

Units:

What is the Gegl Gaussian blur "unit" and what's its mathematical relationship to a 1-pixel Gaussian blur?

What is the USM Std. Dev. and Scale mathematical relationship to the old Radius and Amount? And what happened to USM Threshold? (I don't use Threshold, but a lot of sharpening tutorials mention it.)

Gegl Gaussian Blur and Unsharp Mask sliders are touchy:

Sometimes when I'm trying to type in a value, instead I accidentally cause the slider to move all the way to the right side of the slider box, and Gimp/Gegl starts doing a very time-consuming unwanted operation. The cancel button takes a long time to respond, probably because the cancel signal has to fight for a share of the CPU, which pegs at 100%.

The ability to set the max values on the sliders would solve this problem (I'd still be clumsy with the mouse, but the price of clumsiness would be a lot smaller!).

Complaints aside, Gimp from git is great. Otherwise there'd be no reason to complain about the details!

Elle

Teo Mazars
2013-12-03 19:10:32 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

Hi,

The way GEGL currently exposes each numerical parameters is as follow:

1) A nominal range, say [a, b], which represents the range where the operation is expected to work 2) An UI range, [a', b'] included in [a, b], representing the area of interest of the parameter. 3) An exponent, (like a gamma correction), to make the slider not behave linearly on the [a', b'] range.

Currently, GIMP's sliders "show" only [a', b'], but allows values in [a, b]. The exponent is the way GEGL handles the "mutli-scale" problem and it allows to have more precision on small value. Those values are all in GEGL, look for eg gegl_chant_double_ui in /operations/common/*.c

I will let others comment on what is the optimal UI range for those two operations. But changing [a', b'] would be really easy, and it should change the "unit" as well. I am not sure about making that range "user configurable", it makes sense imho.

In the GEGL Gaussian blur, parameters are the std_dev along x and y, describing mathematically the Gaussian curve used as kernel. Though, I have to read the code to know where the infinite curve is clipped to have a "only-one-pixel" actual radius. Which is not obvious...

Other than that, I don't really understand the "Masks" comment. You can see the actual mask by checking "Show the layer mask", but perhaps you want to see both the mask and the resulting image at the same time?

Hah, and the "computational explosion" with bad parameters is a known bug in a lot of GEGL operations, it may even make GIMP crash. It probably needs to be fixed in each operation individually, but this is not obvious... Perhaps we will need to make the "process" step of GeglOperations cancellable at some point? Unclear...

Also keep in mind that this is all "work in progress", Mitch once said that the ui infrastructure for GEGL Operations in GIMP is not done. And most of GEGL Operations still need some love.

Regards,

Téo

Hi all,

As Gimp 2.10 seems to be closer to being a reality, I wanted to bring up
some minor but annoying useability issues with Gegl Gaussian Blur and Unsharp Mask.

Gegl USM slider range - can't use the slider for small values:

There are many algorithms to add "local contrast enhancement" to an image. But my favorite algorithm remains high radius low amount USM (http://www.luminous-landscape.com/tutorials/contrast-enhancement.shtml).

For a sample camera-generated jpeg, in Gimp 2.8, Radius 50.0, Amount 0.15, Threshold 0 does a nice job. Experimenting, the Gimp 2.9 USM settings that produce a similar result are Std. Dev. 4.00, Scale 0.20.
These are very small values on a very large slider range.

For regular sharpening I use values like 0.5/0.3 or 0.75/0.25. The Gimp
2.9 Gegl USM sliders aren't useable for modifying these small values to
see whether "a little more, a little less" might be better. And typing
in "slightly larger, slightly smaller" values is awkward.

No doubt there are use cases for very large (10 or 20 or higher) USM slider values, but they would seem to fall into the category of special
effects rather than normal image editing. Normal image editing would be
easier if the sliders were easier to use when dialing in small values.

It would help a lot if the max value for the slider ranges could be set
to say 10 (or a user-specifiable value), with an option to multiply by
10 or 100 to get larger max values.

Gegl Gaussian Blur slider range:

Many times a large radius blur is needed. Many times a small radius blur
is needed. The Gegl blur "unit" is larger than a single pixel and it's
not easy to choose a small value using the slider. So to test the effect
of various small radius blurs, the only alternative seem to be to type
the values in.

A smaller "max value", perhaps 255, might help, perhaps with a check box
to multiply the values by 10 for a maximum of 2550, if anyone actually
uses values that large (my computer would crawl into a corner and croak
if I tried to use a 2550 blur radius).

Masks and Gaussian Blur:

Many times seeing the effect of blurring on the image is the most important thing, which the new Gegl Gaussian blur makes possible (yeah!). But when modifying a mask, it's important to see the amount of
mask blur directly.

The old, non-Gegl Gaussian Blur dialog shows a small box at 100%. Albeit
with a lot of scrolling around, that little box helps avoid situations
where too small a blur on a mask creates a line of abrupt tonal transition in the image, that might not become obvious until later in the editing process or when the image is viewed at 100%.

Keeping the old dialog would help, but it would be fantastic to see the
entire blurred mask rather than just a tiny portion of it at a time.

Units:

What is the Gegl Gaussian blur "unit" and what's its mathematical relationship to a 1-pixel Gaussian blur?

What is the USM Std. Dev. and Scale mathematical relationship to the old
Radius and Amount? And what happened to USM Threshold? (I don't use Threshold, but a lot of sharpening tutorials mention it.)

Gegl Gaussian Blur and Unsharp Mask sliders are touchy:

Sometimes when I'm trying to type in a value, instead I accidentally cause the slider to move all the way to the right side of the slider box, and Gimp/Gegl starts doing a very time-consuming unwanted operation. The cancel button takes a long time to respond, probably because the cancel signal has to fight for a share of the CPU, which pegs at 100%.

The ability to set the max values on the sliders would solve this problem (I'd still be clumsy with the mouse, but the price of clumsiness
would be a lot smaller!).

Complaints aside, Gimp from git is great. Otherwise there'd be no reason
to complain about the details!

Elle _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Joao S. O. Bueno
2013-12-03 19:40:38 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

Agreeded - the size sliders in GIMP are a problem - I've implemented the logarithmic slider back in the time - and it was ovecome by the new linear sliders. I still don't see how the lienar sliders make sense - when painting detail one endś up using the left 5% of the slider to count values.
(The new widget also takes more well positioned clicks to allow one to type in a new value - on the up-to-2.6 widget, one could click, swipe over the text entry box - that would select the value there, and just type in a new value -
the way the new one misbehaves is subtle, but far harder to use )

Can we rethink those sliders for gimp 2.10 ? Not trying to add new features/fixes like I tried in the final days before 2.8 (make the "click on botton half to slide the value" behavior to be sensible to mouse speed), - but check how is the actual usage, and put in place something less clumsy instead?

(And have in mind you are talking about a value one sets ina dialog, but the same disfunctional widgets are used when painting) On 3 December 2013 15:34, Elle Stone wrote:

For a sample camera-generated jpeg, in Gimp 2.8, Radius 50.0, Amount 0.15, Threshold 0 does a nice job. Experimenting, the Gimp 2.9 USM settings that produce a similar result are Std. Dev. 4.00, Scale 0.20. These are very small values on a very large slider range.

Joao S. O. Bueno
2013-12-03 19:45:02 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 3 December 2013 17:10, Teo Mazars wrote:

Hah, and the "computational explosion" with bad parameters is a known bug in a lot of GEGL operations, it may even make GIMP crash. It probably needs to be fixed in each operation individually, but this is not obvious... Perhaps we will need to make the "process" step of GeglOperations cancellable at some point? Unclear...

Certainly it would be a lot better if while trying to click on the number to type in a new valuein the Gaussian Blur filter dialog in GIMP, you could not "accidentally" click on the bar bringnig the radius to 850, and having to wait several seconds until GIMP becomes responsive again.

"accidentally" is quoted, because it is actually very hard not to make that happen. I know the widgets are pretty - no one can deny that - but maybe, just letting the typeable values lie outside the range of the slider would be a nice-enough fix already.

Elle Stone
2013-12-03 20:40:51 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 12/03/2013 02:10 PM, Teo Mazars wrote:

Hi,

The way GEGL currently exposes each numerical parameters is as follow:

1) A nominal range, say [a, b], which represents the range where the operation is expected to work 2) An UI range, [a', b'] included in [a, b], representing the area of interest of the parameter. 3) An exponent, (like a gamma correction), to make the slider not behave linearly on the [a', b'] range.

Currently, GIMP's sliders "show" only [a', b'], but allows values in [a, b]. The exponent is the way GEGL handles the "mutli-scale" problem and it allows to have more precision on small value. Those values are all in GEGL, look for eg gegl_chant_double_ui in /operations/common/*.c

I will let others comment on what is the optimal UI range for those two operations. But changing [a', b'] would be really easy, and it should change the "unit" as well. I am not sure about making that range "user configurable", it makes sense imho.

That sounds like maybe I can change the slider scale in the source code pretty easily, even if it never gets changed in git. Thanks! I'll give that a try. The slider scales have been a constant issue. I thought I would get used to them, but that never happened.

In the GEGL Gaussian blur, parameters are the std_dev along x and y, describing mathematically the Gaussian curve used as kernel. Though, I have to read the code to know where the infinite curve is clipped to have a "only-one-pixel" actual radius. Which is not obvious...

I'll have to look up what that means. Is there a simple approximate conversion to pixel radius?

Other than that, I don't really understand the "Masks" comment. You can see the actual mask by checking "Show the layer mask", but perhaps you want to see both the mask and the resulting image at the same time?

User error! "Show the layer mask works perfectly", exactly what I wanted right under my nose and I never noticed it. Gimp never ceases to amaze me. Thank you so much!

Hah, and the "computational explosion" with bad parameters is a known bug in a lot of GEGL operations, it may even make GIMP crash. It probably needs to be fixed in each operation individually, but this is not obvious... Perhaps we will need to make the "process" step of GeglOperations cancellable at some point? Unclear...

Good to know it's a known issue.

Also keep in mind that this is all "work in progress", Mitch once said that the ui infrastructure for GEGL Operations in GIMP is not done. And most of GEGL Operations still need some love.

It did seem like it might be a good time for feedback on various ui issues, yes? no?

On 12/03/2013 02:45 PM, Joao S. O. Bueno wrote:

Certainly it would be a lot better if while trying to click on the number to type in a new valuein the Gaussian Blur filter dialog in GIMP, you could not "accidentally" click on the bar bringnig the radius to 850, and having to wait several seconds until GIMP becomes responsive again.

"accidentally" is quoted, because it is actually very hard not to make that happen. I know the widgets are pretty - no one can deny that - but maybe, just letting the typeable values lie outside the range of the slider would be a nice-enough fix already.

You are right to quote "accidentally"! It's really easy to have that accident happen. I have plenty of RAM, but my processors are slow and my graphics card isn't up-to-date. So those little accidents are painful and it can take considerably longer than several seconds to recover.

When I'm experimenting to find just the right value, I find it easier to make small experimental changes with a slider than with a box for typing, if the slider is set up with an appropriate range. Not to say everyone would feel that way, of course.

The flip side is that just as soon as the slider range is made smaller, one wants a larger range. I remember using some application that allowed to change the scale of a slider easily and instantly. It was very convenient.

Elle

Teo Mazars
2013-12-03 21:14:08 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

In the GEGL Gaussian blur, parameters are the std_dev along x and y, describing mathematically the Gaussian curve used as kernel. Though, I have to read the code to know where the infinite curve is clipped to have a "only-one-pixel" actual radius. Which is not obvious...

I'll have to look up what that means. Is there a simple approximate conversion to pixel radius?

The function looks like that, sigma being std_dev_*, but double check to be sure. (and the "sigma ? : " is weird, I will fix that)

static gint fir_calc_convolve_matrix_length (gdouble sigma) {
return sigma ? ceil (sigma)*6.0+1.0 : 1; }

Also keep in mind that this is all "work in progress", Mitch once said that the ui infrastructure for GEGL Operations in GIMP is not done. And most of GEGL Operations still need some love.

It did seem like it might be a good time for feedback on various ui issues, yes? no?

I wish I didn't said that. Please, keep going reporting issues or anything you found, we deeply need that otherwise (as Daniel said) the "final version" will look exactly like the "under development". So thank you already for your help.

Téo

Elle Stone
2013-12-04 20:58:03 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 12/03/2013 02:10 PM, Teo Mazars wrote:

The way GEGL currently exposes each numerical parameters is as follow:

1) A nominal range, say [a, b], which represents the range where the operation is expected to work 2) An UI range, [a', b'] included in [a, b], representing the area of interest of the parameter. 3) An exponent, (like a gamma correction), to make the slider not behave linearly on the [a', b'] range.

Currently, GIMP's sliders "show" only [a', b'], but allows values in [a, b]. The exponent is the way GEGL handles the "mutli-scale" problem and it allows to have more precision on small value. Those values are all in GEGL, look for eg gegl_chant_double_ui in /operations/common/*.c

I will let others comment on what is the optimal UI range for those two operations. But changing [a', b'] would be really easy, and it should change the "unit" as well. I am not sure about making that range "user configurable", it makes sense imho.

In the GEGL Gaussian blur, parameters are the std_dev along x and y, describing mathematically the Gaussian curve used as kernel. Though, I have to read the code to know where the infinite curve is clipped to have a "only-one-pixel" actual radius. Which is not obvious...

I experimented a bit and settled on the following values:

In operations/common/gaussian-blur.c:

gegl_chant_double_ui (std_dev_x, _("Size X"), 0.0, 250.0, 4.0, 0.0, 100.0, 1.5, /* was: 0.0, 10000.0, 4.0, 0.0, 1000.0, 1.5, */ _("Standard deviation for the horizontal axis " "(multiply by ~2 to get radius)"))

gegl_chant_double_ui (std_dev_y, _("Size Y"), 0.0, 250.0, 4.0, 0.0, 100.0, 1.5, /* was: 0.0, 10000.0, 4.0, 0.0, 1000.0, 1.5, */ _("Standard deviation for the vertical axi. " "(multiply by ~2 to get radius)"))

This Gaussian blur slider range doesn't really allow slider selection of small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as the useful range for blur necessarily is large, and the larger the image, the larger the useful range.

In operations/common/unsharp-mask.c:

gegl_chant_double_ui (std_dev, _("Std. Dev."), 0.0, 10.0, 1.0, 0.0, 10.0, 1.5, /* was: 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _("Standard deviation (spatial scale factor)"))

gegl_chant_double_ui (scale, _("Scale"), 0.0, 10.0, 1.0, 0.0, 10.0, 1.5, /* was: 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _("Scale, strength of effect"))

These USM slider values work well for me. I don't need to type in "little more/little less" values as I can move the slider precisely enough to set a value within 0.01 of what I want.

The other gegl_chant_double_ui values are pretty obvious. What does the value "1.5" do?

A way to type in values without risking accidentally causing a very large radius operation would be very welcome. But the revised slider ranges make typing necessary a lot less often, for me anyway.

I wonder what values other people might find useful for Gaussian blur and USM? I have a 10MP camera. Someone with a 30 or 40MP camera probably would need a larger range, which is one reason why user-settable ranges might be a nice feature. Different styles of processing would be another.

Elle

Teo Mazars
2013-12-04 21:50:00 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

This Gaussian blur slider range doesn't really allow slider selection of
small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as
the useful range for blur necessarily is large, and the larger the image, the larger the useful range.

[...]

The other gegl_chant_double_ui values are pretty obvious. What does the
value "1.5" do?

The "1.5" is the UI exponent you were asking for in Gaussian Blur, 1.0 is linear. If 1.5 is not enough, you may try 2.0 or larger. For the slider step problem, I don't know much about that sorry... I think the new UI values you suggest are good. So please, try some more by tweaking the exponent and you can commit directly to GEGL master those changes, if you want.

A way to type in values without risking accidentally causing a very large radius operation would be very welcome.

Agreed, I am not sure how to solve that though...

I wonder what values other people might find useful for Gaussian blur and USM? I have a 10MP camera. Someone with a 30 or 40MP camera probably
would need a larger range, which is one reason why user-settable ranges
might be a nice feature. Different styles of processing would be another.

I agree too, but this is also an UI problem and I am really not an expert. A reasonable arbitrary UI range + exponent is already a step forward.

Thank you,

Téo

Joao S. O. Bueno
2013-12-04 22:27:09 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 4 December 2013 19:50, Teo Mazars wrote:

This Gaussian blur slider range doesn't really allow slider selection of
small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as
the useful range for blur necessarily is large, and the larger the image, the larger the useful range.

[...]

The other gegl_chant_double_ui values are pretty obvious. What does the
value "1.5" do?

The "1.5" is the UI exponent you were asking for in Gaussian Blur, 1.0 is linear. If 1.5 is not enough, you may try 2.0 or larger. For the slider step problem, I don't know much about that sorry... I think the new UI values you suggest are good. So please, try some more by tweaking the exponent and you can commit directly to GEGL master those changes, if you want.

A way to type in values without risking accidentally causing a very large radius operation would be very welcome.

Agreed, I am not sure how to solve that though...

I wonder what values other people might find useful for Gaussian blur and USM? I have a 10MP camera. Someone with a 30 or 40MP camera probably
would need a larger range, which is one reason why user-settable ranges
might be a nice feature. Different styles of processing would be another.

I agree too, but this is also an UI problem and I am really not an expert. A reasonable arbitrary UI range + exponent is already a step forward.

What if we can think of a way of hint up values for the UI, but not constrain the operator values themselves by these values - so that one could make a 2000-radius gaussian blur, if really needed? (despite any UI changes themselves to allow suitable ranges depending on the image size
for certain controls? - (brush radius and gaussian blur come to mind) )

Thank you,

Téo
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Elle Stone
2013-12-04 23:15:51 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 12/04/2013 05:27 PM, Joao S. O. Bueno wrote:

On 4 December 2013 19:50, Teo Mazars wrote:

This Gaussian blur slider range doesn't really allow slider selection of
small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as
the useful range for blur necessarily is large, and the larger the image, the larger the useful range.

[...]

The other gegl_chant_double_ui values are pretty obvious. What does the
value "1.5" do?

The "1.5" is the UI exponent you were asking for in Gaussian Blur, 1.0 is linear. If 1.5 is not enough, you may try 2.0 or larger. For the slider step problem, I don't know much about that sorry... I think the new UI values you suggest are good. So please, try some more by tweaking the exponent and you can commit directly to GEGL master those changes, if you want.

OK, that would explain why lowering that value to below 1 made the slider act strangely. I'll do some more experimenting and submit a patch. In the meantime, anyone have an idea of the largest GB and USM values they actually have used for image editing?

Elle Stone
2013-12-05 17:14:34 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

I spent some time experimenting with 2.8 vs 2.9 and also with various slider values for gaussian blur and USM.

Comparing 2.8 radius and 2.9 std.dev gaussian blurs:

I made a test image composed of varying width black and white stripes and checked varying blur values (radius in 2.8, std. dev in 2.9) to see what the 2.9 equivalent std.dev (sd) was for various 2.8 blur radius (r) values. I used "difference" blend mode to gage which 2.9 blur values correspond to which 2.8 blur values.

Here's the results:

2.8 2.9 ratio 1r 0.55sd 1.82
2r 0.8sd 2.50
5r 1.7sd 2.94
20r 6.2sd 3.23
40r 12sd 3.33
100r 31sd 3.23
200r 61sd 3.28

Extrapolating, perhaps a 500r 2.8 blur would take a 155sd 2.9 blur. The Gegl Gaussian blur popup says "multiply by ~2 to get radius", but it seems that for all but the smallest values, "multiply by ~3" is closer to the equivalent Gimp 2.8 gaussian blur. Has the definition of "radius" changed? Or something in the GB algorithm?

Do you think the different values and slider labels required to get the same amount of blur (1r vs 0.55sd, 5r vs 1.7sd, etc) might cause a great deal of consternation when Gimp 2.10 is released?

http://www.hackerfactor.com/blog/index.php?/archives/289-Blurring-The-Lines.html gives a nice comparison between Gimp (not from git), Photoshop, Corel Painter regarding the "unit" of blur, which apparently Photoshop uses the diameter and the other editors use the radius.

Very large gaussian blurs:

Quoting Wikipedia:

"Applying multiple, successive gaussian blurs to an image has the same effect as applying a single, larger gaussian blur, whose radius is the square root of the sum of the squares of the blur radii that were actually applied. For example, applying successive gaussian blurs with radii of 6 and 8 gives the same results as applying a single gaussian blur of radius 10."

So it's not too hard to hit whatever target gaussian blur one has in mind, either visually by repeated blurring or by calculating the right successive blur values to use.

As the gaussian blur radius/std.dev gets large compared to the actual size of the image, edge and corner values necessarily start to dominate the result of the blur. Does anyone have a use case for a 6000-radius or even 2000-radius blur?

Slider values:

After some experimentation, these values seem to work nicely. Both sets of ranges allow for reasonably precise setting of low values with the sliders. Both sets of slider settings require that the user figure out that there really is an extended scale. I raised that last ui parameter from 1.5 to 3.0, to make the extended scale not be too long.

Unsharp Mask:

gegl_chant_double_ui (std_dev, _("Std. Dev."), 0.2, 200.0, 0.55, 0.2, 10.0, 3.0, /* was 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _("Standard deviation (spatial scale factor)"))

gegl_chant_double_ui (scale, _("Scale"), 0.0, 200.0, 4.0, 0.0, 10.0, 3.0, /* was 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _("Scale, strength of effect"))

Comments: * These ranges allow for very precise setting of low values, critical for photographic images.
* On the std_dev slider there seems to be a dead spot below 0.2 on the slider, where no matter how high Scale is, nothing happens. So I set the minimum on the upper slider to 0.2.
* I set the defaults to a mild (obvious but not over the top) sharpening, one goal being to let the user know that the two sliders really are independent of each other. * Is there an interest in creating two presets, one a mild but obvious sharpening and the other a mild but obvious local contrast enhance, so that new users would have them available as drop-down choices? It seems to me that with the radical change in the slider values/meanings, a couple of provided defaults would help users figure out where to start.

Gaussian blur:

gegl_chant_double_ui (std_dev_x, _("Size X"), 0.0, 1500.0, 1.5, 0.0, 100.0, 3.0, /* was 0.0, 10000.0, 4.0, 0.0, 1000.0, 1.5, */ _("Standard deviation for the horizontal axis " "(multiply by ~2 to get radius)"))

gegl_chant_double_ui (std_dev_y, _("Size Y"), 0.0, 1500.0, 1.5, 0.0, 100.0, 3.0, /* was 0.0, 10000.0, 4.0, 0.0, 1000.0, 1.5, */ _("Standard deviation for the vertical axi. " "(multiply by ~2 to get radius)"))

Comments: * The Gegl Gaussian blur slider range is the equivalent of 0 to roughly 300px radius plus 0 to roughly 4500px radius for the extended scale. * I changed the default setting to be a visual match to the default Gimp 2.8 "5px blur" setting.
* There's a dead spot below around 0.4, below which blur value, nothing seems to happen.

I'll put a patch together later today (or probably tomorrow AM), if these values seem suitable.

A Gegl Gaussian blur bug?

There seems to be a bug in Gimp from git's Gegl Gaussian blur. It produces vertical streaks, noticeable at higher value blurs in larger images, very obvious at 155unit blur of a 2816x2112px image, less obvious when the image is scaled to 1408x1056px before blurring.

Elle

Elle Stone
2013-12-05 19:03:32 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

On 12/05/2013 12:14 PM, Elle Stone wrote:

I'll put a patch together later today (or probably tomorrow AM), if these values seem suitable.

The patch is attached. If I didn't make it correctly, let me know and I'll try again (still learning).

Teo Mazars
2013-12-05 19:08:16 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

Hi,

I have seen the comparison between the old (from gimp 2.8) and the new gaussian blur. I did not have a look at 2.8's implementation yet, but one of the main difference, is that the new implementation works in scRGB instead of sRGB in GIMP 2.8.

I don't know if you were aware about that. I personally would still let the possibility to make it work in both sRGB and scRGB, depending on user's need. Both behavior are useful. But it's still under discussion.

I completely forgot that until now, but Massimo worked on Gaussian-Blur some times ago, and his work is now in operations/workshop (you have to pass --enable-workshop to autogen to build them). This implementation should replace the current implementation at some point, but the behavior is equivalent to the current implementation. I mean all the work you did still applies on the new implementation. The main thing that prevents the replacement is that the case with std-dev < 0.5 is not implemented.

Among all improvements: Waaay faster, even with very large std-dev, it allows setting how edges are handled and finally it fixes the "vertical streaks" bug you were seeing with large std-dev.

I don't answer to the rest because I don't know or I did not though about it yet. Though, we will need to find the equivalent conversion between the 2.8 gblur and GEGL, because 2.10 keeps api compatibility with 2.8 and that includes that all filters should be have the same given the same set of input parameter from the api point of view (that is, not necesserly in the ui).

Regards,

Téo

Michael Henning
2013-12-06 01:03:33 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

As a quick correction, gegl's gaussian blur doesn't operate in scRGB, but rather in babl's linear premultiplied sRGB-primary space (RaGaBaA float).

babl doesn't really have scRGB formats, although some of the formats resemble some of the scRGB formats.

On Thu, Dec 5, 2013 at 2:08 PM, Teo Mazars wrote:

Hi,

I have seen the comparison between the old (from gimp 2.8) and the new gaussian blur. I did not have a look at 2.8's implementation yet, but one of the main difference, is that the new implementation works in scRGB instead of sRGB in GIMP 2.8.

I don't know if you were aware about that. I personally would still let the possibility to make it work in both sRGB and scRGB, depending on user's need. Both behavior are useful. But it's still under discussion.

I completely forgot that until now, but Massimo worked on Gaussian-Blur some times ago, and his work is now in operations/workshop (you have to pass --enable-workshop to autogen to build them). This implementation should replace the current implementation at some point, but the behavior is equivalent to the current implementation. I mean all the work you did still applies on the new implementation. The main thing that prevents the replacement is that the case with std-dev < 0.5 is not implemented.

Among all improvements: Waaay faster, even with very large std-dev, it allows setting how edges are handled and finally it fixes the "vertical streaks" bug you were seeing with large std-dev.

I don't answer to the rest because I don't know or I did not though about it yet. Though, we will need to find the equivalent conversion between the 2.8 gblur and GEGL, because 2.10 keeps api compatibility with 2.8 and that includes that all filters should be have the same given the same set of input parameter from the api point of view (that is, not necesserly in the ui).

Regards,

To _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Teo Mazars
2013-12-06 10:24:44 UTC (over 10 years ago)

Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

As a quick correction, gegl's gaussian blur doesn't operate in scRGB, but rather in babl's linear premultiplied sRGB-primary space (RaGaBaA float).

babl doesn't really have scRGB formats, although some of the formats resemble some of the scRGB formats.

Absolutly right, I often wrongly take that shortcut. Thanks for the correction.

Regards,

Téo