surface-apply-warpfield and LIA -> RAS warps

[dasturge]

I have freesurfer files which are in LIA orientation, and a final space template in RAS. My pipeline looks something like this

Attempt 1: go straight from LIA using fsl tools...

mri_convert -ot nii brain.mgz T1w.nii.gz flirt -in T1w.nii.gz -ref MNI152_T1_1mm.nii.gz -omat acpc.mat -out T1w_acpc.nii.gz ${FSLDIR}/bin/flirt -interp spline -dof 12 -in T1w_acpc.nii.gz -ref MNI152_T1_1mm.nii.gz -omat acpc2MNILinear.mat -out T1w_to_MNILinear.nii.gz ${FSLDIR}/bin/fnirt ... ... --out=acpc2standard.nii.gz ${FSLDIR}/bin/invertwarp --out=standard2acpc.nii.gz

sort of standard stuff as in HCP, only the beginning brain is in LIA. Now here's the key that I think should work, but isn't working...

we concatenate the acpc.mat to create a warpfield which goes straight from freesurfer to MNI, then do the opposite to get the inverse warp...

convertwarp --relout --rel --ref=T1w.nii.gz --premat=acpc.mat --warp1=acpc2standard.nii.gz --out=fs2standard.nii.gz convert_xfm -omat inverse_acpc.mat -inverse acpc.mat convertwarp --relout --rel --ref=MNI152_T1_1mm.nii.gz --postmat=inverse_acpc.mat --warp1=standard2acpc.nii.gz --out=standard2fs.nii.gz

testing both of these concatenated transforms, fs2standard.nii.gz, standard2fs.nii.gz on the anatomical volumes gives the correct outputs you would expect.

However, here: wb_command -surface-apply-warpfield outputs2/T1w/fsaverage_LR32k/L.white.mytest32k_fs_LR.surf.gii standard2fstest.nii.gz .L.white_test.native.surf.gii -fnirt fs2standardtest.nii.gz

Resulting midthickness after application:

Attempt 2: Start with RAS niftis

I do this identically to above, only, to start with the freesurfer image:

mri_convert --in_orientation LIA --out_orientation RAS -ot nii brain.mgz T1w.nii.gz

then we have a RAS -> RAS acpc.mat at least...

here I just have the white matter and the T1w2MNINonlinear image...

It looks like this might have applied the warp correctly but there's a translational offset? Not easy to tell.

Hoping for thoughts/experience in the matter.

Thank you.

[coalsont]

We haven't extensively tested our warpfield reading against unusual orientations. Is it just the voxel order that is different, or is the nifti spatial +Y direction no longer anterior/posterior?

The choice of --ref in the convertwarp commands looks odd to me, as it sets the voxel space for the warpfield output (which is in the space of the output image of applying the concatenated transform). If you provide a different input or output voxel grid than the FSL warpfield/affine was "made with", things can get weird, as FSL ignores parts of the nifti spatial information - the fact that the FSL resampling "looks right" could actually be because it ignored a difference in spatial orientation in the headers. When you tell wb_command what the intended input voxel space for FSL is (this is the real purpose of asking for the forward warpfield, any volume with the right header would work), if it doesn't match the actual voxel space of the input in the FSL command, it will do something different.

If you can upload the files somewhere we can look at them, that might help us. If you don't want the files to be public, we can work through email.

[coalsont]

Also, freesurfer has an internal "RAS" offset in its coordinate systems, which is a difference between the coordinates it puts in its surface files, and the coordinates they should actually be to align with nifti voxel coordinates. In newer freesurfer, mris_convert should have an option (--to-scanner I think) to fix this issue when converting surfaces to gifti.

Workbench expects all coordinates to be in the same single coordinate system, using full nifti headers, etc.

[dasturge]

Okay, it looks like I accidentally read the docs for invwarp for the --ref flag, thanks for catching that. Makes sense to me. After fixing that, Attempt 2 works! So it is important to reorient the anatomical data to RAS+ prior to calculating that initial acpc.mat.

[coalsont]

Changing the --ref could significantly change what your Attempt 1 does, and it would be nice to know whether our code to read FSL warps behaves correctly for odd orientations. Can you give that another shot too, for my curiosity?

[dasturge]

Oh, surprisingly, both methods work, despite the difference in orientations of the initial T1w images. So it looks like wb_command is robust to these differences provided that the fsl forward and inverse warps have the proper target spaces.

I wasn't sure how to answer your question about the Y+ direction in the nifti versus the voxel order. According to the qform, y is S->I, and the system is left-handed:

qto_xyz:1      -1.000000  0.000000  -0.000000  128.000000
qto_xyz:2      0.000000  0.000000  1.000000  -128.000000
qto_xyz:3      -0.000000  -1.000000  -0.000000  128.000000
qto_xyz:4      0.000000  0.000000  0.000000  1.000000
qform_xorient  Right-to-Left
qform_yorient  Superior-to-Inferior
qform_zorient  Posterior-to-Anterior

[coalsont]

Cool, thanks for testing.

Yeah, that question was hard to phrase - what I meant was, when viewing your original T1w image in wb_view, whether the brain was in the "usual" orientation (whether the axial view mode actually showed normal axial slices), or if it was flipped on end or side or something.

The nifti sform/qform give several options for encoding exactly the same logical image (by both reordering its voxels and changing the header to match), but it is also possible for the subject's head itself to be in an unusual orientation (like if you scan a primate chest-down, chin up, looking through the bore), or for an image to be rotated/flipped to result in a similar effect. I was asking which of these situations was the case with your original T1w image.