Monthly Archives: September 2018

Importing microCT data from Scanco into Slicer

Importing microCT data from Scanco into Slicer

In this tutorial, I will show how to import a ‘raw image’ data into Slicer directly using Nearly Raw Raster Data (NRRD) format specification. I will be using a microCT data sample from a Scanco scanner courtesy of Dr. Chris Percival, however steps are equally applicable to raw image data from any other scanner vendor. For this to work, we need to know the dimension, data type and other metadata associated with the imaging session. These are typically provided as a log file. All files associated with this tutorial can be found in here.

Log file contains all sorts of potentially useful information about the scanning session, but the things we are interested are located in the very first section: Where image data starts in the raw volume (byte offset), XYZ dimensions (622 642 1085), data type (short, or 16 bit), and voxel size (0.02, 0.02, 0.02). These are key pieces of information that is necessary to describe the image data correctly through a ‘detach header’ (for more information see http://teem.sourceforge.net/nrrd/format.html).

Once you download the sample .aim file, open a text editor and paste the following lines, and save it in the same folder as the file you download with extension .nhdr (e.g, test.nhdr).

NRRD0004
type: short

dimension: 3

sizes: 622 642 1085

spacings: 0.02 0.02 0.02

byteskip: 3195

data file: ./PERCIVAL_370.AIM

endian: big

encoding: raw

If you drag and drop the nhdr file into Slicer, you should see the sample data being loaded (this is a fairly large dataset, may take sometime). If this is the first time you will be working with this dataset, you are done. However, if you have additional data (e.g., landmarks) collected outside of Slicer, it is important to check whether the coordinate systems are consistent between two different programs. Dr. Percival also provided a set of landmarks coordinates that was collected from this specimen using Amira. If you drag and drop the landmarks.fcsv into Slicer, you will see that landmarks do not correctly line up.

We need to identify the coordinate system the original landmarks were collected, and describe in the NHDR file. This step will involve some troubleshooting (e.g., collecting a few of the landmarks in Slicer, and comparing reported coordinates.) In this case, all positive values of the original landmark coordinates suggested to me that it is likely the original coordinate system was Right-Anterior-Superior (or RAS in short). I modified the header file to include this as the space tag. One other difference is that you need to remove the spacings tag, and then redefine it as the space directions.

NRRD0004
type: short
dimension: 3
sizes: 622 642 1085
byteskip: 3195
data file: ./PERCIVAL_370.AIM
endian: big
encoding: raw
space: RAS
space directions: (0.02,0,0) (0,0.02,0) (0,0,0.02)

If you change the content of the NHDR file with the code above, and reload your volume and render, now you should see all the landmarks line up correctly. It is always good to familiarize yourself with the coordinate systems of the digitization program you are using. You can find a discussion of coordinate systems here.

I

Saving and exchanging data with Slicer

Any dataset loaded into or derived from existing data (e.g., segmentation) becomes part of the Slicer ‘scene’. In an active project, where you might be doing segmentation, measurements, or landmarking, scene may get complex quickly. Saving (or rather forgetting to save) these different components is a typical point of frustration for the end user. Here, I will use one of the nightly builds (r27390) of Slicer to demonstrate the complex Save As dialog box.

First use the Sample Data module to obtain the MR head dataset, and visualize in 3D renderer using the Volume Rendering Preset MR-Default. Then, place some landmarks using the Fiducial tool, and finally take 3D distance measurement. This will generate enough components to create a semi-complex scene like this:

Now, go to the File->Save as to see the File Save Dialog box, which looks like this for my scene:

As you can see there is a volume (MR-head.nrrd), a volume rendering property (MR-Default.vp), a markups list that contain the four landmark (F.fcsv), and a measurement annotation file (M.acsv) that contain the 3D distance. Notice that all files, except the volume has a check mark next to it. That’s because they have not saved before. The reason MR-head does not have a check mark, because it hasn’t been changed by the user since the last time it is loaded. So, any file that’s previously saved in the session, and remain unchanged will be not have a check mark in the save as dialog box, next time you invoke the save command. You can manually change these. Every time you are saving your scene, make sure the files you care about have a check mark next to them.

A complex scene may have tens of components. If you find yourself in a situation that you need to share your scene and all of its component, or looking for a convenient option to move data from one computer to the next, consider trying the medical reality bundle:

It is the rightmost icon (the gift packaged one) on the top row. As you click, it grays out all the fields, and only lets you specify the name of the MRB file and its location. In essence, MRB is a self-contained zip-file with all the data loaded into the scene. Once it is saved, you can send the mrb file to your collaborator, or move it another computer without having to worry about where each of those component files are located on your hard drive. You can drag’n’drop MRB files into Slicer, and it will automatically load the scene.

The downside is you will have to unpack the MRB, if you need to access the components directly (e.g., you want to read your landmark coordinates into R directly).