Re: [OctDev] Re: imrotate

[Paul K. <pki...@us...>]

>
>>> For example, what happens if the angle is 269.999999?  Discretizing
>>> the angle before checking if it is 270 would be useful.
>>
>> I strongly disagree. rot90 should only be used for _exact_ multiples
>> of 90 degrees. If not, how do we choose the tolerance? If the image is
>> large enough, the result will be different. Let the user decide. The
>> user can discretize the angle before calling imrotate() if s/he wants
>> to.
>>
>
> I agree with Justus on this point, for a very large image a small
> angle change will result in a different rotated image.  However it may
> be possible to do something in the manner of this pseudocode:
>
> theta=89.99
> cornersTheta = compute the corners for 89.99;
> cornersNinety = compute the corners for 90.00
>
> if cornersTheta = cornersNinety
>     theta = 90;
> end;
>
>
> The speedup for the few cases where the angle is so close to a
> multiple of 90 and the image is small enough that it makes no
> difference may not be worth the expense of doing the checks to
> determine this.


The reason you don't want to check for multiples of 90 is that
floating point arithmetic is not exact.  For the sake of argument,
lets say that the rotation angle comes from acos(x) with x
approximately 0:

	> acos(eps)/pi*180-90
	ans =  -1.4211e-14

This is an angle which is almost but not quite 90.

For large matrices, the cost of testing the corners before choosing
the algorithm is trivial compared to the rotation.  For small
matrices, processing time will dominated by interpreter speed and
one or two extra lines amongst hundreds is again a small penalty.

Whether or not this optimization is worthwhile depends on how
frequently these near 90*n cases occur vs. speed gain from the
simple operations.  I'll leave that to the users of imrotate to
decide.

- Paul