[OctDev] imrotate

[Justus P. <Jus...@UL...>]

Hi,

I've fixed the problems reported by Todd Neal, and added support for
rot90(). Note that for "crop" one has to do the cropping after the
rot90(). Moreover, if the image dimensions are not of equal parity
(odd width and even height, or vice versa), a +/- 90 degree rotation
entails interpolation. This implies that rot90() cannot be used for
such rotations.

The new code is designed to behave smoothly across small increments of
rotation angle, rot90 or not. The result should be exactly the same,
whether or not rot90 is used.

Please try out the code (Todd!) and tell me what you think. Once I
have Todd's approval, this code (imrotate.m and imrotate_Fourier.m)
should replace the existing version of imrotate in CVS.

There are two test functions, testimrotate and testrot90. Look at
their code and play with them. The other files are needed by these
two.


Paul Kienzle <pki...@us...> wrote on Thu, 10 Feb 2005
07:09:00 -0500:

> I'm disappointed that the current imrotate gives an incorrect result you
> showed in your example, and would like to see that addressed as well.

Just to clarify: The corners were off by half a pixel due to a
round-off error. This error is dramatic for small matrices, but barely
noticeable for anything that merits being called an "image".
Nevertheless, bug is bug... and is fixed.

> 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.


Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 09:24:03 -0600:

> I also modified the special cases so that it doesn't rely on rot90

Why? rot90 does exactly what's needed here. My code uses it happily.


Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 12:54:06 -0600:

> I am working on imresize and would be interested in seeing the
> bicubic interpolation code.

Here it is :-). The bicubic interpolation code is very general and
could be moved out of imrotate.m for use with imresize and
others. However, I don't think this is the right way to go; there are
more efficient algorithms for interpolation along parralel, regular
grids, e.g. Robert G. Keys, Cubic Convolution Interpolation for
Digital Image Processing, IEEE Trans. on Acoustics, Speech, and Signal
Processing 29(6) 1981, 1153-1160. If you want to do the community a
service, add such bicubic interpolation to interp2.m, and base
imresize() on that. You may also want to check out "help
rotate_scale".

Good luck!
Justus