Processing Large Volumes in MeVisLab

This document discusses helpful techniques as well as limitations when processing very large images with MeVisLab.

MeVisLab uses a demand-driven, page-based image processing approach with caching. This enables the processing of images which are much larger than the computer’s main memory or the signed 2 GB-limit on 32 bit systems.

However, MeVisLab has many modules and mechanisms that might use a lot of memory, so the memory limits can easily be exceeded (for example the MemoryCache modules). Sometimes those mechanisms are hidden so they complicate the handling of large images.

In order to safely handle very large images in MeVisLab, it is important to know the limitations of the currently used, concrete computer.

As a first step, determine the configuration of the system you use. Check how much

  • physical memory,
  • disk space, and
  • graphic card memory you have available.

When you know those basic limitations, you can configure the ML cache and the texture memory sizes, as well as multi-threading settings, in the MeVisLab preferences.

  • Set the image processing cache size to two-third of your computer’s available physical memory (or more conservatively, to a half of it).
  • Make sure that at least 1 GB of physical memory (plus texture memory size) or left over for the operating system and other applications!
  • On 32 bit systems or with a 32 bit version of MeVisLab, do not use more than 768 MB for the ML cache plus texture memory, even if your computer has 4 GB or more of RAM.
  • The configured texture memory size should well fit into the graphics card’s memory. Leave enough memory for other applications.
  • Although multiple threads can increase performance, it also duplicates temporarily used memory buffers, so be careful with many threads when you have strict memory limits!
  • If possible, use image extents which are multiples of page extents (or rather, set the page extents so that they are integer divisors of the image extent).

  • Pages which are not completely part of the image often require extra handling or extra copying of their content via other temporary pages.

  • Configure page and image extent such that two image slices displayed in a 2D viewer fit into the ML cache and - with all color channels - fit in the graphic card’s cache.

    • As an example, a 2D slice of 4096 x 4096 voxels and three color channel of type short can use up to 100 MB of display memory. For two slices, 200 MB might be required. Thus the graphic card’s memory and the ML cache should both have at least about 256 MB. Reducing the voxel type to uint8 or using no color channels often can eliminate this problem.

  • Do not use extreme x and y page extents: 2048 x 2048 usually is enough.

  • Do not use many more than 4 mega pages per image, because many modules internally use page information tables whose sizes otherwise become too large.

When saving large images, make sure to use 64-safe file formats.

  • In MeVisLab, only the GVR-file format (.gvr) and the MLImageFormat (.mlimage) files are tested for being 64-bit safe. Use only the format specific IO modules to read/write/cache these formats.
  • In MLImageFormat modules use LZ4 compression, because it compresses memory faster than most network connections or file IO operations can transfer them.
  • Especially when processing very large files ensure that the used file system can handle corresponding sizes. Many file systems still have 2 GB or 32 GB limitations.
  • Many disks (for example system SSDs or RAM-disks) can have surprisingly small sizes. Often the system tmp-directory is located on fast but small disks. Usually this can easily be solved by selecting some other drive for storing temporary files.
  • Avoid memory caching modules such as MemoryCache or registration modules, or replace them by file caching modules (for example MLImageFormatFileCache).
  • Use page-based modes instead of memory caching modes in modules which allow such configuration (for example OrthoReformat3 or OrthoSwapFlip). If a module only works on images that need to be fully stored in main memory, better avoid it.
  • Avoid modules that reformat memory dimensions (such as MPR and Ortho modules), because they temporarily allocate too much memory.
  • Use only modules that operate page-based or which are designed for large images. For example:
  • Storing images on disk and displaying them can be optimized significantly sometimes if nearly empty regions in the images have unique (best zero) values instead of some low-level noise values. A simple noise filter before displaying or storing such images can help.
  • If you create or process images and if you have control over their configuration, prefer larger z, t, or u dimensions over larger x or y dimensions.

In the following, two example configurations are given to handle very large images.

  • Example 1:
  • Filtering an image with page extent 2048 x 2048 x 4 x 1 x 1 x 1 and image extent 8192 x 8192 x 4096 x 1 x 256 x 1 = 64 Tera voxel (uses 4 x 4 x 1024 x 256 = 4 mega pages) created with type uint8 by a TestPattern module can still be handled on 32 bit systems in a pipeline of TestPattern, Arithmetic1, and View2D on a 32 bit machine with a graphic card of 256 MB.
  • Example 2:
  • Saving an image with an extent of 4096 x 4096 x 256 x 1 x 16 (a volume ramp image of type uint8 generated by TestPattern with a page extent of 512 x 512 x 2 x 1 x 1) by MLImageFormatSave with LZ4 compression, took 10 minutes and resulted in a 1,7 GB file.
  • Saving the same image without compression took 12 minutes and resulted in a 57 GB file.