Does sct_register_multimodal use image orientation from the headers?

SCT
1

Dear SCT developers,

I would like to clarify how sct_register_multimodal works. We have structural and functional images acquired with different orientation: sagittal and axial oblique respectively. During the registration step, we are providing the cord segmentations for both images, using centerMass as an algorithm and setting slicewise to 1. It works pretty well.

But I am worried that trying to co-register an oblique volume using 2D transformations only may be sub-optimal. The help page states that:

Hence, this function assumes that orientation of the destination image is axial (RPI). If you need to register two volumes with large deformations and/or different contrasts, it is recommended to input spinal cord segmentations (binary mask) in order to achieve maximum robustness.

My question is whether sct_register_multimodal uses header information about the oblique orientation of the destination image while calculating the transformation? Or should we resample those images to the same orientation to make the registration task easier?

Here are our current registration parameters:

sct_register_multimodal -i T2w.nii.gz -d EPI_combinedRUNs_Spine_moco_mean.nii.gz -iseg T2w_seg.nii.gz -dseg EPI_combinedRUNs_Spine_Mean_seg.nii.gz -param step=1,type=seg,algo=centermass,metric=MeanSquares,iter=5,slicewise=1

Thank you!

2

My question is whether sct_register_multimodal uses header information about the oblique orientation of the destination image while calculating the transformation?

Great question! Yes it does. To give you more details, this is done at step=0 (usually hidden for the user, but could be configured using the -param flag if you wish to input manual labels as a pre-registration). If you look closely at your terminal output you will see a mention of “step=0”, which uses the NIfTI’s header qform matrix of the source and destination image to compute an affine (rigid) transformation, that is then used as a starting point for “step=1”.

That being said, the subsequent steps (1, 2, etc.) assume that the 3rd dimension is in the superior-inferior (S-I) axis, such that some of the algorithms that are regularized along the S-I direction will work optimally (eg: slicereg, centermass, etc.). So just make sure that your destination image’s 3rd dimension corresponds to the S-I axis. If it is not the case, you can first run:

sct_image -i DEST -setorient RPI -o DEST_RPI

And then run your registration.