I had a look into what happens in imremap.m that makes imrotate with bicubic interpolation so slow, now. The profiler shows, that most of the computing time is spent in the function intpolcub in bicubic_conv in inremap.m. Most of the time there is due to the two functions cubic12 and cubic01. And these functions eventually spend most of their time with simple arithmetic calculations: plus, minus, power of n, times, all with matrices of the size of the image.

My conculsion now is: It is not easy to speed this up. There seem to be two ways to do this:

• Find a clever way to do the same calculation in m-code as now, but using existing functions in core Octave (like corr2) that also calculate correlation and convolution. Those functions will probably do the job faster, because their inner part does the calculation in compiled C code. (But I am not sure if there is a equivalent formulation of the same calculation that uses those core functions.)
• Rewrite the caculation bit of this code path in a compiled Octave C file.

I made a simple patch (as full file and as diff) for imremap, that uses "single" for 8 and 16 bit integer (and also for "single") images. It just does not make sense to convert these to double. I have not checked it very thoroughly, since imremap is lacking tests, but the patch is quite simple. It should improve the performance quite a bit:

I = uint16 (checkerboard (1000) * 65535);
tic;
J = imrotate(I,36,'bicubic','crop',1);
t=toc

• before: 63.032
• with patch: 44.580

But also some of the other methods are faster:

I = uint16 (checkerboard (1000) * 65535);
tic;
J = imrotate(I,36,'pchip','crop',1);
t=toc

• before: 38.220
• with patch: 28.364

Although especially pchip would be faster for multi-channel images, if interp2 supported them.
For "linear" there seems to be no speed-up.

(file #52748, file #52749)

Yes, that's really what I ment. I tried to use the same Octave version, to proof that the execution time increase is really due to our octave package version, and not due to the core Octave version. And the latest Octave (7.0.90) is currently not able to install image 2.12.0, that's why I used Octave 6.3.0 instead.

But in the octave code in comment #0 is a little typo. I ment to re-rotate the image incrementally, i.e. I = imrotate(I, ...). But the given run times in comment #0 are still correct for the given test code. So the given test code is non-sense from the image processing stand point, but it is good enough to show the drop in execution speed, let's just keep it as it is.

I have observed the following: When you run this little script, that rotates an image several times with imrotate:

pkg load image
I = checkerboard(120);
tic;
for n=1:10
  J = imrotate(I,36,'bicubic','crop',1);
end
t=toc

Then the execution speed is significantly increased in current dev image (what should become image-2.14.0), compared to the current image release 2.12.0. I have observed this on windows and linux, and I have observed this under serveral versions of core Octave (6.3.0 and 7.0.90).

Example:

• Octave 6.3.0 (linux) and image-2.14.0 -> 6s
• Octave 6.3.0 (linux) and image-2.12.0 -> 3s

The other interpolation methods (nearest or bilinear) are not affected by this speed increase.

Is this a "speed regression" introduced by the recent code changes regarding bicubic interpolation? Can we improve this, back to (more or less) the old speed?