Skip to content

Useful information

Jump to bottom
villekf edited this page May 7, 2021 · 19 revisions

This page lists some useful information such as recommendations and possible issues that can arise.

Recommendations

Importing GATE data

PET data

On Unix systems, it is highly recommended to use ROOT data as it takes less disk space than ASCII or LMF but is also faster to load than ASCII and has more features than LMF. However, do take note of the crashing in MATLAB R2018b and earlier (see README.md).

On Windows systems ASCII is the recommended format.

LMF format is not recommended but can be used for normal coincidence imaging (i.e. no trues or scatter extraction).

CT data

Currently only projection images are supported.

Using corrections

These apply to PET data only. CT data can use custom scatter correction data though same way as PET data.

When using randoms correction (delayed coincidence window), variance reduction is recommended when performing the corrections during the image reconstruction.

Corrections during the reconstruction are recommended to preserve the Poisson nature of the measurement data, however, they will most likely slightly reduce the speed of the image reconstruction. This should be only marginal increase though.

Normalization with raw list-mode data can be unreliable compared to sinogram data. Computing normalization coefficients for raw data also uses more memory. Nevertheless, it is highly recommended to perform normalization coefficient computation to raw data if possible.

Selecting the correct implementation

Implementation 2 is the recommended method if it is supported and if single precision (f32) variables are not a problem. It should be both the fastest method and also, along with implementation 1, has the widest array of supported features. For CUDA capable devices, it is recommended to enable CUDA if you are using improved Siddon (i.e. projector_type = 1) otherwise OpenCL is recommended.

Implementation 3 is recommended if you have multiple GPUs and want to compute OSEM/MLEM reconstructions. For single GPU/device case it is recommended to use implementation 2 instead if possible. Implementation 3 is recommended over implementation 4, though the latter (4) uses double precision numbers while the former (3) uses single precision. If you are doing OSEM or MLEM only and want the simplest and fast method, then implementation 3 is recommended. Implementation 3 is also recommended if you can’t use implementation 2 (e.g. using MinGW on Windows), but want to utilize GPU(s).

Note
 The device/platform numbers with implementations 2 and 3 can differ, i.e. device 0 on implementation 2 is probably a GPU, but with implementation 3 that might actually be the CPU. Use ArrayFire_OpenCL_device_info() to check the device numbers with implementation 2 and OpenCL_device_info() when using implementation 3.

Implementation 4 is recommended when implementation 2 is not available and you need more than OSEM and/or MLEM, or, alternatively, if you are not interested or capable of installing the required OpenCL/ArrayFire files.

Implementation 1 should only be used if none of the above cases are valid. This could be if you want to use some of the other algorithms (e.g. MBSREM), but can’t use implementation 2, or if you want to compute the system matrix. Note, however, that there are memory considerations when using implementation 1 (see below memory issues). Implementation 1 is also the only implementation that currently does NOT support TOF data.

Note
 Implementations 4 and 1 use double precision and, as such, are numerically more accurate than implementations 2 and 3. However, in most cases the differences should be small/insignificant.

If you are computing the forward and/or backward projections (e.g. by using the class object), implementations 3 and 4 are available (PET also supports implementation 1, though that is not recommended). If you use implementation 2 when computing the forward and/or backward projections, it will behave as if implementation 3 is selected (make sure the platform/device number is set for implementation 3). No difference in features exist between the implementations in this mode, but, as before, implementation 4 is double precision while 3 is single.

Selecting the projector

For best quality, the recommended projector is the volume of intersection ray tracer, i.e. options.projector_type = 3. Default tube and voxel radius values are recommended. However, this is also the slowest method. Orthogonal distance-based ray tracer is slightly faster alternative with 2.5D mode being (usually) faster. Note that CT does not support orthogonal distance-based ray tracer.

If you want a compromise between speed and quality, then point spread function (PSF) reconstruction (i.e. options.use_psf = true) with improved Siddon is recommended. Improved Siddon with PSF is several times faster than orthogonal or volume-based ray tracers.

For pure speed, improved Siddon without PSF is recommended. This, however, can lead to aliasing artifacts in some cases.

Image reconstruction parameters

For the number of iterations, subsets, subset type, regularization parameters, etc. I can’t give any recommendations. The optimal selections and values depend on the use case and as such it is best to either experiment or follow values in literature. For CT data, random subset sampling is recommended.

Memory and computational issues

Data load

PET data

Large scanners can require quite significant amount of memory when loading the GATE/list-mode data. For example, the Biograph mCT or Vision scanners can use over 20 GB of memory. As such, it is recommended to have at least 24 GB of memory when loading data from larger scanners, though with sufficient swap file size less should be sufficient though it can have significant impact on speed.

Dynamic imaging

Dynamic imaging can be very memory intensive if you have a large amount of time steps. Furthermore, dynamic data load can take significant amount of time depending on the amount of time steps, the scanner used, whether raw data is used, and the computer the computations are performed on.

Saving the dynamic examination sinogram data might also fail in Octave due to the lack of support for v.7.3 type of MAT-files.

TOF

Applies to PET data only.

Using TOF data not only requires more memory, but also takes more disk space when saving the measurement data. While there is no upper limit to the number of TOF bins, it is recommended to keep the bin count in less than 100. Dynamic TOF sinograms require even more space and memory. However, dynamic sinograms do not need extra memory when using GPU as the subsequent time frames are saved in the system memory.

Image reconstruction

Implementation 1 is very memory intensive method since it is not a matrix-free method. This is especially true if options.precompute_lor = false (this is also the only case where the system matrix computations are NOT done in parallel). Some algorithms with implementation 1 can require much more memory. These include at least MBSREM/MRAMLA. Minimum of 16GB of memory is recommended if using these, but even that might be too little depending on the subset and image size. CT data automatically uses precomputed data and this can only be changed with manual editing of the code.

Due to above, only improved Siddon’s algorithm is recommended as the projector. Especially 3D orthogonal distance-based or volume-based ray tracers can take significant amount of memory.

On large neighborhoods MRP, RDP, FMH and L-filter can use significant amounts of memory. It is recommended to keep the neighborhood smaller than 9x9x9. In the case of MRP, however, this applies only if you do not have image processing toolbox and use implementation 1 or 4.

As already mentioned above, using implementation 1 with options.precompute_lor = false is simply NOT recommended. This is only supported in order to keep feature parity (and because it was the first version that was implemented).

Using the precomputed system matrix (i.e. options.precompute_obs_matrix = true) (implementation 1 only) can take over 100GB of memory on normal PET scanners. Due to this, it has not been tested and is not recommended for 3D reconstruction.

Errors in MEX-files with implementation 2 might create memory leaks. Closing MATLAB/Octave will clear the allocated memory from the device. It is also possible that errors will cause implementation 2 to become unusable until the software is restarted. This, however, should no longer be the case as of OMEGA v1.2.

Clone this wiki locally