Steve on Image Processing

October 29th, 2010

R2010b – More Image Processing Toolbox changes

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

3 Responses to “R2010b – More Image Processing Toolbox changes”

  1. Adnane replied on :

    Thanks a lot
    this looks to be very interisting :)

  2. Siddharth replied on :

    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.

  3. Steve replied on :

    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.


MathWorks
Steve Eddins is a software development manager in the MATLAB and image processing areas at MathWorks. Steve coauthored Digital Image Processing Using MATLAB. He writes here about image processing concepts, algorithm implementations, and MATLAB.

These postings are the author's and don't necessarily represent the opinions of The MathWorks.