Not enough memory

While using the Huygens Software the following error message might occur which will terminate deconvolution and restoration:

The operating system did not allow a necessary increase of the size of the image memory pool from 1500 MB to 2300 MB for a 800 MB image with dimensions...(truncated) Failed to allocate heap memory. Not enough memory available.

Sometimes the solution is trivial: Huygens Scripting could run in 32 bit mode on a linux machine while a 64 bit version was expected. Therefore memory allocation is restricted. Reviewing scripts with this idea in mind may provide a quick fix.

In most cases however the problem is not caused by Huygens. As the message states, it is the operating system (OS) that did not provide the necessary memory when it was actually needed. Applications like Huygens cannot access the memory directly, this is handled and provided by the OS. This problem appears many times with current releases of MacOS X and many Windows systems. Details follow.

Deconvolution requirements

This memory problem can be very annoying when you try to restore a 300 MB image and you have, for example, 4 GB RAM installed. That's more than 13 times more!

A 300 MB image may not appear large (it is a typical size for a Multi Channel 3D 16 bit image, see Bytes And Bits to estimate file sizes), but when deconvolving such images many intermediate images have to be created like bricks and the PSF. All of these intermediate images are created as 32 bits which is double your original 16 bit tiff image. The final restoration result will also be 32 bit if there is enough memory, but it can be less if Huygens can't allocate the necessary memory.

Huygens Deconvolution internally runs in 32 bit float mode to make use of a wider Dynamic Range, a benefit from deconvolution. In an ideal situation without any memory restriction an original 16 bit image of 300 MB would be transformed into a 600 MB 32-bit dataset before starting deconvolution. The destination images and PSF are the same size as this transformed original which means 600 MB for both PSF and destination image. Other, intermediate state images (for FFT and other calculations) are about the same size (600 MB)

600 × 4 = 2400 MB, more than half of the memory that is installed! Maybe the operating system won't allow that allocation: the memory may be being used by other programs, perhaps the OS itself. Some operating systems (like Mac OS X) have shown to be very conservative and even when the memory is available they won't provide a single program all that much, maybe to allow other programs or other users to still use the machine later. In such cases, just having more memory installed is not a solution: the OS will not serve it anyway!

(Tip: An image can be split and each channel may be loaded seperately. An application like Huygens Essential will deconvolve them separately anyway and having the other channels loaded in the memory while deconvolving just one may push things to the memory limits).

Mac Systems

In case of Mac systems 8 GB Ram may be installed, but previous MacOS X releases (before Leopard) are still 32 bit in many aspects and can not allocate more than 4 GB for a single program if it has a graphical interface. (We have an interfaceless 64 bit Huygens Scripting for MacOS X to circumvent this problem). Still, the OS can handle different 32 bit programs running simultaneously until all the memory is used, but that doesn't help each independent program to allocate more than the theoretical maximum of 4 GB.

In practice, memory available for individual application on MacOS X is even less than 4 GB. For example, in a 8 GB RAM Mac G5, about 2.5 GB is available for Huygens and sometimes even less. As seen from previous estimations this is not a lot in the end. Despite of what can be found in some technical documentations, applications can only get up to 4 GB of RAM when demanding it in small chunks. For this kind of image restoration there is no use for small chunks but at least two large ones are needed (for the original and the result) and ideally more (for all the intermediate calculations)! The current Mac memory manager doesn't provide this for reasons unknown.

Moreover, once an application gets a reasonably big chunk, it may not get another one later even after releasing the first one. Maybe the OS thinks "you already got your piece of the tart, you don't deserve more"...

More memory

The solution of course is to have more memory and a real 64 bit OS which provides the programs as much memory as they require. Fortunately currently most, but not all, platforms are 64bit. 64 bit Linux distributions are especially good at this, and do not suffer from license limitations.

Windows Vista-64, Windows 7/8/10 are also examples of 64 bit systems that can handle large amounts of memory both in RAM and in a virtual memory pool on disk. In Windows you can expand your virtual memory, but this is always slower than having physical RAM. The same holds true for the changing the virtual memory of Mac computers.

Save memory

When no more memory can be requested the alternative solution is to use the available memory in a smart way. Huygens will still do the internal calculations in 32 bit numeric format, but if there is little memory available it won't transform the original image to try and keep memory demands down and if necessary, the final result will not be 32 bit despite the loss in Dynamic Range.

When even this is not enough, the 32 bit internal calculations will run in small chunks, not considering the image as a whole. This is called Brick Splitting and can be problematic, especially when the Point Spread Function is very large (as with Wide Field Microscopy) and the contribution of every light source affects the whole of image (the blur spreads over a large volume). If all contributions are not considered simultaneously the deconvolution result may not be as good. But in cases of little available memory it might be the only option. The Brick Splitting routine considers many variables to find the best compromise between available memory and deconvolution requirements. There is a limit however and if the bricks become so small that the deconvolution will be a disaster, it won't run. Moreover, if your Microscopic Parameters are not physically realistic this routine can also fail (see Brick Splitting).

System limitations

Even them there might be problems when the OS reports that it has more memory available than what is going to be provided later. Just asking the OS how much free memory is available is not enough if later, when demanded, it will serve less than that! The provisions made based on initial figures (like Brick Splitting) will fail.

Moreover, a typical problem present in some operating systems is that they only allow memory allocation of contiguous memory chunks. The (reported) available memory may be large, but if there's not a contiguous piece of the size that is requested, it won't be provided. Some versions of Windows are known for suffering from memory fragmentation that reduce the size of the largest allocatable chunk. In these cases, the message "not enough memory available" actually means "not enough contiguous memory available". To circumvent this issue, the Huygens Embedded Memory Manager may help if the program is run on a freshly started OS.

Until the Operating Systems in question do not improve their memory management, there's not much that applications can do. Huygens does its best not to be fooled by these OSs (usually this implies being pessimistic with the provided free memory figures, and calculate the brick splitting in a more conservative way), but when large amounts of memory are required we usually suggest using other platforms like recent Windows or Linux versions.

Exporting requirements

Sometimes the memory problem appears when saving your datasets. Why does just saving data require extra memory usage? It depends on the File Format that is being used. A format like ICS will store the data directly without further memory demands, but other formats, like TIFF, require the dataset to be transformed and for that the program needs to create a new destination image to store the transformation result (see Tiff Scaling). Maybe there's not enough memory to create a full third image, even if it is 16 bit!

In such a case, store the results first in ICS or OME, restart the program and try reloading and converting the image to the desired format.