Steve on Image Processing and MATLAB

Concepts, algorithms & MATLAB

This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

R2010b – More Image Processing Toolbox changes 3

Posted by Steve Eddins,

In my October 15 post I mentioned some Image Processing Toolbox performance improvements in the R2010b release. Today I want to mention other improvements in the release.

There is a new corner function to supplement the existing cornermetric function. The corner function applies a peak-detection method to the output of cornermetric.

There are several improvements related to processing very large image files. The blockproc function now supports writing to JPEG2000 files, and it also has new options for controlling padding behavior at the image edges. You can also now extend both blockproc and rsetwrite to support custom image file formats by writing your own ImageAdapter class.

The toolbox function dicomread now reads multiframe imagery faster, and it now supports files containing images compressed using JPEG2000.

Next week I plan to do one or two more posts on R2010b. In particular, there's big news for the Image Acquisition Toolbox. I'll also mention MATLAB features that especially caught my eye.


Get the MATLAB code

Published with MATLAB® 7.11

Note

Comments are closed.

3 CommentsOldest to Newest

Siddharth replied on : 2 of 3
I am not sure whether it is a bug or not, but I have noticed some very unusual behavior with blockproc and JPEG2000 images. I have an image that was JPEG2000 encoded using the Kakadu JPEG2000 library. (I have no control over how the conversion actually happens). When I use R2010a and blockproc to process the image, the analysis progresses as expected. However, if I use R2010b to analyze the same image, using the same code, the function fails. The error message I get in R2010b is :
??? Error using ==> jp2dispatcher
Error in Kakadu File Format Support:
Unable to open input file,

Error in ==> Jp2Adapter>Jp2Adapter.Jp2Adapter at 23
            obj.id = internal.images.jp2.jp2dispatcher('create', ...

Error in ==> blockproc>createInputAdapter at 802
        adpt = internal.images.Jp2Adapter(data_source,'r');

Error in ==> blockproc at 271
    a = createInputAdapter(a);

Error in ==> run_wholeslidejp2 at 16
blockproc(name, [2048 2048]*2, @cmyk_voronoi, 'Destination', resfile);
The file exists in the full path specified using the "name" variable above. For instance, the following statement returns true:
exist(name,'file')
ans =
     2
imfinfo(name) also returns image info successfully (in R2010b). It takes around 3.5 hours to process this image and I was interested in the performance enhancements in blockproc in the new release.
Steve replied on : 3 of 3
Siddharth—You should contact technical support to report a possible bug. I will also let the development team know about your comment. I'd also like to point out that the performance improvements to blockproc do not magically make the user-defined function go faster. Instead, the overhead of blockproc bookkeeping was reduced. So you won't see much difference if the 3.5 hours of processing time is being spent mostly in the user-defined function.