Sun 14 Dec 2014 10:06:52 PM UTC, original submission:
There might be a bug related to the use of anti-aliasing filter in the "imresize.m" function, whose code one can see at
http://sourceforge.net/p/octave/image/ci/Octave-Forge-2006.01.28/tree/imresize.m
Consider running this function with an image of size 32x32, i.e.
img_bigger = imresize(img, [64,64], 'cubic')
or
img_smaller = imresize(img, [16,16], 'cubic')
Here 'cubic' could be 'spline', but not 'nearest'.
The problem is with the "reverse logic of the algorithm". At line 85 we have:
if (m > 1 & filter > 0)
# If the image is being enlarged and filter > 0 then
# convolve the image with a filter*filter gaussian.
...
and at line 93:
elseif (m < 1 & nargin == 4)
# If the image size is being reduced and a fourth argument
# is given, use it as a FIR filter.
...
As we have 3 arguments and the method which is not "nearest", filter is set to 11, and hence the anti-aliasing filter will be applied (wrongly) when using imresize to enlarge an image. When imresize is applied to reduce the size of the original image, there will be no anti-aliasing filtering at all since nargin==3.
This seems to be wrong: the problem with aliasing is about representing a higher resolution image in a low-resolution domain.
We need antialiasing (low pass filter) BEFORE resampling with interp2 to lower resolution, and we do not need antialiasing when upsampling with interp2 to bigger than original resolutions.
The suggestion is to reverse "m>1" on line 85 to "m<1", and similarly on line 93. The suggested change is attached in the file imresizemod.m.
P.S. Optinal matters: Consider also switching from Gaussian smoothing to fir1 filter as is done in MATLAB (might not be important at all, but to be more consistent with MATLAB and more flexible), and also "mexing" interp2 as it is currently 5-10x slower than MATLAB's equivalent already on very tiny images such as when resizing from 28x28 to 32x32.
|