Large CT images

I am working with large CT images of an entire human body.
Dicom convertion is done with Dicom to Nifti converter from C.Rorden.
Voxel spacing is typically 0.9x0.9x0.6 and the dims ranging rnd 512x512x2000.
The filesize after dicom import ranges between 750mb to 1.500gb.
In order to reduce filesize,
I ususally crop ‘air’ and resample to voxelsize o 1x1x1 (lin. interpolation),
which does help a bit in reducing filesize. We save the volume as a .nrrd filetype.
Using Slicerversion 4.10.1

What other steps can be taken in order to reduce filesize?

Thank you.

750-1.gGB volumes are not actually that big. Why do you need to reduce the filesize any further?

Always use at least the latest Slicer Stable Release and try the latest Slicer Preview Release, too, because we are constantly improve performance, add features, and remove bugs.

This sounds good, but 0.9x0.9x0.6 to 1.0x1.0x1.0 resampling means that you reduce the file size to about half, which is not much. If your computer has problems dealing with this file size then you can increase the spacing to 1.5x1.5x1.5 or 2.0x2.0x2.0 or even higher.

Computer does not handle those filesizes all that well.

Thank you.
I typically use the latest release, but Im somewhat locked into 4.10 for this project.
We use the markup tool a lot and export fiducial points to .fcsv. I believe the coordinate systems are different between 4.10 and 4.11. and I dont want to change the existing processing pipeline.

You can choose that coordinate system you want to save in. We have not exposed this on the GUI, as we want to encourage everybody to consistently use LPS coordinate system in all files (as in DICOM, and as it has been always done for images, transforms, etc).

If for a legacy project you want to change what coordinate system is used, you can change the coordinate system for all newly created markups fiducial nodes that are saved in fcsv format, by adding this code snippet to your application startup script:

defaultFiducialStorageNode = slicer.vtkMRMLMarkupsFiducialStorageNode()

Coordinate system choice is preserved if you load and save a node, so you only need to switch the coordinate system for a node once. Even if you load and save the node on another Slicer instance where the startup file was not modified, the coordinate system will still be still RAS.

In case you ever need to change coordinate system in a node to RAS that has been already saved as
LPS then you can run this:

fiducialNode = getNode('F')

Coordinate transformaiton from RAS to LPS is very simple, and involves negating the sign of the first two coordinate. There are many benefits to keeping the fiducial coordinates in LPS so that they are exactly in the same reference frame as your images.

I would suggest converting your existing RAS fiducials to LPS, and then start using the latest version of Slicer. That you will also futureproof your data.

There are also quite a few updates to the Markups tool as well.

Thank you for the suggestion of editing the startup script. I was unaware of this option. That might be the way to go for now, since I do see the advantages of the newer version.

Thank you for your input. You certainly correct of the improved featurelist of the markuptool, which is worth switching too.

You may want to try MRIcroGL for resampling large images:

  1. Use the Import/Tools/Crop to interactively crop large images. Do this first to remove parts of the field of view that are not of interest.
  2. Use Import/Tools/Resize to rescale your image. You can choose your interpolation filter (nearest, Linear, hermite, bell, spline, Lanczos, or Mitchell). All downsampling interpolation uses anti-aliasing. The Lanczos sinc filter is used by default for downsampling, it preserves high frequency edges better than linear interpolation. While your can choose custom scaling, it does provide three quick buttons:
  • “Isotropic shrink”, e.g. this would convert your 0.9x0.9x0.6 to 0.9x0.9x0.9
  • 512mb Texture is a common maximum texture size for many integrated graphics cards. It will provide fluid rendering performance for most modern integrated and discrete graphics.
  • 2048mb Texture is the ultimate limit for any OpenGL-based texture.

I know your primary interest is using Slicer, but it is worth noting that MRIcroGL preferences allows you to set the maximum texture size it will load (512mb is the default). If you have a high end graphics card, you can set this to 2048 to avoid downsampling images. If you do set this to 512 and load a bigger texture, the cropping and rescaling are applied to the original large dataset, not the dataset reduced to fit on your graphics card.