Page 4 of 4
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T16:10:28-07:00
by Akira
fmw42 wrote: 2017-08-15T16:04:07-07:00
OK. That makes more sense. But for support 2=n, you should evaluate (2*n)^2 = 16 values (in one dimension?). But I got originally 202 values. Please clarify the correspondence.
In two demension. Spline2 (Spline16), Lanczos2, Bi-cubic are all 4x4. Spline3 (Spline36) and Lanczos3 are 6x6.
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T16:12:22-07:00
by magick
Akira, what is your preference? -define filter:lobes={2,3,4} or -define:support={2,3,4}?
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T16:16:03-07:00
by Akira
-define filter:lobes={2,3,4} should be righter if you use filter:lobes={2,3,4} for Lanczos2,3,4
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T16:20:06-07:00
by fmw42
Makes sense to me to use whatever notation is consistent with the current notation for lanczos for example.
Correct me if I am wrong, but Anthony uses lobes for the number of lobes and support for how many lobes the filter truncates it to.
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T16:59:08-07:00
by magick
IMv7 Beta is ready for testing. Use CubicSpline and define filter:lobes={2,3,4}.
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T17:38:12-07:00
by Akira
Makes sense to me to use whatever notation is consistent with the current notation for lanczos for example.
Correct me if I am wrong, but Anthony uses lobes for the number of lobes and support for how many lobes the filter truncates it to.
That's why I think filter:lobes is more appropriate than filter:support.
Support of Spline16,36,64 are 2, 3, 4 because the lobes of them are 2,3,4, so the filter doesn't truncate it within the lobe. If you use filter:suppor for selecting spline16/36/64, you can't use the custom filter support option for them.
http://svn.int64.org/viewvc/int64/resam ... rnels.html
Samples in 3.0-4.0 area in Spline64 almost don't affect the final result, so 4-lobed Spline (Spline64) and the support size of 3 might be effective for example.
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T17:48:16-07:00
by Akira
magick wrote: 2017-08-15T16:59:08-07:00
IMv7 Beta is ready for testing. Use CubicSpline and define filter:lobes={2,3,4}.
Thanks! It works beautifully!
This might be not a good test image. I can't tell any difference between Lanczos one and Spline36 one (or 16/64). Apparently, this NASA image just tries to tell us why we need to resize a picture in the linear light space.
https://visibleearth.nasa.gov/view.php?id=55167
https://eoimages.gsfc.nasa.gov/images/i ... _16384.tif
Spline36 - gamma space
Code: Select all
magick land_lights_16384.tif -filter CubicSpline -define filter:lobes=3 -resize 512 land_lights_spline36_gamma.png
Lanczos3 - gamma space
Code: Select all
magick land_lights_16384.tif -filter Lanczos -resize 512 land_lights_lanczos_gamma.png
Spline36 - linear space
Code: Select all
magick land_lights_16384.tif -colorspace RGB -filter CubicSpline -define filter:lobes=3 -resize 512 -colorspace sRGB land_lights_spline36_linear.png
Lanczos3 - linear space
Code: Select all
magick land_lights_16384.tif -colorspace RGB -filter Lanczos -resize 512 -colorspace sRGB land_lights_lanczos_linear.png

Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T18:01:36-07:00
by fmw42
Re: High tap count Spline filters? (Spline36/64/100/144/196/256)
Posted: 2017-08-15T18:55:44-07:00
by Akira
fmw42 wrote: 2017-08-15T18:01:36-07:00
Code: Select all
magick compare -metric rmse logo128_lanczos.png logo128_spline16.png -format "\n" null:
1711.18 (0.0261109)
magick compare -metric rmse logo128_lanczos.png logo128_spline36.png -format "\n" null:
562.698 (0.00858621)
magick compare -metric rmse logo128_lanczos.png logo128_spline64.png -format "\n" null:
628.19 (0.00958556)
magick compare -metric rmse logo128_catrom.png logo128_spline16.png -format "\n" null:
609.158 (0.00929516)
magick compare -metric rmse logo128_catrom.png logo128_spline36.png -format "\n" null:
1541.94 (0.0235285)
magick compare -metric rmse logo128_catrom.png logo128_spline64.png -format "\n" null:
1686.94 (0.025741)
SSIM indexes:
Code: Select all
ffmpeg -i logo128_lanczos.png -i logo128_spline16.png -filter_complex ssim -an -f null -
SSIM R:0.946036 (12.678943) G:0.957871 (13.754209) B:0.970681 (15.328484) All:0.958196 (13.787820)
ffmpeg -i logo128_lanczos.png -logo128_spline36.png -filter_complex ssim -an -f null -
SSIM R:0.994943 (22.961192) G:0.995593 (23.558111) B:0.997249 (25.605576) All:0.995928 (23.902356)
ffmpeg -i logo128_lanczos.png -i logo128_spline64.png -filter_complex ssim -an -f null -
SSIM R:0.989257 (19.688591) G:0.991401 (20.655318) B:0.995461 (23.430614) All:0.992040 (20.990597)
I think evaluating different algorithms by RMSE, PSNR or SSIM is not a good idea, but SSIM index of around 0.992 to 0.995 is what you usually get when you compare an original PNG and a [Quality=95 YUV444] JPEG.