Aligning PET image with CT

Support
1

Hi everyone,

This may seem like a simple question but I am having trouble understanding how to do it correctly on 3D Slicer.

I have a CT image with the following .mhd file description:

ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = False
TransformMatrix = 1 0 0 0 1 0 0 0 1
Offset = 91.654800415039062 140.35000610351562 -140.18800354003906
CenterOfRotation = 0 0 0
AnatomicalOrientation = LPI
ElementSpacing = 2.2100000381469727 2.2100000381469727 2.2100000381469727
DimSize = 125 122 93
ElementType = MET_FLOAT
ElementDataFile = ct_pet_y90.raw

However, on Volume Information on 3D Slicer, a different Image offset and matrix show up:

image
image452×286 78 KB

I am trying to align this CT image with my obtained reconstruction PET image, which has this image info:

image
image443×285 76.5 KB

The offset on the .hdr headfile says that it’s zero. However, when opening it on 3D Slicer it shows different values, as you can see.

I tried applying a Linear Transformation, but I still can’t seem to get them aligned correctly. Can someone please help me do this? I would really appreciate any insights.

Thank you!

Greetings,
Beatriz

2

Based on the fact that instead of DICOM you use a research file format, I assume that these two images do not come from a PET-CT machine (that ensures that the two images have the same frame of reference), but two different machines. In that case you’ll need to align the two volumes yourself. However, the two modalities are very different, and manual alignment may not be possible without some landmarks.
Using the sliders in the Transforms module is very inconvenient for this. I suggest using the recently added transform interactions. You can turn it on in the Data module after right-clicking the eye in the row of the volume you want to move:

image
image277×134 3.32 KB

(We should really update this section to contain this information: Registration — 3D Slicer documentation)

By the way the different origin is simply due to the LPS-RAS conversion. Read about this here.

1 Like