surface-apply-warpfield and LIA -> RAS warps about workbench HOT 6 CLOSED

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.

from workbench.

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.

from workbench.

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.

from workbench.

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?

from workbench.

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

from workbench.

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.

from workbench.