[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #57500] [octave forge] (image) imrotate fails
[Octave-bug-tracker] [bug #57500] [octave forge] (image) imrotate fails in default branch
Thu, 2 Jan 2020 11:23:04 -0500 (EST)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
Follow-up Comment #1, bug #57500 (project octave):
I have looked into this a bit:
At first I did not like to abandon a nice Octave-only feature, as is this
"valid" output matrix of the imrotate function. But now I think this is the
price we need to pay to fix bug #55780 effectivly.
On the positive side of removing this feature I see:
* We get rid of some code duplication in the code, by now using the
interpolation method from core Octave in interp2 directly.
* There is an easy workaround for people who actually used this Octave-only
feature of the "valid" output in imrotate: Just use an extrapolation value of
NaN, and afterwards do something like valid = !isnan(im).
So as a conclusion, I would support Avinoam's proposal from comment #0. I.e.
remove this "valid" output feature.
Once we remove this feature we should definitly make a note in the NEWS file,
and maybe also mention the easy workaround sketched above.
My open question:
* Can we do this (removal of an Octave-only feature) right away, or should we
first deprecate it and warn users about this? (And remove this feature only in
the second next release? And marking the failing BIST in imrotate as known
failure for the meantime.) I personally tend to remove this feature straight
away, without any prior deprecation warning. I expect that not many people
actually use this feature. What do other people think of this? Carne?
Reply to this item at:
Message sent via Savannah
- [Octave-bug-tracker] [bug #57500] [octave forge] (image) imrotate fails in default branch,