Trial of New Interpolation Methods

[anthony]

Tonight I'll be removing the new 'nearest...' interpolation methods. But then adding

Blend -- As NearestBlend above.
Background -- just return the background color (as a error check for EWA resampling)

Spots (if wanted) can be created using Distort Resize with Box filter and the support setting.

----------

Question -- Should Resize, also deal with bad resampling in the same way the Distort does? That is do a interpolative lookup?

At the moment resize switches to 'point' if support is less than 0.5 (without regard to what the user is requesting), or produce black, if you use a non-box filter to generate 'zero weights' (For example by using Gaussian)...

Code: Select all

  convert rose: -define filter:blur=0.01 -filter Gaussian \
          -resize 100x100  rose_black_bars.png

Note: This is nothing to do with the user specifically requesting a 'point' filter (a support=0 impulse filter) and have resize switch to a interpolative lookup, as distort does. That I regard as a separate question, one solved by a 'interpolative resize' operator (in IMv7 but not in IMv6 unless I backport).

[anthony]

Okay, I dropped the extra 'Nearest' methods. Here is the new methods, - except the first "Nearest' whcih is just a 'NearestNeighbor' so you can see the straight scaled version of the input image.
"NearestBlend', is now just 'Blend'



NOTE: the junk in the Montage labels is a bug! The label should be just -label '%c'
and it displays fine for anything but "montage". Reporting.

Also I dropped the 'Nearest' aspect of "Background', and was added for the checking for 'resampling errors.
For Example....

Code: Select all

    convert \( xc:red xc:blue +append \) \
            \( xc:yellow xc:cyan +append \) -append \
            -filter Box -define filter:support=0.3 \
            -interpolate Background -virtual-pixel Background \
            -background Gray    +distort SRT 30,0 \
            pixel_ip_background.png

[NicolasRobidoux]

Question -- Should Resize, also deal with bad resampling in the same way the Distort does? That is do a interpolative lookup?

At the moment resize switches to 'point' if support is less than 0.5 (without regard to what the user is requesting), or produce black, if you use a non-box filter to generate 'zero weights' (For example by using Gaussian)...

I think you are better placed than me to answer this.
My first thought is to let things break if people set a too small support somehow. Then they can learn something. Papering the problem over by silently switching to point or interpolative lookup is probably counter-productive (UX people: Time for you to complain!) although this probably keeps the clueless happy. (It may also cover up some of our programming/method shortcomings.)
My other suggestion would be that there be a final check for the window support, and that it be clamped up to a square with "radius" 1/2+epsilon for resize and an ellipse with semi-axes at least sqrt(2)/2+epsilon for EWA. So, there would be a hard limit to how small one can make the effective support. (This limit would not necessarily always make things safer, since in principle you could get negative or vanishing weights with some combinations, but it would prevent cases where we know ahead of time that it is most likely to break.)
But then I read this, and I really think that letting things break when a dangerous combination is used is OK. With control comes power, with power comes mistakes, with mistakes comes learning.
(Note sure I'm very helpful here.)

[NicolasRobidoux]

The following does look right to me, in terms of code/behavior.

For Example....

Code: Select all

    convert \( xc:red xc:blue +append \) \
            \( xc:yellow xc:cyan +append \) -append \
            -filter Box -define filter:support=0.3 \
            -interpolate Background -virtual-pixel Background \
            -background Gray    +distort SRT 30,0 \
            pixel_ip_background.png

[anthony]

The following does look right to me, in terms of code/behavior.

For Example....

Code: Select all

    convert \( xc:red xc:blue +append \) \
            \( xc:yellow xc:cyan +append \) -append \
            -filter Box -define filter:support=0.3 \
            -interpolate Background -virtual-pixel Background \
            -background Gray    +distort SRT 30,0 \
            pixel_ip_background.png

In what way? The ellipses (circles) have a support limit of 0.3 which is used with the Box filter. Naturally this means for some sampling points, we do not find a single pixel. Resampling Error, and it switches to a fast 'interpolate lookup'. That uses the new lookup 'Background' and that returns a fixed Gray color.

FYI. 0.3 support with a 30 scaling factor, means the 'spots' are 30x0.3 or 9 pixel radius.
Though it looks more like a 9.5 radius between pixel centers? Not certain why. I like it better that the current 'Disk Morphology' radius though, if I can figure out the logic.

In IM Examples, the Cylindrical Box filter expert note
http://www.imagemagick.org/Usage/resize ... terpolated
used the default interpolation of Bilinear, producing 'nearest pixel spot' circles, on a Bilinear interpolated color where resampling failed to find any pixel.

[whugemann]

Anthony,

you asked for my comment on it, so here it is (before I will be on holidays the next two weeks):
To me it looks like you are trying to press two different things in one argument for the operation, which are the form of the interpolation area and the mathematical operation that you want to apply. These should possibly be split into two.

Also I think that especially larger interpolation areas can not only be square, thus "average16" might not be a good choice of the wording, because it could be ambigeous. To me, something like "4x4" (or "4_4" if the "x" is problematic) would make more sense.

Considering the operation, I could think of something like "gaussian" in order to weight the nearer neighbours stronger than others. Averaging is fast, but to "levelling" for larger interpolation areas.

[anthony]

Note that before this trial Average was a average of the 16 nearest neighbours! i always thought it was just the nearest 4 which is what I have now set it to. It makes so much more sense as a interpolator.

Not certain I like "average4x4" or even "average_4x4" (which would probably work too) though really it is more of a 2-pass average4, or even 2-pass box with a support of 2.

Of all of them I still think average16 (as average of nearest 16) is still the most logical.

Do you think a hardcoded gaussian 0.5 (slight blur) interpolator would be a good addition? As a interpolator it does not reproduce the original pixel on exact pixel samples?

Also look at the other discussion...
BiCubic Interpolation does not match any known filter!
viewtopic.php?f=2&t=21118
ASIDE: it was eventually found to match a extreme, with a deep ring, cardinal (cubic factors b=0,c=1)
It has been proposed to replace this with a catrom (or THE keys cubic: b=0, c=1/2) while adding hermite and michell cubics too.
Also duplicate the 'Cubic' resampling filter as 'Spline' to match the 'spline' interpolator.


ASIDE: I ment to do this last weekend, but was stuck doing 'on call duty' for work with fence repairs inbetween, so I did nto get to it. I'll try tonight.