Matlab - slow imread, multiframe tiffs

Author

slow imread, multiframe tiffs

runcyclexcski@yahoo.com

2007-06-28, 7:17 pm

Hi all,

I posted this ~3 months ago and got no response. So I am trying again.

I use matlab to read and analyze multiframe tiff images. An average
image is a 16 bit grayscale, 30 by 30 pixels, tens and hunreds of
thousands of images. I have problems with performance, to the point
when I am considering re-writing the whole code in VC++. Can anyone
suggest a way to speed matlab up? Generate libs from matlab and plug
them into VC++ code? I could even get a more powerful PC just to save
myself time needed to re-write the code in a faster language.

Here are the details.

Iterative imread of a 1000 30x30 16 grayscale TIFF frames takes 6.1
seconds. This is
despite the fact that I pre-allocate everything:

frames(height,width*i) = uint16(0);
frame(height,width) = uint16(0);
tic,
for index=1:i
frame = imread(fifile,'tiff',index);
frames(1:height,(index-1)*width+1:
(index-1)*width+width) = frame;
end
toc

elapsed_time = 6.1100

In fact, not-preallocating the arrays does not make a big difference
(~25% slower?).

This is on Pentium M 1.86, 512 mB of RAM IBM laptop.

Loading this same tiff file in a image analysis program called ImageJ
(Java-based?) takes 0.8 seconds. I am not a Java programmer, but the
Java source of ImageJ, and the matlab algorythms look the same. The
only difference is a factor of 10 in performance.

Steve Eddins

2007-06-29, 7:14 pm

runcyclexcski@yahoo.com wrote:
> Hi all,
>
> I posted this ~3 months ago and got no response. So I am trying again.
>
> I use matlab to read and analyze multiframe tiff images. An average
> image is a 16 bit grayscale, 30 by 30 pixels, tens and hunreds of
> thousands of images. I have problems with performance, to the point
> when I am considering re-writing the whole code in VC++. Can anyone
> suggest a way to speed matlab up? Generate libs from matlab and plug
> them into VC++ code? I could even get a more powerful PC just to save
> myself time needed to re-write the code in a faster language.
>
> Here are the details.
>
> Iterative imread of a 1000 30x30 16 grayscale TIFF frames takes 6.1
> seconds. This is
> despite the fact that I pre-allocate everything:
>
>
> frames(height,width*i) = uint16(0);
> frame(height,width) = uint16(0);
> tic,
> for index=1:i
> frame = imread(fifile,'tiff',index);
> frames(1:height,(index-1)*width+1:
> (index-1)*width+width) = frame;
> end
> toc
>
> elapsed_time = 6.1100
>
> In fact, not-preallocating the arrays does not make a big difference
> (~25% slower?).
>
> This is on Pentium M 1.86, 512 mB of RAM IBM laptop.
>
> Loading this same tiff file in a image analysis program called ImageJ
> (Java-based?) takes 0.8 seconds. I am not a Java programmer, but the
> Java source of ImageJ, and the matlab algorythms look the same. The
> only difference is a factor of 10 in performance.
>

Hi,

About 70% of the time used by MATLAB for your example is in a MEX-file
which simply calls functions in libtiff, a widely-used C library for
TIFF I/O. So I'm not sure that you would see much benefit from writing
your own C or C++ code.

When you use ImageJ, what indication do you have that "loading the file"
is actually reading the pixels from all 1000 images? In other words,
I'm wondering if your comparison is really "apples to apples."

Another thought - you're getting an average read time of 6ms per image.
How long does your analysis step take for each image? Is the I/O is
truly going to be your performance bottleneck?

--
Steve Eddins
http://blogs.mathworks.com/steve

Steve Eddins

2007-06-29, 7:14 pm

Steve Eddins wrote:
> runcyclexcski@yahoo.com wrote:
>
> Hi,
>
> About 70% of the time used by MATLAB for your example is in a MEX-file
> which simply calls functions in libtiff, a widely-used C library for
> TIFF I/O. So I'm not sure that you would see much benefit from writing
> your own C or C++ code.
>
> When you use ImageJ, what indication do you have that "loading the file"
> is actually reading the pixels from all 1000 images? In other words,
> I'm wondering if your comparison is really "apples to apples."
>
> Another thought - you're getting an average read time of 6ms per image.
> How long does your analysis step take for each image? Is the I/O is
> truly going to be your performance bottleneck?
>

Also, part of the problem is the high overhead of parsing TIFF file
metadata each time you read only 900 pixels. If I create a 30000-by-30
uint16 image, which contains the same number of pixels as your 1000
30-by-30 images, imread reads the whole thing in 15ms on my computer.

--
Steve Eddins
http://blogs.mathworks.com/steve

runcyclexcski@yahoo.com

2007-06-30, 8:12 am

I found that when I save the same data in binary and save the width
and height of the frames in a separate header file (so that ML knows
in advance how many frames there are to open and how big the frames
are) the time it takes to open speeds up by at least a factor of 10.

Speaking of imageJ - are you saying it opens only one frame and keeps
opening the rest if I have to scroll? I doubt it: the response when I
scroll is fast, a response you expect if the whole "movie" is in the
memory.

On Jun 29, 7:30 am, Steve Eddins <Steve.Edd...@mathworks.com> wrote:
> Steve Eddins wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Also, part of the problem is the high overhead of parsing TIFF file
> metadata each time you read only 900 pixels. If I create a 30000-by-30
> uint16 image, which contains the same number of pixels as your 1000
> 30-by-30 images, imread reads the whole thing in 15ms on my computer.
>
> --
> Steve Eddinshttp://blogs.mathworks.com/steve- Hide quoted text -
>
> - Show quoted text -

Steve Eddins

2007-06-30, 10:19 pm

runcyclexcski@yahoo.com wrote:
> I found that when I save the same data in binary and save the width
> and height of the frames in a separate header file (so that ML knows
> in advance how many frames there are to open and how big the frames
> are) the time it takes to open speeds up by at least a factor of 10.
>
> Speaking of imageJ - are you saying it opens only one frame and keeps
> opening the rest if I have to scroll? I doubt it: the response when I
> scroll is fast, a response you expect if the whole "movie" is in the
> memory.
>

I don't use ImageJ and I don't know what it is doing. I was merely
asking.

--
Steve Eddins
http://blogs.mathworks.com/steve

Sponsored Links