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

[Christof Kaufmann]

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

Regarding the changed tests, there are several reasons.

I added some tests to make the suite more complete:
* nearest neighbor with x-scale 1 and y-scale 2
* bilinear scaling with gimp output for reference
* checkerboard

I replaced the nearest neighbor check, that used a reference matrix  to a more
general test. The new pixel centers are all lying in between 4 points,
similarly as shown in comment #4. So all neighbors have the same distance and
thus there is no unique _nearest_ neighbor. Hence I only checked that one of
the 4 neighbors is used in the output.

The tests for bilinear and bicubic interpolation with matlab reference outputs
were all failing. This is currently still the case for bicubic interpolation
(I like to look at that later). However, to avoid rounding of the output size,
I changed the input matrices from 7 x 10 to 8 x 10. This gives a 4 x 5 or a 12
x 15 matrix with scale factors 0.5 or 1.5, respectively. Because of the
changed input I had to redo the reference outputs (but I could also not
confirm all of the old Matlab results). Now the new bilinear interpolation
results in the same output as the one from Matlab (without anti-aliasing).

Let me explain the issue with the output size rounding with a tiny example:
Let in = [1 2 3];
When scaling with 0.5 and the output size should be 1 x 2, there are two
options:
0 Replace the input by in = [1 2 3 3]; which will result in the output out =
[1.5 3];
0 Replace the scaling by 0.666..., which will result in the output out = [1.25
2.75];

(Note, this does not run in octave currently, since interp2 needs at least a 2
x 2 matrix to work.)
Matlab goes for the first approach, while I chose the second. Also Gimp seems
to use the second. However, this might need some further discussion.
0 Replacing the input seemed odd to me at first glance. However, it preserves
the scale factor and gives accurate results for all pixels, that are not at
the right or bottom border. In the example above you can see this from the
first two values, which have been scaled down exactly to 1.5, which is what
you expect with a factor of 0.5.
0 Replacing the scale factor seemed better to me, since the output is accurate
for the new scaling. However, this might result in a different scaling for x
and y. This does clearly not preserve shapes. Also, the user might not notice
that  the scaling changed at all.

So, now I think the first approach is better, since it gives less surprises.
What do you think? If you agreed, I would like to change it. Are there any
restrictions here about how to do it? Should I make a new commit or rather try
to change the current one?

Regarding your question for the bicubic interpolation: Yes, the changed
interpolation points affect all methods. Hopefully in a good way.

Sorry for the length of this comment and thanks for the good discussion!

    _______________________________________________________

Reply to this item at:

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

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