octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #43823] Potential bug in imresize.m in Image t


From: anonymous
Subject: [Octave-bug-tracker] [bug #43823] Potential bug in imresize.m in Image toolbox
Date: Sun, 14 Dec 2014 22:06:53 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/38.0.2125.111 Chrome/38.0.2125.111 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?43823>

                 Summary: Potential bug in imresize.m in Image toolbox
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Sun 14 Dec 2014 10:06:52 PM UTC
                Category: Libraries
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Inaccurate Result
                  Status: None
             Assigned to: None
         Originator Name: John Smith
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.8.1
        Operating System: Any

    _______________________________________________________

Details:

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. 



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sun 14 Dec 2014 10:06:52 PM UTC  Name: imresizemod.m  Size: 4kB   By:
None
Please verify imresize.m code logic and consider the suggested change.
<http://savannah.gnu.org/bugs/download.php?file_id=32666>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43823>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]