Anatomical orientation change when converting from MHD/RAW to NRRD

Beginner Questions
, ,
1

Hi,

I am trying to convert a series of MHD/ZRAW file-pairs to a single NRRD file that contains both the header meta-data and the array data. However, I notice that when I convert the files the orientation does not seem to be properly considered in the conversion.

For example, here is a snippet of the MHD file. The physical orientation is right-anterior-inferior.

ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = True
CompressedDataSize = 263
TransformMatrix = 1 0 0 0 1 0 0 0 1
Offset = -142.356 7.8968 1739
CenterOfRotation = 0 0 0
AnatomicalOrientation = RAI
ElementSpacing = 0.808 0.808 1
DimSize = 31 31 26
ElementType = MET_UCHAR
ElementDataFile = 1.2.392.200036.9116.2.6.1.48.1215545712.1253630630.477188_1_0.zraw

After conversion to NRRD, here is the new header information. The orientation is now listed as left-posterior-superior, however the origin/offset are the same between the two files, which shouldn’t be true, right?

NRRD0004
# Complete NRRD file format specification at:
# http://teem.sourceforge.net/nrrd/format.html
type: unsigned char
dimension: 3
space: left-posterior-superior
sizes: 31 31 26
space directions: (0.80800000000000005,0,0) (0,0.80800000000000005,0) (0,0,1)
kinds: domain domain domain
encoding: raw
space origin: (-142.35599999999999,7.8967999999999998,1739)
ITK_InputFilterName:=MetaImageIO

For completeness, I am using the python binding to SimpleITK via R. Here is the basic code:

library(reticulate)
sitk <- import('SimpleITK')
img <- sitk$ReadImage('test.mhd')
sitk$WriteImage(img, 'test.nrrd')
1 Like
2

Hello @mattwarkentin,

I think this may just be an ITK thing in the mhd conventions (very old explanation here). Are you seeing a difference when loading the two images in ITK-SNAP/Slicer? If not, then it is just sins from the past. If yes then might require additional digging.

As a side note, you can use SimpleITK directly in R. The devtools installer is found here, will compile the toolkit on your system (for now only linux/OSX).

2 Likes
3

Hi @zivy,

Thanks for the reply. I don’t see any difference when I load the images into Slicer. Perhaps I am misunderstanding, but I was under the impression that if you have a 3D array (like in this example), the origin/offset indicates the physical location of the array voxel [0, 0, 0]. But doesn’t the image orientation (e.g. RAI vs. LPS) let us know which “corner” of the array is the [0, 0, 0] voxel? Or is that determined by the directional cosine matrix? Thanks for your help.

Thanks for suggesting the R version of SimpleITK. I am aware of the SimpleITK installer for R and I do intend to use it at some point soon. But for now I find that using the python binding is fairly frictionless and there seems to be more python example code available which makes it easier to re-factor the code for my own uses.

4

The original sin was in the naming given in the meta-image, as the explanation in the reference page says: “It seems unfortunate to have a letter code selection for axes that is opposite to that used by DICOM and hence the scanner manufacturers.”…“I take this to mean R implies the fastest varying axis runs from Right to Left. DICOM would give this the code L,”

So what mhd calls RAI would be LPS in DICOM and any other file format that follows the DICOM definition. That is why I referred to it as “sins from the past”. The format has been used in the wild for enough time making it too late to fix/modify (many files out there using this naming convention).

2 Likes
5

Thank you very much for this clarification!