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

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

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

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?

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

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