quantitative image enlargement comparison: methods to test

[NicolasRobidoux]

My student Adam Turcotte will revise the image resizing test suite which we used in http://www.springerlink.com/content/640453037048p712/ and http://eprints.ecs.soton.ac.uk/18086/.
(The version used in the latter, unfortunately, had some bugs (mea culpa) and consequently most of the ImageMagick method numbers are wrong. Also, we foolishly included some filters which, really, are only meant to work well for EWA (Elliptical Weighted Averaging) methods.)

Re-enlargement tests are not without shortcomings, but this is what the test suite is about.

We are a bit short on time, so we are not aiming for "the perfect and definitive test suite." But we still want to make it as good as we can given the time constraints. Adam will use it in his Masters thesis.

Most of the tested methods will be taken from ImageMagick. We're aiming to test a total of about 30-60 methods.

The question: Which ones?

So, I'm looking for feedback regarding favorite methods for enlarging images.

Of course, I already have a list of "shoo-ins" based on my experience and interests. They are listed below. What I'm asking is: what else should I add.

To reiterate: The test suite is strictly about comparing the quality of resamplers for enlargement purpose. So, there is little point in including a method known to only be good for downsampling (unless it is to provide a baseline, or because it has my name . In addition, I'll have to read the fine print about the implementation of some of these methods, and make sure my syntax is flawless.

(The suite actually has a second purpose: Compare different image metrics, including l_infinity (a.k.a. max), l_1 (a.k.a average of absolute values), l_2 (a.k.a. RMS), SSIM and something which can best be described as L*a*b*.)

I make no claim at this point of knowing about everything IM can do. (I'll reread the documentation when I have a minute.)

convert resize -interpolate (orthogonal) methods:

• Point a.k.a. nearest neighbour
• Triangle a.k.a. bilinear
• Cubic (B-Spline smoothing)
• Mitchell a.k.a. Mitchell-Netravali bicubic
• Bicubic a.k.a. Lagrange degree 3
• CatRom a.k.a. Catmull-Rom bicubic
• Lanczos a.k.a. Lanczos 3-lobes
• Lanczos2 a.k.a. Lanczos 2-lobes
• Some or all of Sinc windowed with 'Blackman', 'Bohman', 'Hanning', 'Hammming', 'Kaiser', 'Welsh', 'Bartlett' (I don't think I want to do 'Parzen' which has, as only advantage, that it's cheap?) although we'll probably only keep those that perform well. The big question here is "how many lobes?" The IM standard appears to be 4, but I'm not sure this is the best choice. (We could also test Lanczos 4-lobes.)

convert distort -resize (Elliptical Weighted Averaging) methods:

• Lanczos2, Lanczos2Sharp, Lanczos3, Lanczos3Sharp (all Jinc-windowed Jinc) and the ones with blur parameters given in http://imagemagick.org/discourse-server ... =15#p76218
• triangle a.k.a. the teepee or cone
• possibly Robidoux (even though it is not a particularly good enlargement method: it's for downsampling, really) and Mitchell
• Quadratic (quadratic B-spline approximation of Gaussian? need to check) and Cubic (cubic ...)

Miscellaneous:

• -adaptive-resize (removed from list)

Non-IM methods:

• LBB (Locally Bounded Bicubic) from VIPS, which is visually inferior to Nohalo-LBB but I'd like to know how it fares quantitatively
• Nohalo-LBB from VIPS
• VSQBS (Vertex-Split Quadratic B-Spline smoothing) from VIPS
• EANBQH (Exact Area Natural BiQuadratic Histospline) and IBFNBQH (Interpolatory Box Filtered ..., basically (global) cubic spline interpolation) from the GIMP plug-in Upsize

I'd love to add the excellent iNEDI and NNEDI, but we may not have the time to set things up to test these non-IM methods.

None of the test images will have transparency.

What am I forgetting?

[anthony]

Adaptive-resize is actually just a resize using a hardcorded Mesh Interpolation (in IMv6), which is not available as a filter. and is ment for use with very very small image size changes.

However the IMv7 (alpha) version now have it using the current -interpolate setting, without even a fallback to Mesh if interpolate is not defined. As such it now defaults to bilinear interpolating instead of mesh when interpolate is not set by the user.

The operator was originally created in a fast response to a user request, but without discussion. It is was it would probably have been more like what is now in IMv7. As such in my view it is a miss-named operator. As I am currently working on IMv7 CLI interface, I need to decide whether to fix this (back to using Mesh), OR rename the operator to something like -interpolated-resize, which correctly described what the operator is now doing.

My preference is for the later, and rename the operator more appropriately, perhaps with the change and a depreciation warning for the old operator migrated back to IMv6.


I will make a copy of this and place it in 'Developers' for specific discussion.

[NicolasRobidoux]

(I can't find the copy in Developers.)

[anthony]

Adaptive Resize - and IMv7 CLI development.
viewtopic.php?f=2&t=19543