High tap count Spline filters? (Spline36/64/100/144/196/256)

[fmw42]

I have tested the following enlarging tests in IM 7.0.6.8beta and visually see no difference. A compare does show minor differences of the order of about 0.9% or less with respect to lanczos and with respect to catrom. But I cannot tell if the spline filters are better or worse.

Code: Select all

magick logo128.png -filter spline16 -resize 400% logo128_spline16.png
magick logo128.png -filter spline36 -resize 400% logo128_spline36.png
imagick logo128.png -filter spline64 -resize 400% logo128_spline64.png
magick logo128.png -filter lanczos -resize 400% logo128_lanczos.png
magick logo128.png -filter catrom -resize 400% logo128_catrom.png

Code: Select all

magick compare -metric rmse logo128_lanczos.png logo128_spline16.png null:
611.226 (0.00932671)

magick compare -metric rmse logo128_lanczos.png logo128_spline36.png null:
225.147 (0.00343553)

magick compare -metric rmse logo128_lanczos.png logo128_spline64.png null:
611.226 (0.00932671)

Code: Select all

magick compare -metric rmse logo128_catrom.png logo128_spline16.png null:
289.134 (0.0044119)

magick compare -metric rmse logo128_catrom.png logo128_spline36.png null:
606.479 (0.00925428)

magick compare -metric rmse logo128_catrom.png logo128_spline64.png null:
289.134 (0.0044119)

Same issue with spline16 and spline64 giving equal results.

[fmw42]

It looks like spine64 is calling spline16. The verbose data is identical. Here is the top part of each

im7beta magick logo128.png -define filter:verbose=true -filter spline16 -resize 400% logo128_spline16.png

# Resampling Filter (for graphing)
#
# filter = Spline16
# window = Box
# support = 2
# window-support = 2
# scale-blur = 1
# practical-support = 2


im7beta magick logo128.png -define filter:verbose=true -filter spline64 -resize 400% logo128_spline64.png

# Resampling Filter (for graphing)
#
# filter = Spline16
# window = Box
# support = 2
# window-support = 2
# scale-blur = 1
# practical-support = 2

So there is a bug.

P.S. spline36 is showing up properly in the verbose info as Spline36 and different values.

[Akira]

"-filter Spline -define filter:lobes=n" might be a cleaner solution, rather than having Spline16, Spline36, and Spline64 individually...?
Though, IM already has Spline filter (I guess B-Spline), so it might be little confusing...

lobes:
1: Spline4 - Identical to Triangle/Bi-linear
2: Spline16
3: Spline36
4: Spline64
(and if you add high lobed ones)
5: Spline100
6: Spline144
7: Spline196
8: Spline256

[fmw42]

magick is asking if you can check the values he is showing for the verbose information to see if they are correct. Wait until he fixes the spline64=splne16 values. Or look in the code and see if he has implemented the formulae properly against your code reference.

[magick]

Defines are considered expert options. Mnemonics are typically easier to grok by newbies.

The latest Beta is ready for testing with a fix for Spline64.

We did not see a need to add support for Spline 100-256. If you feel differently, let us know.

[fmw42]

Defines are considered expert options. Mnemonics are typically a better choice for newbies.

The latest Beta is ready for testing with a fix for Spline64.

We did not see a need to add support for Spline 100-256. If you feel differently, let us know.

One compromise would be -splineX or -splineN (or -spline-lobes) and a -define splineN:lobes=N

That would avoid having too many spline named filters if you implement the higher number of lobes versions and avoid confusion with the current spline

But I do not object to the current method.

I am downloading the new beta now and will present results shortly.

[fmw42]

Redoing the minimizing (after checking that spline64 and now different from spline16), I get

Code: Select all

magick logo: -filter spline16 -resize 150x logo_spline16.png
magick logo: -filter spline36 -resize 150x logo_spline36.png
magick logo: -filter spline64 -resize 150x logo_spline64.png
magick logo: -filter lanczos -resize 150x logo_lanczos.png

Code: Select all

magick compare -metric rmse logo_lanczos.png logo_spline16.png null:
524.952 (0.00801025)

magick compare -metric rmse logo_lanczos.png logo_spline36.png null:
162.101 (0.0024735)

magick compare -metric rmse logo_lanczos.png logo_spline64.png null:
139.788 (0.00213303)

Results of the higher lobes spline seem to be converging on lanczos.

[Akira]

magick is asking if you can check the values he is showing for the verbose information to see if they are correct. Wait until he fixes the spline64=splne16 values. Or look in the code and see if he has implemented the formulae properly against your code reference.

Checked resize.c and it should be ok. Thanks!

We did not see a need to add support for Spline 100-256. If you feel differently, let us know.

No, I don't need 100-256, honestly.

[fmw42]

Redoing the enlarging but not an integer factor this time, I get

Code: Select all

magick logo128.png -filter spline16 -resize 375% logo128_spline16.png
magick logo128.png -filter spline36 -resize 375% logo128_spline36.png
magick logo128.png -filter spline64 -resize 375% logo128_spline64.png
magick logo128.png -filter lanczos -resize 375% logo128_lanczos.png
magick logo128.png -filter catrom -resize 375% logo128_catrom.png

Code: Select all

magick compare -metric rmse logo128_lanczos.png logo128_spline16.png null:
608.706 (0.00928826)

magick compare -metric rmse logo128_lanczos.png logo128_spline36.png null:
224.736 (0.00342925)

magick compare -metric rmse logo128_lanczos.png logo128_spline64.png null:
242.297 (0.00369721)

Note that spline64 is not as close to lanczos as spline36. Same for the comparison with catrom below.

Code: Select all

magick compare -metric rmse logo128_catrom.png logo128_spline16.png null:
284.971 (0.00434838)

magick compare -metric rmse logo128_catrom.png logo128_spline36.png null:
603.113 (0.00920292)

magick compare -metric rmse logo128_catrom.png logo128_spline64.png null:
624.169 (0.00952421)

[magick]

In 2,000 seconds, download the latest beta and try this command:

Code: Select all

magick logo128.png -define filter:lobes=3 -filter spline-lobes -resize 400% logo128_spline64.png

Is SplineTap a better choice?

Note, we are willing to support higher lobes counts if someone volunteers the C source. Here's an example for 2-lobe

Code: Select all

 if (resize_filter->support <= 2.0)
    {
      /*
        2-lobe Spline filter.
      */
      if (x < 1.0)
        return(((x-9.0/5.0)*x-1.0/5.0)*x+1.0);
      if (x < 2.0)
        return(((-1.0/3.0*(x-1.0)+4.0/5.0)*(x-1.0)-7.0/15.0)*(x-1.0));
      return(0.0);
    }

[fmw42]

Is SplineTap a better choice?

I am not the expert on this. I am not sure taps is the same as lobes. So I think lobes is a safer term. You could use splineLobes, but it seems that most of the methods have hyphens, when needed. So I suspect it would be more consistently named a the hyphen.

Perhaps the OP can comment on the difference between taps and lobes?

[magick]

Hyphens are a convenience. You can also use SplineLobes.

[fmw42]

Other possible names might be: -extended-spline or -long-spline or -wide-spline.

This reference seems to imply the taps is the number of filter values and lobes is the number side peaks. I have not had time to read it that thoroughly. http://avisynth.nl/index.php/Lanczos_lobs/taps

spline16 has 202 values. So I guess that is taps. I cannot tell exactly from the numbers how many lobes, but I assume it is 16.

Code: Select all

But I would like to hear back from the OP on naming convention and difference between lobes and taps.

Is this really a spline or a sinc filter or some other tapered sine funtions

[Akira]

I'm so sorry for the late reply. It took me time to install Xcode and stuff for building the beta (I reinstalled Mac OS last weekend).

Tried the latest beta build in the linear light space (thank you very much for adding the filters).

Code: Select all

magick logo128.png -colorspace RGB -filter Spline16 -resize 400% -colorspace sRGB logo128_spline16.png
magick logo128.png -colorspace RGB -filter Spline36 -resize 400% -colorspace sRGB logo128_spline36.png
magick logo128.png -colorspace RGB -filter Spline64 -resize 400% -colorspace sRGB logo128_spline64.png
magick logo128.png -colorspace RGB -filter Lanczos -resize 400% -colorspace sRGB logo128_lanczos.png

Resizing in the linear space sometimes emphasizes the difference between different filters. Some people may think differently, but I believe that resizing in the linear light space is righter than doing it in the gamma space.
http://www.synth.in/2016/07/your-scalin ... sucks.html (this is not my page)
"Your scaling software sucks" PNG in this page isn't that important. The import thing is NASA's image.

Anyway, here are the original image and the result I got:


Spline16


Spline36


Spline64


Lanczos (default 3-lobed)


The difference is subtle. You can't see the difference if you compare them side by side. I usually do "flip" method to compare two images or more. It's better to put a GIF than explaining it in words (Note that this isn't not a fair comparison because it's 2-lobed Spline vs 3-lobed Lanczos just for explaining my method, but you can see the difference between 3-Lobed spline (spline36) vs Lanczos3 with this method):

Is this really a spline or a sinc filter or some other tapered sine funtions

Yes, this is the real spline filter, and if you ask me, I still think that "-filter Spline -define filter:lobes=n" is the right naming & scheme, but it's confusing as IM already has a Spline filter (I'm not 100% sure about this, but the current spline filter in IM is B-Spline), so I think Spline16/36/64 or SplineLobes is better (than SplineTaps). I don't think Spline is superior to Lanczos, but having more options is cool...

[fmw42]

We probably cannot change the name of the existing B-spline filter (spline), unfortunately since it would break existing code that people might have developed for it. So we will have to go with either spline16/spline36/spline64 or splinelobes, unless you can think of a better name for the latter. Which do you want -- just the 3 names or one name with -define filter:lobes:16/36/64. If we are only going to implement these 3, then it would be simpler to just keep the 3 separate names, spline16, spline36, spline54.

One other possibility is cubicspline.

You are right, the more proper method is to work in linear RGB.

Can you provide tests against the "NASA" image you mentioned?

Do think higher orders are necessary or make that much more difference?