sform not preserved when running sct_warp_template

[jcohenadad]

Description

When applying a transformation to bring the PAM50 to the native space of an image using sct_warp_template, the sform field is not preserved (all zeros). We should ensure the qform is copied onto the sform for the generated PAM50 files.

Steps to reproduce

1. Download and extract the following images: javier_20210226.zip

2. Run the following commands:

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

3a. (Optional) Open label/template/PAM50_wm.nii.gz in FSLeyes (version 0.34.2) to see the message "Displaying images with different orientations/fields of view"

3b. (Optional) Run flshd label/template/PAM50_wm.nii.gz to see the following result:

Result of fslhd

filename	PAM50_wm.nii.gz

sizeof_hdr	348
data_type	FLOAT64
dim0		3
dim1		21
dim2		51
dim3		147
dim4		1
dim5		1
dim6		1
dim7		1
vox_units	mm
time_units	Unknown
datatype	64
nbyper		8
bitpix		64
pixdim0		-1.000000
pixdim1		1.550000
pixdim2		1.458333
pixdim3		1.458333
pixdim4		0.000000
pixdim5		0.000000
pixdim6		0.000000
pixdim7		0.000000
vox_offset	352
cal_max		0.000000
cal_min		0.000000
scl_slope	1.000000
scl_inter	0.000000
phase_dim	0
freq_dim	0
slice_dim	0
slice_name	Unknown
slice_code	0
slice_start	0
slice_end	0
slice_duration	0.000000
toffset		0.000000
intent		Unknown
intent_code	0
intent_name	
intent_p1	0.000000
intent_p2	0.000000
intent_p3	0.000000
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 
sform_xorient	Unknown
sform_yorient	Unknown
sform_zorient	Unknown
file_type	NIFTI-1+
file_code	1
descrip		
aux_file	

[joshuacwnewton]

I believe this issue is due to our call to the ANTs binary, because ITK (and by extension ANTs) ignores the sform. See: ANTsX/ANTs#333 (comment).

https://github.com/neuropoly/spinalcordtoolbox/blob/d25e4ce12264ff75e5476fffaf7606342a459b87/spinalcordtoolbox/scripts/sct_warp_template.py#L119-L127

However, I think we may have already addressed this problem inside our wrapper, sct_apply_transfo, in PR #2400.

https://github.com/neuropoly/spinalcordtoolbox/blob/d25e4ce12264ff75e5476fffaf7606342a459b87/spinalcordtoolbox/scripts/sct_apply_transfo.py#L291-L294

https://github.com/neuropoly/spinalcordtoolbox/blob/d25e4ce12264ff75e5476fffaf7606342a459b87/spinalcordtoolbox/image.py#L373-L384

This would properly copy over the sform from the reference image (which in this case is PARESP_00003__003_eddy_md_crop.nii).

[joshuacwnewton]

The reason the fix from #2400 didn't get applied here is because in #2175, the call to sct_apply_transfo was replaced with a direct call to isct_antsApplyTransform.

So, switching back to sct_apply_transfo may cause a ~2.5m slowdown (see that PR).

[jcohenadad]

The reason the fix from #2400 didn't get applied here is because in #2175, the call to sct_apply_transfo was replaced with a direct call to isct_antsApplyTransform.

So, switching back to sct_apply_transfo may cause a ~2.5m slowdown (see that PR).

great catch! OK, so my suggestion would be to switch back to sct_apply_transfo and fix the speed problem there

[joshuacwnewton]

my suggestion would be to switch back to sct_apply_transfo and fix the speed problem there

Agreed. We use sct_apply_transfo in many places (registration, etc.) so I'm wondering if we're seeing that 2.5m slowdown in elsewhere, too. 😨

I may use 2 PRs here: one for switching the calls, and a second for the speed problem, just because that might be a more involved investigation.

[joshuacwnewton]

Aha! I've just realized that this issue is connected to the unset sform noticed a while back by @cfhammill in #2858 (comment).

Somewhere inside test_straighten there is an image generated with sform =

[[0. 0. 0. 0.]
 [0. 0. 0. 0.]
 [0. 0. 0. 0.]
 [0. 0. 0. 1.]]