EPI Slice timing encoding direction error (bug?) in fmriprep

,
1

Hi,

I have some 7T EPI data, which was acquired with slices in the y-direction to maximise brain coverage. The data are 128 x 96 x 128 x time. The json files clearly indicate this with the flag: “SliceEncodingDirection”: “j”,

Nonetheless, I get a warning from the BIDS validator:
1: [WARN] The number of elements in the SliceTiming array should match the ‘k’ dimension of the corresponding nifti volume. (code: 87 - SLICETIMING_ELEMENTS)

And, much more annoyingly, a complete failure from fmriprep:
traits.trait_errors.TraitError: The ‘slice_encoding_direction’ trait of a TShiftInputSpec instance must be ‘k’ or ‘k-’, but a value of ‘j’ <class ‘str’> was specified.

Is there a reason that things are set up so restrictively?

I’m not all that keen to go about rotating all of my images (that way errors lie). Is this fixable, or fatal?

2

I could be wrong but for humans taller than the inner diameter of the bore of the scanner, yes. Are you trying fMRIPrep on nonhuman data or data acquired on an open scanner?

3

I’m sorry, I really don’t understand your response.

The data are human data. The EPI sequences were acquired at 1.5mm isotropic resolution. Our SAR limits restricted us to 96 slices, resulting in a 14.4cm slab. This was insufficient to capture the whole brain in a conventional axial EPI acquisition, so the data were acquired in an oblique coronal plane (somewhat similar to this Google images example: http://www.neurologyindia.com/articles/2012/60/1/images/ni_2012_60_1_29_93585_f5.jpg).

The dimensions of the data are as follows:

dim0 4
dim1 128
dim2 96
dim3 128
dim4 340

And we therefore have a 96 element slice time vector and “SliceEncodingDirection”: “j” . This results in a failure.

A quick and dirty workaround is to do something like
fslswapdim “${badfile}” x z -y “${badfileswap}”
to the data, but this kind of procedure is very prone to errors, and requires a lot of manual checking of orientation matrices etc.

4

Oh, I see. Such an oblique acquisition is pretty unconventional, but I still don’t understand why slices are encoded on the second axis. I’m also very curious as to how susceptibility distortions warp these images.

This error is Nipype checking that the underlying 3dTShift command from AFNI will accept the input (I might be wrong, but the AFNI tool will not accept other than the third axis for slice encoding).

This is something we definitely want to get fixed for animal fMRI, as it is common to find the slice encoding in the first or second dimensions. But this is not common in humans for the physics of the MR scanner and MRI principles.

I’m afraid that this is currently your only option with fMRIPrep. Swapping axes should not introduce interpolations on your data. Since I’m not sure about how fslswapdim will perform in this case, I would rather use nibabel. Something like this should work:

import nibabel as nb

RAS = np.array([[1, 0, 0, 0], [0, 0, 1, 0], [0, 1, 0, 0], [0, 0, 0, 1]])

nii = nb.load('sub-NNN/func/sub-NNN_task-taskname_bold.nii.gz')
hdr = nii.header().copy()
aff = nii.affine
data = np.swapaxes(nii.get_data(), 1, 2)
aff = RAS.dot(aff)
hdr.set_qform(RAS.dot(nii.header.get_qform()), int(nii.header.get_qform(coded=True)[1]))
hdr.set_sform(RAS.dot(nii.header.get_sform()), int(nii.header.get_sform(coded=True)[1]))
nii.__class__(data, hdr, aff).to_filename('newname.nii.gz')

Please make sure you always keep a copy of your original files before doing this, maybe under the sourcedata/ folder.

For the future, we will be interested in including such axes swap into fMRIPrep. Contributions are very welcome!

1 Like