The amount of RAM (working memory) needed for deconvolution depends strongly on the image and data type. If the image is saved as a 16 bit image you typically need 6-8 times more RAM than the size of your image to deconvolve the entire image in one go. The reason for this is that the mathematical operations during deconvolution require floating point numbers (32 bit). The result image and intermediate images will therefore take twice as much memory as the raw data. For a raw image saved in 8 bit (less common) you thus need 12-16 times more RAM than the raw image for the deconvolution. Importantly, deconvolution goes per channel and per time frame so these intermediate images are needed only for 1 channel and 1 time frame.

On top of this there are a few important exceptions:

• 2D images Huygens does use 3D Point Spread Functions (PSF) as the convolution in your microscope is also always in 3D. When you deconvolve a 2D image, Huygens will therefore expand this image in the 3rd dimension (usually Z) which multiplies the amount of required RAM. The extent of the expansion varies greatly as this depends on the size of the PSF in the 3rd direction. For 2D widefield images with a low NA this can increase the size by a factor of 50 but for 2D confocal images this will usually not be more than a factor of 10. Luckily, most 2D images are small so this large multiplication factor rarely causes issues. Note that 2D images are harder to deconvolve as insufficient information is available to identify out-of-focus light.

• SORA Spinning Disk This is a rather special case. Due to the high magnification in SORA microscopes the pinholes get extremely close together, causing their signals to overlap. In order to calculate this crosstalk correctly a significant amount of additional RAM is required. If this stops the deconvolution from becoming feasible you can deselect the SORA option in the microscopic parameters and use an experimental PSF to counter this sub-optimal microscopic parameter setting.

• Array detector For Matrix STED and Airyscan systems the raw data consists of 16, 23 or 32 detector images. For most reduction modes (except for "none") Huygens first reduces these images and their PSFs to 1 combined (reduced) image before deconvolution. Therefore you typically only need 2-4 times more RAM than the raw image for these images.

Operating systems can use a part of the hard disk that is intended for long term storage as extra RAM. On a Linux installation, typically a separate partition is created on the disk when Linux is installed, while Windows and Mac use a file on the system disk that can grow on demand. On Linux it is possible to temporarily create an extra swap file. On Mac and Windows the amount of virtual memory and the disks it resides on can be configured in e.g. Mac OSX and Windows 10.

Magnetic hard-disks have the advantage that they are cheaper per terabyte in large sizes and do not suffer as much from wearing out. However, SSDs and especially NVMe SSDs are much faster than magnetic disks. Be aware that SSDs do wear out when they are written too often: look for the "total number of TB written" specification of the disk.

You can often prevent issues by utilizing your memory in a smarter way. It will always help to crop the image to remove as much empty space as possible. The smaller the image the faster they process. Huygens therefore offers an inteligent autocrop function in the Cropper and Workflow Processor.

Moreover, deconvolution is done channel by channel and (time) frame by frame. It is therefore feasible to split the raw images in individual channels or sections of time in order to reduce the amount of RAM needed to store the raw, intermediate and result images. The splitting and deconvolution can also be done in batch as long as the raw files have the same size/dimensions.

In the Stitcher there are several additional options to reduce the memory. For the tile position optimization there is a low memory option that significantly reduces the memory usage for large tiles by only considering the edges. In addition there are options to do the stitching process in 8 or 16 bit integers. This is less accurate than using floating point numbers, but saves a factor 2 or 4 in terms of memory.

Lastly, there are some smart RAM saving protocols inside the software. For example, if there is little memory available the original image is not rewritten to 32 bit floats. When this is not enough, the 32 bit internal calculations will also be run in small chunks, not considering the image as a whole. This is called Brick Splitting. Though it is a useful technique to circumvent system RAM requirements. This splitting can become problematic when the Point Spread Function is very large (as with Wide Field Microscopy) as then the contribution of every light source affects the whole image. Luckily, the Brick Splitting routine considers many variables to find the best compromise between available memory and deconvolution requirements. There is a limit however as you also would need to do additional calculations to prevent bricking artifacts when putting the bricks together at the end.

The Graphical User Interface (GUI) can suffer when large amounts of RAM and CPU are being used by the calculation. In these situations it can help to use the Workflow processor instead as this needs very little memory to update the GUI and because it allows you to limit the computational resources. In the Workflow Processor it is also possible to schedule tasks and start them at a later time. For example, you can start your callculations at the end of the workday, or you can program them to start in the weekend when no-one is using the computer (don't close the workflow processor in the mean time).

In addition, when the freezing is caused by excessive RAM or swap space use, it could help to instruct Huygens to use smaller bricks in the calculation. This can be done in the deconvolution template or in the deconvolution Wizard by setting the "Brick mode" option to "More". Similarly, in some cases it can be helpful to reduce the number of threads per workflow in the main workflow processor window. If you for example leave 1 or 2 CPUs (threads) available for other tasks outside Huygens these will run a lot smoother. The default setting for this number of threads and number of Bricks is "Auto" which will use all available resources in order to let the calculations finish as quickly as possible. Limitting this will thus slow the calculations down.

Note that for extremely big images you would need to expand the timeout limit in both the deconvolution template and in the Workflow Processor itself (see options menu). The defaults are 3 days for workflows and 10.000 seconds for the deconvolution).

The Memory Mapped Format uses a manner of data handling where large amounts of data that are required for calculations are stored directly on your harddisk ( normally used for long-term storage). Your harddisk is usually 10-100 times larger than your working memory and thus this approach lets you process even the biggest images. The cost of this approach is processing speed and the ease of accessing the data later on. The processing speed when you need to read/write from the harddisk is at least an order of magnitude slower than when you read/write to the working memory. These calculations will therefore take a very long time to complete so it is only advised to use this format if it doesn't fit in the working memory at all (see "How can I reduce the memory that is required?" above).

The result file will be in the MMF format which can only be accessed by programs that can work with memory mapped files. Therefore most analysis programs will not be able to open this file. Huygens can use MMF files as input images, but most tool require normal intermediate or result images. This is something we hope to expand future versions. For now the main application of this is thus simply to be able to perform the stitching on a computer with too little memory to contain the result image. The image could be resaved as for example a Pyramidal OME.Tiff file for post analysis on a larger computer.

Sometimes the memory problem appears when saving your datasets. Why does just saving data require extra memory usage?

This 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). Sometimes, there's not enough memory to create this full third image.

In these cases first store the results first in ICS or OME, restart the program and try reloading and converting the image to the desired format. You can also remove all other images from Huygens to create room for the destination image.

There might be problems when the Operating System (OS) reports that it has more memory available than what is going to be provided later. The provisions made based on initial figures (like Brick Splitting) will then be incorrect leading to issues during the calculation.

In addition, a problem 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 are no a contiguous pieces 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". Until the OS in question does 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. When large amounts of memory are required we therefore suggest using recent Windows or Linux versions.