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

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

[Octave-bug-tracker] [bug #57500] [octave forge] (image) imrotate fails


From: Carnë Draug
Subject: [Octave-bug-tracker] [bug #57500] [octave forge] (image) imrotate fails in default branch
Date: Thu, 23 Jan 2020 09:00:13 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #2, bug #57500 (project octave):

Sorry, I missed this discussion. I only noticed the issue now and put the
valid argument back with http://hg.code.sf.net/p/octave/image/rev/04ab95ae4750
and linked to bug #55780 because that's where the patch that introduced the
bug came from.

I don't oppose the removal of the valid argument but we should go through a
phase of deprecation. We could see if at least anyone complains about it.

The easy workaround of specifying a extrapolation value is not that easy.  If
the image is of an integer type, then there's no NA or NaN that could be used
to distinguish valid elements.  This works inside imremap because it converts
the image to double before interpolation, but then it casts it back to integer
before returning to the user which will cause NA to be cast to zero.

Despite all this, looking at this again, this time with the extrapolation
value argument in mind, I see that this probably never worked properly. The
default extrapolation value is zero all over the place.  However, imremap uses
`isnan` independent of whatever extrapolation value. If this is correct, we
guess we can just remove all this and leave a comment on the NEWS that the
options were removed and probably never worked?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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