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

Cubic Interpolation vs No Halo

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.

14 of 14 messages available
Toggle history

Please log in to manage your subscriptions.

Cubic Interpolation vs No Halo C R 27 Apr 08:03
  Cubic Interpolation vs No Halo Liam R. E. Quin 27 Apr 17:09
   Cubic Interpolation vs No Halo C R 28 Apr 06:58
   Cubic Interpolation vs No Halo Nicolas Robidoux 28 Apr 22:59
    Cubic Interpolation vs No Halo Liam R. E. Quin 28 Apr 23:34
     Cubic Interpolation vs No Halo C R 29 Apr 06:31
      Cubic Interpolation vs No Halo Nicolas Robidoux 02 May 20:24
  Cubic Interpolation vs No Halo Øyvind Kolås 07 May 13:38
   Cubic Interpolation vs No Halo C R 07 May 15:00
   Cubic Interpolation vs No Halo Karl Günter Wünsch 09 May 10:11
    Cubic Interpolation vs No Halo Øyvind Kolås 09 May 13:16
     Cubic Interpolation vs No Halo Akkana Peck 09 May 15:15
      Cubic Interpolation vs No Halo C R 14 May 12:21
    Cubic Interpolation vs No Halo Alexandre Prokoudine 09 May 14:47
C R
2016-04-27 08:03:15 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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.

It's just that I spend a lot of time lately switching to No halo for my professional work.

Thoughts?

-C

Liam R. E. Quin
2016-04-27 17:09:48 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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 
C R
2016-04-28 06:58:10 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

Thanks Liam. I suppose this will work okay for my purpose. Thanks for the tip.

-C
On 27 Apr 2016 6:09 pm, "Liam R. E. Quin" wrote:

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

Nicolas Robidoux
2016-04-28 22:59:11 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

Liam:

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

Nicolas

Liam R. E. Quin
2016-04-28 23:34:31 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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 
C R
2016-04-29 06:31:00 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

Are there plans to fix the cubic interpolation so it doesn't toss away quite so much resolution?
It seems to me it didn't do that quite so much before.

-C

On Fri, Apr 29, 2016 at 12:34 AM, Liam R. E. Quin wrote:

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

Nicolas Robidoux
2016-05-02 20:24:33 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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

Øyvind Kolås
2016-05-07 13:38:42 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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.

C R
2016-05-07 15:00:07 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

Awesome! Thanks. :) It will be great to get a decent result from cubic again.

-C

On Sat, May 7, 2016 at 2:38 PM, Øyvind Kolås wrote:

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.

Karl Günter Wünsch
2016-05-09 10:11:11 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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

Øyvind Kolås
2016-05-09 13:16:22 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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

Alexandre Prokoudine
2016-05-09 14:47:58 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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

Akkana Peck
2016-05-09 15:15:05 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

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

C R
2016-05-14 12:21:41 UTC (almost 8 years ago)

Cubic Interpolation vs No Halo

Cubic seems to be giving much better results now. Thanks again Øyvind! I no longer feel it necessary to always switch to NoHalo. Thankyou thankyou thankyou!

Much respect,
-C

On Mon, May 9, 2016 at 4:15 PM, Akkana Peck 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.

On Mon, May 9, 2016 at 12:11 PM, Karl Günter Wünsch 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 Kolås 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 _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list