Co-Registering DWI Problem: DWI Sequences Are Not Overlaid

Dear SCT Team

I have been working through your excellent single subject walkthrough, from the website. We have just started using your Spine Generic Protocol. However I have encountered an issue when registering my DWI sequences (which hadn’t been a problem with the MT sequences):

Having spent some time looking at why, I think this is because the DWI sequences are not correctly orientated / overlaid. Principally, as when viewed in FSLEyes, the DWI sequence is upside down and mislocated.

I have experimented using -setorient to see if I can adjust this, but without success (at least visually).



Raw images avaliable here: Transfer - Dropbox

I have explored using -setorient to try an adjust these but without success.

Spinal Cord Toolbox (5.4)

sct_image -i 32900_0003.nii -getorient


Spinal Cord Toolbox (5.4)

sct_image -i 32900_0004.nii -getorient


sct_image -i 32900_0004.nii -setorient ASR -o RAS_0004_ASR.nii

Spinal Cord Toolbox (5.4)

sct_image -i 32900_0004.nii -setorient ASR -o RAS_0004_ASR.nii

Here is a copy of my script. I appreciate there are redundancies in there, but reflects more my experimentation with SCT than planned pipeline. Images in this script have been renamed as per your tutorial by sequence, and the T1/2/2s all also converted to 3d, but the images above are the raw NiFti files. (8.2 KB)

Look forward to your guidance. Thanks in advance.

Hi @Benjamin_Davies,

Thank you for taking the time to post and share your experiences with SCT! We’ll be happy to help. :slight_smile:

I’d like to try to reproduce the results you’ve shown here. But, I just want to make sure I’m understanding exactly what steps were taken. Looking at your sample script, I see the following steps:

  • Registered T2 data to the PAM50 template (where 32900_0003.niit2.nii?)

    cd data/t2
    sct_maths -i t2.nii -mean t -o t2.nii
    sct_propseg -i t2.nii -c t2 -qc /Users/benjamindavies/IMAGE_DCM/01_Biomechanics_SS/data/qc 
    open "/Users/benjamindavies/IMAGE_DCM/01_Biomechanics_SS/data/qc/index.html"
    sct_label_vertebrae -i t2.nii -s t2_seg.nii -c t2 -qc /Users/benjamindavies/IMAGE_DCM/01_Biomechanics_SS/data/qc 
    sct_label_utils -i t2_seg_labeled.nii -vert-body 2,5 -o labels_vert.nii.gz
    sct_register_to_template -i t2.nii -s t2_seg.nii -l labels_vert.nii.gz -c t2 -qc /Users/benjamindavies/IMAGE_DCM/01_Biomechanics_SS/data/qc
  • Co-registered DWI data to the PAM50 template (where 32900_0004.niidmri.nii?)

    cd ../dmri
    sct_dmri_separate_b0_and_dwi -i dmri.nii -bvec bvecs.txt
    sct_deepseg_sc -i dmri_dwi_mean.nii -c dwi -qc ~/qc_singleSubj
    sct_create_mask -i dmri_dwi_mean.nii -p centerline,dmri_dwi_mean_seg.nii -f cylinder -size 35mm
    sct_dmri_moco -i dmri.nii -m mask_dmri_dwi_mean.nii -bvec bvecs.txt \
                  -qc ~/qc_singleSubj -qc-seg dmri_dwi_mean_seg.nii
    sct_deepseg_sc -i dmri_moco_dwi_mean.nii -c dwi -qc ~/qc_singleSubj
    ## Unable to extract DWI metrics from all regions - not sure issue, doesn't seem to coregister, having seen what should happen with their example data.
    sct_register_multimodal -i "${SCT_DIR}/data/PAM50/template/PAM50_t1.nii.gz" \
                            -iseg "${SCT_DIR}/data/PAM50/template/PAM50_cord.nii.gz" \
                            -d dmri_moco_dwi_mean.nii \
                            -dseg dmri_moco_dwi_mean_seg.nii \
                            -initwarp ../t1/warp_template2anat.nii.gz \
                            -initwarpinv ../t1/warp_template2anat.nii.gz \
                            -owarp warp_template2dmri.nii.gz \
                            -owarpinv warp_dmri2template.nii.gz \
                            -param step=1,type=seg,algo=centermass:step=2,type=seg,algo=bsplinesyn,slicewise=1,iter=3 \
                            -qc ~/qc_singleSubj
  • Then, I’m guessing the “T2+DWI” overlay image from your post was generated by applying both resulting warping fields to the DWI data (i.e. “DWI -> template” plus “template -> T2”) then displaying the overlaid image in FSLeyes?

If my understanding is correct, then I think I may need additional files to be able to reproduce your results:

  • I notice the 4D DWI data was preprocessed using the option -bvec bvecs.txt, but I don’t think bvecs.txt was included in the Dropbox?
  • I also notice that the DWI data was coregistered with T1 initialization (e.g. -initwarp ../t1/warp_template2anat.nii.gz), but I don’t think the T1 data was included in the Dropbox?

If you could please provide all of the files/commands that are needed to reproduce your results, I will be happy to take a look. :slight_smile:

Kind regards,

Thanks Joshua, and apologies for the missing pieces.

Hopefully everything should now me this folder: Transfer - Dropbox

I have extracted the relevant parts from my script, to illustrate my problem. I have also followed this with the same script but processing the single subject data from, which led me to the conclusion the issue resides with my images as opposed to the syntax.

Script is also here, as dropbox link will expire. (4.5 KB)

Thanks for looking at this for me.

Having looked at your data, I agree with your assessment above.

As you’ve found out, -setorient cannot fix this problem, because:

  1. “Orientation” here (e.g. RAS, ASR, etc.) is only for interpreting the (X, Y, Z) voxel coordinates in terms of RL/AP/SI directions. In other words, “RAS orientation” only tells you that “X == L→R”, “Y == P→A”, and “Z == I→S”.
  2. But, separately, the image has “affine matrices” that apply specific translations/rotations/scaling etc. to the data array to turn the voxel coordinates into real-world scanner coordinates. (More information on this page and the bottom of this page.)

So, when -setorient is run, it is modifying 1., when I believe the problem lies with 2.

In theory, it might be possible to modify the affine matrix to apply a different set of reflections/translations to fix the misalignment.

But, it’s tricky for me to recommend a specific fix, because it’s hard for me to know where exactly the misalignment originated from (acquisition, processing the raw data, etc.).

@jcohenadad may be able to chime in with additional insight, though, as he is much more knowledgeable about the acquisition and processing of raw MRI data than I am.

Here are some small demos that should hopefully help with the explanation:

Aside 1: Additional information about the affine matries of your DWI data

The affine matrices for your DWI data can be viewed using the command:

sct_image -header -i 32900_0004.nii

The relevant part of the output is:

qto_xyz:1	-0.895833 0.000000 -0.000000 38.655224 
qto_xyz:2	0.000000 -0.891558 -0.487915 17.852997 
qto_xyz:3	0.000000 0.087418 -4.976137 105.531113 
qto_xyz:4	0.000000 0.000000 0.000000 1.000000 


sto_xyz:1	-0.895833 0.000000 0.000000 38.655224 
sto_xyz:2	0.000000 -0.891558 -0.487914 17.852997 
sto_xyz:3	0.000000 0.087418 -4.976137 105.531113 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 

These arrays take the form:


Where the upper-left 3x3 matrix (M) is applying rotations and scaling to the data array, while the vector (a, b, c) is applying a translation (source).

Aside 2: A demonstration of modifying the affine of your DWI data

As a small demo, we can modify the affine matrix directly, e.g. by changing the translation of the SI axis using this Python code:

import nibabel as nib
import numpy as np

image = nib.load("32900_0004.nii")

affine = image.header.get_best_affine()
# (since the image is RAS, the SI axis == the Z coordinate, so we modify the 3rd translation)
transformation = np.array([[0,  0,  0,   0],
                           [0,  0,  0,   0],
                           [0,  0,  0, -50],
                           [0,  0,  0,   0]])
affine_modified = affine + transformation

image_modified = nib.Nifti1Image(image.get_fdata(), affine_modified), "32900_0004_modified.nii")

This would result in the following shift (red: before, blue: after):

But, I believe this is quite a dangerous way to go about things without knowing the root cause of why and how your data became misaligned in the first place.

Kind regards,

Thanks Josh… I was worried you were going to agree with me!

I attach the imaging protocol we are running - it was meant to be the Spine Generic Protocol, but perhaps we have ported it incorrectly?

Look forward to Julien’s thoughts, (and hopefully some sort of work around).

Ben Davies Spinal 2019-03-22_ZOOMit.pdf (95.8 KB)

sorry i’m late to the party. The root cause of the issue is indeed the wrong orientation of the DWI. I advise against ‘playing’ with manually reorienting the DWI, and instead fix the problem at the source. The problem could have been introduced during the DICOM to NIFTI conversion. I tried downloading the raw data by the dropbox link has expired. @Benjamin_Davies would you be able to send me another link?

1 Like

Thanks Julien - Spot on.

I have switched to a different DICOM to NIFTI converter (dcm2niix), which has resolved the problem.

So simple - :man_facepalming:

Thanks for your time, and of course the amazing platform in general.