Images with different orientations/fields of view

Dear experts,

When I warp the template to the native space, the PAM50 atlas seems different from the DWI images and segmentation mask. I think that this mismatch between PAM50 and the DWI images is affecting the statistics (sct_extract_metrics).
I used sct-4.3.

I used the commands:

sct_register_multimodal -i ../${base}-T2_SAG_resize_seg_labeled.nii -d ${base}_eddy_md_crop.nii -x nn -identity 1

sct_label_utils -i ${base}-T2_SAG_resize_seg_labeled_reg.nii -vert-body 1,10 -o ${base}_dmri_labels.nii.gz

sct_register_to_template -i ${base}_eddy_md_crop.nii -l ${base}_dmri_labels.nii.gz -s /home/jnavas/SPINALCORD/spine_masks/masks_reg_crop_fa/${base}_WholeSpine_Mask2_reg.nii.gz -c t1 -param step=1,type=seg,algo=slicereg,metric=MeanSquares: step=2,type=seg,algo=affine,metric=MeanSquares,gradStep=0.2: step=3,type=im,algo=syn,metric=MI,iter=5,shrink=2

sct_warp_template -d ${base}_eddy_md_crop.nii -w warp_template2anat.nii.gz -a 1 -s 1 -ofolder label

I really appreciate any help you can provide.

I also tried another parameters in the sct_register_to_template, such as:

sct_register_to_template -i ${base}_eddy_md_crop.nii -l ${base}_dmri_labels.nii.gz -s /home/jnavas/SPINALCORD/spine_masks/masks_reg_crop_fa/${base}_WholeSpine_Mask2_reg.nii.gz -c t1 -param step=1,type=seg,algo=centermassrot,smooth=0:step=2,type=seg,algo=columnwise,smooth=0,smoothWarpXY=2,iter=6

However, I have similar results.

Hi @Javier_Navas,

Image registration is completely image-dependent and should be resolved on a case-by-case basis (image resolution, contrast, noise, artefacts, etc.). So it is impossible for us to help without seeing the images. Would you be able to share them?

Cheers
Julien

All the images has the same resolution, however when I cropped them, the dimensions between becomes different.

How can I share the images? Can I attached them here?

whatever is easier for you. Zip and attach here, or if too large dropbox/gdrive, etc.

Here I attached the images of 2 subjects: the Mean Diffusivity, the mask of the DWI segmentation, and the dmri_labels.
With these images I run the sct_register_to_template. If you need more data let me know. Thanks in advance.

PARESP_00004__004_WholeSpine_Mask2_reg.nii.gz (1.4 KB) PARESP_00004__004_dmri_labels.nii.gz (5.2 KB) PARESP_00004__004_eddy_md_crop.nii (571.0 KB)
PARESP_00003__003_dmri_labels.nii.gz (5.6 KB) PARESP_00003__003_eddy_md_crop.nii (615.3 KB) PARESP_00003__003_WholeSpine_Mask2_reg.nii.gz (2.0 KB)

Hi Javier,

Given that the cord segmentation is slightly larger than the cord itself (oversegmentation), I would only rely on the cord segmentation to do the cord alignment and get its orientation (rotatino) on a slice-by-slice basis. Then, I would switch to the image-based registration. Given the relatively small appearance of the cord compared to the PAM50 template, I would increase slightly the number of iterations (but not too much, given that the SyN algorithm is poorly regularized). I find that the following configuration works pretty well:

sct_register_to_template -i PARESP_00003__003_eddy_md_crop.nii -s PARESP_00003__003_WholeSpine_Mask2_reg.nii.gz -l PARESP_00003__003_dmri_labels.nii.gz -c t2 -param step=1,type=imseg,algo=centermassrot,rot_method=pcahog:step=2,type=im,algo=syn,metric=cc,iter=5,smooth=0,slicewise=0 -r 0 -qc qc-optimization

Here is the result (click on the image to see the toggling between the dmri image and the registered PAM50-T2 image):
reg_iter10

Compared with the default parameters:
reg_default

And here is a QC report that shows all my investigations: qc-optimization.zip (2.4 MB)

Cheers,
Julien

Thanks for your work. The registration is obviously improved. However, when I run the sct_warp_template, with the -w warp_template2anat obtained from your script, I obtain the PAM50 atlas with a different field of view (or orientation), as informed fsleyes. I tried to use a different mask, but the results were similar. The template2anat.nii was correct, but the problem appears when I run the sct_warp_template.

These patients have severe atrophy in the spinal cord; that’s why it seems small compared to the template.

I do not know if this mismatch could affect the results when I extract the metrics for each label and each WM atlas pathway

Here I attached the new segmentation masks:

PARESP_00003__003-T2_SAG_resize_seg_reg_bin.nii.gz (3.0 KB) PARESP_00004__004-T2_SAG_resize_seg_reg_bin.nii.gz (2.9 KB)

Hi,

I don’t have that problem, see below:

To be able to help you, I need to know exactly the command you ran and the images you used.

I used this script:

‘sct_warp_template -d ${base}_eddy_md_crop.nii -w …/warp_template2dmri.nii.gz -a 1 -s 1 -ofolder label’

As I told you, the template2anat.nii do not seems to show this problem, however when I apply the warp_template2dmri.nii.gz appear this message. It could be a problem to extract the dwi-related metrics?

why are you using …/warp_template2dmri.nii.gz considering that the transformation to bring the PAM50 to the DWI space is warp_template2anat?

also, it is not clear to me how the file …/warp_template2dmri.nii.gz was generated.

In order for me to reproduce your error, can you please write exactly all the commands that you ran. I should be able to do a copy/paste of your commands and observe your results.

sct_register_to_template -i PARESP_00003__003_eddy_md_crop.nii -s PARESP_00003__003_WholeSpine_Mask2.nii.gz -l diff/PARESP_00003__003_dmri_labels.nii.gz -c t2 -param step=1,type=imseg,algo=centermassrot,rot_method=pcahog:step=2,type=im,algo=syn,metric=cc,iter=5,smooth=0,slicewise=0 -r 0 -qc qc-optimization; 

mv warp_template2anat.nii.gz warp_template2dmri.nii.gz

mv warp_anat2template.nii.gz warp_dmri2template.nii.gz

sct_warp_template -d PARESP_00003__003_eddy_md_crop.nii -w warp_template2dmri.nii.gz -a 1 -s 1 -ofolder label

I don’t see any file called “PARESP_00003__003_WholeSpine_Mask2.nii.gz” in the files you shared. To make sure you and I are testing your code on the same data, could you please zip all the necessary files into a single zip package and upload it here. thanks

Sorry, I just tried with other masks

PARESP_00003__003_WholeSpine_Mask2.nii.gz (1.5 KB)

Still working fine on my end:

Let’s just make 100% we are using exactly the same data. Could you please download/unzip this package: javier_20210226.zip (542.8 KB)

Then, go to the folder and run:

sct_register_to_template -i PARESP_00003__003_eddy_md_crop.nii -s PARESP_00003__003_WholeSpine_Mask2.nii.gz -l PARESP_00003__003_dmri_labels.nii.gz -c t2 -param step=1,type=imseg,algo=centermassrot,rot_method=pcahog:step=2,type=im,algo=syn,metric=cc,iter=5,smooth=0,slicewise=0 -r 0 -qc qc-optimization;
mv warp_template2anat.nii.gz warp_template2dmri.nii.gz
mv warp_anat2template.nii.gz warp_dmri2template.nii.gz
sct_warp_template -d PARESP_00003__003_eddy_md_crop.nii -w warp_template2dmri.nii.gz -a 1 -s 1 -ofolder label

Could you please also copy/paste the output of:

sct_check_dependencies
fsleyes --version

Spinal Cord Toolbox (5.1.0)

sct_check_dependencies

SCT info:

  • version: 5.1.0
  • path: /home/jnavas/sct_5.1.0
    OS: linux (Linux-5.4.0-66-generic-x86_64-with-debian-bullseye-sid)
    CPU cores: Available: 8, Used by ITK functions: 8
    RAM: Total: 31993MB, Used: 824MB, Available: 30659MB
    Check Python executable…[OK]
    Using bundled python 3.6.12 |Anaconda, Inc.| (default, Sep 8 2020, 23:10:56)
    [GCC 7.3.0] at /home/jnavas/sct_5.1.0/python/envs/venv_sct/bin/python
    Check if data are installed…[OK]
    Check if colored is installed…[OK] (1.4.2)
    Check if dipy is installed…[OK] (1.3.0)
    Check if futures is installed…[OK]
    Check if h5py is installed…[OK] (2.10.0)
    Check if Keras (2.1.5) is installed…[OK] (2.1.5)
    Check if ivadomed (2.6.1) is installed…[OK] (2.6.1)
    Check if matplotlib is installed…[OK] (3.3.3)
    Check if nibabel is installed…[OK] (3.2.1)
    Check if numpy is installed…[OK] (1.19.5)
    Check if onnxruntime (1.4.0) is installed…[OK] (1.4.0)
    Check if pandas is installed…[OK] (1.1.5)
    Check if psutil is installed…[OK] (5.8.0)
    Check if pyqt5 (5.11.3) is installed…[OK] (5.11.3)
    Check if pytest is installed…[OK] (6.2.1)
    Check if pytest-cov is installed…[OK] (version = ‘2.11.1’)
    Check if raven is installed…[OK]
    Check if requests is installed…[OK] (2.25.1)
    Check if requirements-parser is installed…[OK] (0.2.0)
    Check if scipy is installed…[OK] (1.5.4)
    Check if scikit-image is installed…[OK] (0.17.2)
    Check if scikit-learn is installed…[OK] (0.24.1)
    Check if tensorflow (1.5.0) is installed…[OK] (1.5.0)
    Check if torch (1.5.0+cpu) is installed…[OK] (1.5.0+cpu)
    Check if torchvision (0.6.0+cpu) is installed…[OK] (0.6.0+cpu)
    Check if xlwt is installed…[OK] (1.3.0)
    Check if tqdm is installed…[OK] (4.56.0)
    Check if transforms3d is installed…[OK] (0.3.1)
    Check if urllib3 is installed…[OK] (1.26.2)
    Check if pytest_console_scripts is installed…[OK]
    Check if pytest-xdist is installed…[OK] (2.2.0)
    Check if spinalcordtoolbox is installed…[OK]
    Check ANTs compatibility with OS …[OK]
    Check PropSeg compatibility with OS …[OK]
    Check if DISPLAY variable is set…[OK]
    Check if figure can be opened with PyQt…[OK]

fsleyes/FSLeyes version 0.34.2

thanks, and what is the result of the processing with the data and commands i listed here: Images with different orientations/fields of view ?

@Javier_Navas ah! I found out what the problem was! My FSLeyes version (0.31) was older than yours (0.34.2), and it did not show the “Displaying images with different orientations/fields of view” message.

I have upgraded FSLeyes to 0.34.2 and I confirm that I do see this message. Investigating further, I do notice a discrepancy between the input image and the template for the qform/sform:

PARESP_00003__003_eddy_md_crop.nii

qform_name	Aligned Anat
qform_code	2
qto_xyz:1	-1.549350 0.010756 -0.040836 24.244717 
qto_xyz:2	0.000000 1.410237 0.371441 -75.029106 
qto_xyz:3	-0.044884 -0.371286 1.409645 -89.249001 
qto_xyz:4	0.000000 0.000000 0.000000 1.000000 
qform_xorient	Right-to-Left
qform_yorient	Posterior-to-Anterior
qform_zorient	Inferior-to-Superior
sform_name	Aligned Anat
sform_code	2
sto_xyz:1	-1.549350 0.010757 -0.040839 24.244717 
sto_xyz:2	0.000000 1.410237 0.371441 -75.029106 
sto_xyz:3	-0.044887 -0.371286 1.409645 -89.249001 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 

label/template/PAM50_wm.nii.gz

qform_name	Scanner Anat
qform_code	1
qto_xyz:1	-1.549350 0.010756 -0.040837 24.244717 
qto_xyz:2	0.000000 1.410237 0.371441 -75.029106 
qto_xyz:3	-0.044884 -0.371286 1.409645 -89.249001 
qto_xyz:4	0.000000 0.000000 0.000000 1.000000 
qform_xorient	Right-to-Left
qform_yorient	Posterior-to-Anterior
qform_zorient	Inferior-to-Superior
sform_name	Scanner Anat
sform_code	0
sto_xyz:1	0.000000 0.000000 0.000000 0.000000 
sto_xyz:2	0.000000 0.000000 0.000000 0.000000 
sto_xyz:3	0.000000 0.000000 0.000000 0.000000 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 

Now, the good news is that this is not an issue for SCT pipelines, which relies on the qform only. So you can go ahead with your analyses. However, I do agree that we should ensure the sform is preserved. An issue has now been opened and we will fix it with high priority.

Thank you for your valuable feedback!

Thank you very much for your time and for your work!!

1 Like