[Octave-bug-tracker] [bug #60322] [octave forge] (image) imresize bicubic interpolation inaccurate

[Hartmut]

Follow-up Comment #7, bug #60322 (project octave):

I have not tried to understand the algorithms and code to do the real
calculation here, because I think that Avinoam is already into this topic and
will probably continue with this.

Nevertheless I will comment on your discussion points from comment #6:

* testing a local function: I think it is OK to not explicitly test this local
function pad_indices in imremap at all. We do still test this local function
implicitly, when running the tests in imresize, is this true? I agree, that
this would probably not be worth the "mess" of a dedicated subdirectory as
with @strel. But if you still consider it useful to test this local function
explicitly in some way, you could simply ask on the Octave maintainers email
list, probably someone there will have a hint for you how to do this (or
confirm your suspicion that it's impossible): octave-maintainers@gnu.org

* change the demo to color images: I personally do not like this change. Demos
are not ment to be tests, they are more kind of educational to show what you
can do with a function. And doing interpolation of color images on the 3 color
channels seperatly is a bit wrong from the image processing aspect. So I would
rather not make this a showcase example, but rather stick with a demo using a
grayscale image, here.

* padding option: I think this is fine. Imremap is an Octave only function, so
there are no compatibility considerations involved. Addidtionally you only add
a feature, you do not remove one, so no long standing user of the image
package will be disturbed by this.

* The +-1 difference in output images of integer classes: I think this is fine
as well. It is hard to perfectly mimic thte Matlab outputs without actually
knowing their code. And your result has 100% the same quality, it is just not
100% compatible to their implementation. A side note: Yes, we are maybe
"better" in terms of accuracy with this implementation, but on the other hand
we do need more memory for this calculation on integer images, if it is really
true that Matlab does the full calculation in the integer domain. Below the
bottom line: Our compatibility would still improve a lot to what it currently
is.

Just an additional question: Are there now tests included for all the code
improvements you did? If you improved the code in aspect A, you should
afterwards add a test to check for this aspect A. Otherwise this improvement
might get lost after another person, who might not look out for this aspect A,
does the next code change to this function.

Thanks for this good code improvment! Let's see if Avinoam has more comments.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60322>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/