3dDespike changing orientation

AFNI Message Board
1

Hello,

I’m getting an odd error with 3dDespike that I have not seen before. 3dDespike is changing the s and qform orientation matrices and orientations (which it shouldn’t be) without changing the actual order on disk resulting in the brain being incorrectly “flipped” in y and probably x too though I can’t tell that just by looking. After running, fslview shows the brain in the expected orientation in the view, but with the posterior of the brain labelled A and the front, P, with the obvious downstream problems. 3dDespike changing the orientation is quite unexpected behavior particularly without warning

I run fslreorient2std on the data first and have
qform_name Scanner Anat
qform_code 1
qto_xyz:1 2.174255 -0.000007 0.241726 -103.557930
qto_xyz:2 0.097798 1.998255 -0.889684 -65.314316
qto_xyz:3 -0.219557 0.890019 1.997506 -76.150925
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Left-to-Right
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 2.174256 0.000000 0.241725 -103.558640
sto_xyz:2 0.097791 1.998255 -0.889685 -65.313644
sto_xyz:3 -0.219558 0.890018 1.997506 -76.150742
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Left-to-Right
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior

The brain appears correct and labelled correctly in fslview. After 3dDespike I have:
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.174256 0.000005 0.241726 -103.558640
qto_xyz:2 -0.097796 -1.998255 -0.889684 -65.313644
qto_xyz:3 0.219557 -0.890019 1.997506 -76.150742
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.174256 -0.000000 0.241725 102.995598
sto_xyz:2 -0.097791 -1.998255 -0.889685 133.810699
sto_xyz:3 0.219558 -0.890018 1.997506 -12.457040
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Inferior-to-Superior

This occurs in both 19.1.00 and 20.2.14 (both with OpenMP). This did not occur in previous non-OpenMP versions run on essentially the same data, but I no longer have access to those on the servers I use. The sequence is one we’ve used for several studies without problem and the DICOM to nifti is using the same to3d scripts that I have used for years. I’m not sure what’s happening. The output of 3dDespike does not give any indication that its flipping things, just the generic complaint that the data is oblique.

Any ideas you might have would be appreciated.

Thanks

j

2

So you used FSL to reorient the data before giving it back to AFNI? Maybe FSL is passing along the old AFNI header embedded in the NIFTI header (something we are planning on preventing issues from).

Run “nifti_tool -rm_ext ALL” on it, try it again, and please let us know how it goes.

Thanks,

  • rick
3

Hi
The nifti_tool -rm_ext ALL stopped 3dDespike from flipping (AP and I confirmed LR). Thank you! That was an easier fix than I anticipated.

However, this begs a few questions.

The nifti header appears unchanged so what exactly was removed, and what does “old AFNI header embedded” mean? Is there a page somewhere explaining what it is and how its being used?

I assume the additional information was included in the file by to3d? Is there a way to stop this behavior beyond the rm_ext ALL?

I only noticed this after moving to 20.2.14 OpenMP version (though 19.1.00 OMP seems to do it too). Did something change in these versions that changed how the nifti header was read/interpreted or was the “old AFNI header embedded” always used instead of the just the standard nifti? I checked some older but similar data processed with an older version of afni and I don’t see the flip (thankfully!) though everything was done with the same bash scripts.

Is this specific to 3dDespike or would other afni functions (eg slice timing correction) in the new version be expected to do the same thing? I ask because we are field-testing enigma/halfpipe and are seeing errors that say the sform of an image and a mask are substantially different. halfpipe/fmriprep uses afni for slice timing correction I believe and the masking error is during later fieldmap correction (I believe). I’m giving it the niftis as created by to3d so maybe the same problem? I guess I’ll have to look at the matrices before and after…

Thanks again for your help.
cheers
j