Error Using zeros command

Hello,

I am getting the following error:

• _Error using zerosOut of memory. Type HELP MEMORY for your options.

Error in CT2 (line 26) sequence = zeros([size(I) numFrames],class(I));_ *

in the following section of the code (the first line is line 26):

_ sequence = zeros([size(I) numFrames],class(I)); sequence(:,:,1) = I; _

I have a 32 bit system with the following memory (which seems enough for 30 images each being 3001 x 3001 uint 16) info:

Maximum possible array: 505 MB (5.299e+008 bytes) Memory available for all arrays: 1380 MB (1.448e+009 bytes) * Memory used by MATLAB: 427 MB (4.477e+008 bytes) Physical Memory (RAM): 3292 MB (3.452e+009 bytes)

• Limited by contiguous virtual address space available. Limited by virtual address space available.

Any work arounds or pointers?

Thanks,

---Ish

Answer 1

[John D'Errico]

1. Work on smaller images, or ...
2. Work on fewer images, or ...
3. Migrate to a 64 bit version of MATLAB, or ...
4. Learn to work on one image at a time, reading and writing them from disk, or ...
5. Convert to uint8 images, cutting the memory required in half, at a cost of 8 low order bits.

There a really are no things you can do to make things tremendously easier unless you do one of the options I've offered above. Wanting to solve big problems requires sufficient memory.

Note that once you do choose a way to alleviate the memory problem, many users just start working on bigger problems, so it will not be long until you trip over the same issues unless you move to a 64 bit system. Even then you can still cause problems if you get too aggressive in the size of the problems you attack, as a 64 bit system will start throwing stuff onto disk using virtual memory. So the swap time could be an issue. Computers are not infinitely large or fast.

[Salaheddin Hosseinzadeh]

Hi John,

Good suggestions.

I have a question though!

Is this a MATLAB memory issue or the whole system? I mean, if we were to use C or C++ or other programming languages, we still had the same problem? Or it's MATLAB that cannot get all the system memory, and eventually crash it or slow it down? Does C++ limited to the same amount of memory?

Thanks alot.

[José-Luis]

The amount of memory allocated to a given process depends on the OS. Matlab is one such process. So in that sense, no, C++ will not give you access to more memory, unless you somehow goad the OS into it.

Matlab, however, uses a fair chunk of memory to just "exist" so your available memory goes down just by starting Matlab.

[Salaheddin Hosseinzadeh]

Thanks for your answer Luis.

So the only disadvantage, that might be addressed to MATLAB, is that it consumes a little bit more memory than a programming language might do.

Which well worth it from my point of view.

Viva MATLAB!!

[José-Luis]

Well, it depends how you understand a little bit. Around 300 MB at the very least.

Also, if you worry about memory, C++ allows you to control that more closely, whereas it is sometimes hard to know what is going on behind the scenes in Matlab. That liberty awarded by C++ is a double edged sword, it might save you but you might also be shooting yourself in the foot.

[John D'Errico]

Good question. MATLAB takes up a large amount of memory on its own, so that limits what you can do. And copies of variables are often generated automatically on the fly in subexpressions. You can get fragmented memory before long with these big variables flying around. The PACK command will help you clear that up a bit, but there is indeed a cost to working in MATLAB. Of course, MATLAB has other advantages in terms of development time, etc.

You are running on a 32 bit system though, so nothing you do can access more memory than your OS will allow. Of course, as you point out, the images you are working with will take up:

30*3001*3001*2
ans =
   540360060

bytes of memory, so you should have enough room in theory as long as you do not make unnecessary copies. Sadly, MATLAB on a 32 bit system will not leave you much room beyond that though.

Well written C or C++ code will certainly leave you more room, but even there the best answer is probably to leave the images on disk until they are explicitly used. This is true for any language of course, including MATLAB, which would also solve your problem.

Answer 2

[Image Analyst]

You, or someone, tagged this as digital image processing. If that's the case, you might be able to use uint8 image/sequence like John mentioned as point 5. Just pass 'uint8' into zeros():

sequence = zeros([size(I), numFrames], 'uint8');

That will cut the memory down by half from what you're currently doing (uint16). It really depends on what you'll be using sequence for. If it will never have values above 255, then uint8 is fine. If you want to stuff a 16 bit image in there, then just divide the image by 256 to scale it down to uint8.

Another thing to check. I is a grayscale image, right? Are you sure? Do this

[rows, columns, numberOfColorChannels] = size(I)
sequence = zeros([rows, columns, numFrames], 'uint8');

Tell me if numberOfColorChannels is 1 or 3.

[Ishtiaq Bercha]

Thanks for your answer. I am new to this but if your suggestion is going to cut down the image quality and the true fidelity of image data, as it seems to be doing, then perhaps it is not the best option to use for medical imaging data. What do you think?

[Image Analyst]

It depends on if you're doing radiometric (intensity) measurements or spatial measurements (like finding areas or outlines). Chances are you can still find the liver or lungs no matter if the data are 16 bit or 8 bit and the borders won't be any different. If you're comparing very slight changes in intensity then your precision will be less.