Personal tools
  • Help

jist:PluginsSaveMemory

From NITRC Wiki

Jump to: navigation, search

The following instructions require JIST Pre-Beta 1.4 or newer.

Contents

Save Memory When Writing Plugins

When you are processing many image volumes (either inputs, outputs, or both), you often do not need to keep all volumes in memory at all times. JIST's default behavior is to load all volumes prior to calling execute and write all volumes when you are done. This behavior may be disabled on a parameter-by-parameter case by calling in either createInputParameters or createOutputParameters:

param.setLoadAndSaveOnValidate(false);

Input Parameters

When the above flag is set, input volumes (and volume collections) are not loaded until the first time that you request data.

ParamVolume

For example, with a ParamVolume, the data are not loaded until you call:

param.getImageData() 

or

param.getModelImage().

To release the memory associated with a ParamVolume, call:

param.dispose();

If you need the data again from a parameter, you can call any data access method and the data will be loaded from the disk.


ParamVolumeCollection

If you want all the data in a collection loaded at once and/or released, you can use any of the typical data access methods described above. If you would like the system to only load specific objection in a collection, then use

param.getParamVolumeList()

and use the above access methods on specific items in the collection.


Output Parameters

When the above flag is set, input volumes (and volume collections) are not written out at the end of an execute method. Rather, YOU are responsible for calling

param.writeAndFreeNow(this); 

from within your ProcessingAlgorithm. For ParamVolume objects this will write out the volume to disk and call .dispose(); For ParamVolumeCollection objects, this will write out any objects that have not-yet be written out to disk.

Example Code

See the follow class for an example of a plugin that handles a very large number of inputs and outputs on minimal memory:

    edu.jhu.bme.smile.demo.MemoryDemo


Legacy Methods

The original method of carefully managing memory will still work. However, this is much more prone to programming error and we suggest using the above method.

When JIST modules are developed with input classes of “Volume” or “Surface”, then all of the inputs are loaded prior to computation and all of the outputs are written after computation. No inputs or outputs are closed until the module is finished and the system is sure that the data are no longer needed. This behavior is by design and can lead to efficient computation when all analyses are being run in a single thread. However, for certain memory intensive tasks or tasks that involve many intermediates which should be written out and closed prior to completion, then this behavior is not desirable.

Fortunately, JIST supports a complementary method of data exchange through generic “File” types. The type of data may be validated by setting acceptable file extensions. Image/surface dimensions/resolutions/etc. cannot be validated prior to the start of the module because the data are not opened by the system. However, it is essentially trivial to query the JIST interface to load the data for you, write out data when you are done, and close the image at the end.

You can create an input parameter to accept any file with a valid image extension with the following code example:

 
mainParams.add(sourceVols= new ParamFileCollection("Source Volumes",new FileExtensionFilter(ModelImageReaderWriter.supportedFileExtensions)));
mainParams.add(targetVol= new ParamFile("Target Volume",new FileExtensionFilter(ModelImageReaderWriter.supportedFileExtensions)));

To read a volume, use:

CubicVolumeReaderWriter rw  = CubicVolumeReaderWriter.getInstance();
ImageData target = rw.read(targetVol.getValue());

To free memory associated with a volume:

vol.dispose();
vol=null;

To save a volume use:

CubicVolumeReaderWriter rw  = CubicVolumeReaderWriter.getInstance();
File f2 = rw.write(thisreg, f1);

See the “edu.jhu.ece.iacl.plugins.registration.MedicAlgorithmEfficientFileCollectionRegistration” for an example of how this works.

Powered by MediaWiki
  • This page was last modified 14:34, 4 February 2010.
  • This page has been accessed 1,858 times.
  •