On Wed, 2016-04-27 at 09:03 +0100, C R wrote:

I assume the reasoning behind using cubic as the default for all the scale
and transform tools is to cut back on the complaints of how slow GIMP is at
the moment, but the quality loss in the current cubic interpolation algorithm is quite bad.

It depends on what you're doing - in some cases Cubic gives better results. In addition nohalo and lohalo can take several minutes to scale an image.

You can change the default tool option in preferences/tool options.

Also, it's probably safe to assume that if the user chooses an interpolation type in the tool, they are saying something about the quality of the results they are after vs speed. I think setting the value in one tool should set the value automatically in other tools, and treat it as a "global" value of sorts.

I'd rather see it moved out of tool options and into preferences with a single setting in that case. In practice I fairly often copy a small section of an image and experiment with a cobination of blur and different downsizing algorithms. In addition, more upscaling options would be good, maybe after 2.10 - waifu2x, if unencumbered, would be a good candidate. So I think having the algorithm choice right there in scale image makes experimentation easier, and helps people dscover the option.

So maybe a preference to say the default would be good. And hey! there is one :-)

Liam

Liam R. E. Quin 

Liam:

Do you ever find LoHalo (snail crawling notwithstanding) worthwhile?

Nicolas

On Fri, 2016-04-29 at 00:59 +0200, Nicolas Robidoux wrote:

Liam:

Do you ever find LoHalo (snail crawling notwithstanding) worthwhile?

Yes, but because it's so slow I use it less than once a month.

It feels like it takes half an hour or so, but I suspect it's probably more like 10 minutes.

Most often I'm working with scanned engravings that have lots of almost-parallel almost-horizontal lines, and the trouble is moiré-like patterns that creep in. A gaussian blur before down-scaling, followed by a sharpen, usually helps. We lost the old gimp 2.6 sharpen filter, but the newer unsharp filter works.

Sometimes lohalo scales down without introducing the problems.

Liam

Liam R. E. Quin 

I suspect that it would make very little difference when downsampling, but maybe sigmoidization, as used in LoHalo, is not worth the computational cost.

Very easy to modify the code:

Remove the extended_sigmoidal and inverse_sigmoidal function definitions, and then replace these strings (which trigger the function calls) by nothing throughout
https://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-sampler-lohalo.c

I also wonder if the nested ifs in the downsampling component should be replaced by non-nested branches (that contain the previous tests, but are not nested).

On Wed, Apr 27, 2016 at 10:03 AM, C R wrote:

I assume the reasoning behind using cubic as the default for all the scale and transform tools is to cut back on the complaints of how slow GIMP is at the moment, but the quality loss in the current cubic interpolation algorithm is quite bad.

Can we shift the default to No Halo or Lo Halo? Also, it's probably safe to assume that if the user chooses an interpolation type in the tool, they are saying something about the quality of the results they are after vs speed. I think setting the value in one tool should set the value automatically in other tools, and treat it as a "global" value of sorts.

I've pushed code to GEGL master that makes the resamplers called "linear" and "cubic" do a tiny bit more than just interpolation. These operations now do a (possibly sparse) box-filtering when scaling down instead of scaling up. Doing point sampling with interpolated values is probably not what a user expect "cubic" or "linear" scaling down to be anyways,. even if this is what it currently is. GEGL now does a 2x2 averaging of values for bilinear and a 4x4 sparse box filter averaging for cubic. Due to how this code uses whole pixels for averaging it might yield slightly sharper result than nohalo in many cases.

On 07/05/16 15:38, yvind Kols wrote:

I've pushed code to GEGL master that makes the resamplers called "linear" and "cubic" do a tiny bit more than just interpolation.

The more you change the default behavior of existing filters the more it makes the use of GIMP impossible in a setup where you build up a workflow... It's bad enough to outright drop the previously available scaling algorithm but to tinker and thus in some cases invalidate existing workflows without the user being made aware of it is ridiculous for a tool like the GIMP...

I would ask you to reinstate the old code and have the new selectable under a new name - then at least an existing workflow could remain intact and the user would be made aware (a little bit at least) that there may be something better available...

regards Karl Gnter Wnsch

On Mon, May 9, 2016 at 12:11 PM, Karl Günter Wünsch wrote:

On 07/05/16 15:38, Øyvind Kolås wrote:

I've pushed code to GEGL master that makes the resamplers called "linear" and "cubic" do a tiny bit more than just interpolation.

The more you change the default behavior of existing filters the more it makes the use of GIMP impossible in a setup where you build up a workflow... It's bad enough to outright drop the previously available scaling algorithm but to tinker and thus in some cases invalidate existing workflows without the user being made aware of it is ridiculous for a tool like the GIMP...

This was a fix for the 2.9 series - any releases of 2.9 thus far have been development snapshots and you shouldn't be establishing unchangable workflows based on the behavior of development snapshots. The new behavior you will get from cubic and linear *resamplers* in GIMP master + GEGL master resembles what the stable releases of GIMP have been doing for at least the last half decade, whereas GIMP 2.9 for a while has produced the equivalent of slightly randomized nearest neighbor when scaling down with cubic and linear. Other things that might happen for 2.10 is lanczos being reinstated if *you (or someone you convince)* implement lanczos as a GeglSampler, and the nohalo sampler being dropped unless it starts having performance of similar magnitude to nearest/linear/cubic/lohalo.

I would ask you to reinstate the old code and have the new selectable under a new name - then at least an existing workflow could remain intact and the user would be made aware (a little bit at least) that there may be something better available...

Nope - won't happen. Linear and cubic resamplers should provide reasonable results - instead of a random broken thing, which is why I also implemented similar fixes to GIMP itself early in the 2.x series. If you've been blurring your photos before scaling them down with cubic to compensate for cubic being broken in 2.9, you should no longer be doing so.

/pippin

On Mon, May 9, 2016 at 1:11 PM, Karl Günter Wünsch wrote:

I would ask you to reinstate the old code and have the new selectable under a new name - then at least an existing workflow could remain intact and the user would be made aware (a little bit at least) that there may be something better available...

I would ask you to begin with carefully evaluating the impact of the changes by testing a newer build of GIMP, *then* posting to this mailing list on the subject. That way we would be sure that whatever your claim is, it is based on having hands-on experience with what you talk about. Thank you.

Alex

On 07/05/16 15:38, yvind Kols wrote:

I've pushed code to GEGL master that makes the resamplers called "linear" and "cubic" do a tiny bit more than just interpolation.

On Mon, May 9, 2016 at 12:11 PM, Karl Gnter Wnsch wrote:

The more you change the default behavior of existing filters the more it makes the use of GIMP impossible in a setup where you build up a workflow... It's bad enough to outright drop the previously available scaling algorithm but to tinker and thus in some cases invalidate existing workflows without the user being made aware of it is ridiculous for a tool like the GIMP...

yvind Kols writes:

This was a fix for the 2.9 series - any releases of 2.9 thus far have been development snapshots and you shouldn't be establishing unchangable workflows based on the behavior of development snapshots.

As someone who down-scales a lot (and who expects workflow and defaults to change now and then when using development releases), I want to thank yvind for the new code. Downscaling with Cubic looks much better now (compared to the previous 2.9 behavior), and is much faster than LoHalo/NoHalo. Good stuff!

...Akkana