Steve on Image Processing and MATLAB

Concepts, algorithms & MATLAB

R2010b – Image Processing Toolbox performance improvements 13

Posted by Steve Eddins,

MathWorks shipped release R2010b last month. Today I want to mention several performance improvements made in the Image Processing Toolbox.

First, imresize received more love and attention in this release. Several benchmark imresize problems are plotted together below. The y-axis is "relative speed." That means that each line on the plot is normalized by the slowest recorded speed for the corresponding benchmark. MATLAB releases are plotted on the x-axis. R8 on the left is MATLAB 5 back in early 1997. "10b" on the right is short for R2010b.

All of the benchmark curves have gone up several times in the last few years. If you look closely you can see that speed improvements were made in R2007a, R2007b, R2010a, and again in the just-released R2010b.

The function iradon has also been improved in both the last two releases, at least for the 'linear' and 'nearest' interpolation options.

Finally, the relatively new function blockproc had a fairly high amount of overhead in it when it was first released. That overhead has now been optimized away. The benchmark problem, shown in the plot's legend below, just leaves each block unchanged. That way we are only measuring the speed of blockproc and not the speed of the user-defined function applied by blockproc.

I will discuss other aspects of R2010b soon. I'll focus on things that particularly interest me. Be sure to check out the other MATLAB Central bloggers to see what they have to say about the release.

Get the MATLAB code

Published with MATLAB® 7.11


Comments are closed.

13 CommentsOldest to Newest

Siddharth replied on : 1 of 13
That's a significant improvement in the performance of blockproc. I use this function a lot. Can't wait to see how the R2010b version performs for my analysis. Also, are there any plans to make blockproc work on distributed/co-distributed arrays ? (And, is there is a way to suppress the messages written to the command window when running with -nodisplay or in the context of a matlabpool ?) Thanks !
Yasin Abbas replied on : 2 of 13
I had no idea blockproc existed... :) Is there a way to use this to do quick image correlation, block by block? [specifically - fast Strain mapping] All the examples show a function acting on the same image.
Siddharth replied on : 5 of 13
I am referring to the messages produced by blockproc and displayed on the progressbar when runing in a normal windowed environment. When I run the same blockproc call in a matlabpool (or in headless MATLAB), these same messages get printed to the MATLAB command line. This just clutters the output and makes it a little harder to debug the in case of problems. (Note that I have not yet had a chance to run blockproc in R2010b, so if the behavior has changed, please disregard my post)
BjornG replied on : 7 of 13
Quick follow-up question to Yasin's question... I tried to do (what I guess Yasin wanted) with blkproc and couldn't find a way, then I took the source code and made a "derivative art" blkproc2 that was identical in most respects apart from calling functions with blocks from 2 images, like cov/corrcoef. Worked fine when I had the image processing toolbox, but my function was no-license-blocked on machines without the image processing toolbox. I could live with that at the time. But I also wanted to distribute my toolbox (~1-3 functions used my blkproc2) to others. This I realise is in the copyright gray-zone, so I'd like to know if it is OK to distribute this modified function?
Steve replied on : 8 of 13
Bjorn—I don't have the expertise to be able to speak for MathWorks on licensing and copyright issues. My own recommendation to you would be for you to write your block processing function so that the code you distribute is not derivative.
BjornG replied on : 11 of 13
Steve, that's what I thought, so I decided not to distribute my blckproc2. Which made the distributed toolbox one functionality short. Because, I could not imagine any way to write a blkproc2 that was not derivative and at the same time behaved identically with blkproc whit respect to handling of "sub-sized blocks at the image frame". To achieve that I felt I had to more or less replicate the code of blkproc - at least as far as the loops and their indexing. And then it unfortunately would be derivative work anyway.
Jotaf replied on : 12 of 13
Yasin Abbas and BjornG -- You can do block-wise cross-correlation (or normalized cross-correlation) between 2 images by expressing the formula using neighborhood filter operations (imfilter) and other vectorized operations on both images. To have an idea of this trick, see the code for stdfilt ("edit stdfilt"). The formula imfilter(I.^2,f)+imfilter(I,f).^2 expresses the typical variance formula but for the neighborhood of each pixel: sum(x.^2)+sum(x).^2. (I omitted some constant factors like 1/n for clarity.) Now instead of slow loops or block operations you have a couple of very fast convolutions. If there's an interest I might post this in the File Exchange :)