[Octave-bug-tracker] [bug #51769] [octave forge] (image) imresize bilinear interpolation inaccurate

[Christof Kaufmann]

Follow-up Comment #4, bug #51769 (project octave):

This problem is not mainly handling Matlab incompatibility. The approach was
just not correct. Raster graphics have pixels and pixels represent the mean
color (or value) of an area. They are *not* samples of infinitesimal small
points. This is what I changed.

The image should cover the same area before and after scaling. A pixel has a
width and height of 1 unit. This means the first pixel starts at (0.5, 0.5),
has its center at (1, 1) and ends at (1.5, 1.5). The last pixel starts at
(end-0.5, end-0.5), has its center at (end, end) and ends at (end+0.5,
end+0.5). So the whole image starts at (0.5, 0.5) and ends at (end+0.5,
end+0.5). The scaled image has to cover the same area, but with a different
resolution. In the example of my first comment I scaled the image down by
using a factor of 0.5. This means in the system of the original resolution the
pixels have now a size of 2 units. So the new first pixel will start at (0.5,
0.5), have its center at (1.5, 1.5) and end at (2.5, 2.5) and so on.

>From this you can see that the checkerboard in the example should give the
mean value, since the new pixel centers (marked with an X) are exactly in the
middle of 4 pixel groups:

+-------+-------+
| 0   1 | 0  0.7|
|   X   |   X   |
| 1   0 |0.7  0 |
+-------+-------+
| 0   1 | 0  0.7|
|   X   |   X   |
| 1   0 |0.7  0 |
+-------+-------+


Matlab shows this behavior in this example, but when a rounding  occured in
the new image size, it would not adjust the scale factor. I handled rounding
errors in the commit. So I was not trying to be 100% compatible, but rather to
do it correct.

To answer you question: With the old behavior all positions were a bit off,
since the first pixel center has always been at 1 and the last at end. The
pixel centers in between were linearly spread. So for the checkerboard it just
selected the 4 corner pixels.


    _______________________________________________________

Reply to this item at:

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

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