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

[Hartmut]

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

Yes, I think this valid output of imrotate never ever worked as expected:
* To find these in"valid" pixels, imremap searches for NaN values in its
"warped" variable.
* "warped" is generated by Octave's interp2 using the parameters "interp" and
"extrapval". In order to ever produce any NaN values, interp2 needs to get
extrapval=NaN as calling parameter.
* The extrapval parameter in imremap has a default value of 0. So it would
need to be explcitly set to NaN when imremap is called.
* imremap is called by imperspectivewarp. The the parameter
"extrapolation_value" in imperspectivewarp would need to be equal to NaN.
(It's default value is also zero here.)
* imrotate is calling imperspectivewarp. So it's parameter "extrapval" would
need to be NaN. (It's default value is also zero.)

So there seems to be only one way to get useful output of "valid" from
imrotate: You need to call imrotate with "extrapval=NaN".

The case Carne mentioned, where there is no easy workaround for a removed
valid output would be integer images (that do not have a NaN value). 

I was suspecting (as Carne did) that even in this case, the valid output would
not work. Because the etrapvalue of NaN would be of different class than the
uint class of the image, and somewhere this extrapvalue must be cast to the
class of the image when both number should go into the same final output
image.

That's why I tried the following (in image 2.10.0 without any of those
changes):


>> I = ones(5);
>> I = uint8(I)
I =

  1  1  1  1  1
  1  1  1  1  1
  1  1  1  1  1
  1  1  1  1  1
  1  1  1  1  1

>> [I2, ~, valid] = imrotate (I, 45, "nearest", "loose", NaN)
I2 =

  0  0  0  0  0  0  0
  0  0  0  1  0  0  0
  0  0  1  1  1  0  0
  0  1  1  1  1  1  0
  0  0  1  1  1  0  0
  0  0  0  1  0  0  0
  0  0  0  0  0  0  0

valid =

  1  1  1  1  1  1  1
  1  1  1  1  1  1  1
  1  1  1  1  1  1  1
  1  1  1  1  1  1  1
  1  1  1  1  1  1  1
  1  1  1  1  1  1  1
  1  1  1  1  1  1  1

>>


My conclusion is, that even in this only possible case, where the valid output
might have been useful, it obviously doesn't do anything. So there is and was
never ever was any useful output of this "valid" output variable in imrotate.

My suggestion: Let's right now REMOVE this valid output variable (as discussed
earlier in this bug report.) We could make a note in the NEWS file that we
removed a parameter that never worked before (as suggested by Carne in comment
#2).

What do you think?



    _______________________________________________________

Reply to this item at:

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

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