Slice timing issue with Anterior to Posterior

[cchaswell]

I was running data from a site that specified their slice timing direction as Anterior to Posterior in beta 6. I chose that option in the halfpipe user interface, however it found 44 scans with I-S direction. I continued to try to run and got an error:

[2020-12-28 14:56:56,0915] [halfpipe ] [ERROR ] Exception: The 'slice_encoding_direction' trait of a TShiftInputSpec instance must be 'k' or 'k-', but a value of 'j-' <class 'str'> was specified.

I'm not sure if that is due to some of the scans possibly not being A-P or not.

Also, how can I tell the direction from header information? I am double checking what sites have told me but I cannot find that information from using something like fslhd to check the header.

Thank you.

[HippocampusGirl]

Dear Courtney,

Apparently it is unsupported if the slice encoding direction is not on the third axis of the NIfTI file.

1. Could you try to re-orient the files so that this is the case, for example using fslswapdim weird_nifti.nii.gz LR IS PA new_nifti.nii.gz. I have not tested this, so you may need to play around with the exact parameters.

2. Also, we could ask the developers of fmriprep, because this is an issue in their code.

[HippocampusGirl]

Apparently the developers of fmriprep discussed this at nipreps/fmriprep#1345, and decided that it's not an issue. One of the developers of AFNI writes "I have never seen data where the slice-encoding dimension is not k, and am not sure how the software would behave. "

[cchaswell]

So how do I handle data that the sites have told me their slice encoding direction is A-P? Literally half of our data shows that people said their slice dimension was A-P which must be incorrect. How can I check the metadata to see what the slice encoding direction really is? Our Duke data has always been k, so I have no idea. The program is automatically finding it and suggesting S-I for some of the scans, but a lot will say "Missing" for encoding direction.

…

On Mon, Dec 28, 2020 at 3:27 PM Lea Waller ***@***.***> wrote: Apparently the developers of fmriprep discussed this at nipreps/fmriprep#1345 <nipreps/fmriprep#1345>, and decided that it's not an issue. One of the developers of AFNI writes "I have never seen data where the slice-encoding dimension is not k, and am not sure how the software would behave. " — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJV2KSSZALSXY5LJDPEHPBLSXDS27ANCNFSM4VMNZ33A> .

[HippocampusGirl]

So what you are saying is that the image metadata contradicts the slice acquisition direction provided by the sites? In this case, I think before we think any further on the software side, we need to be doubly sure that they were actually acquired that way. My suggestion would be to work with the sites to get first-hand information on the sequence to make sure that they did not confuse slice acquisition and phase encoding direction :-)

[cchaswell]

It does seem that slice acquisition and phase encoding has been confused by many sites. Ugh. Is there a command to find the slice acquisition in the metadata? I don't know how besides running it in halfpipe and the program says what it found.

…

On Wed, Dec 30, 2020 at 12:38 PM Lea Waller ***@***.***> wrote: So what you are saying is that the image metadata contradicts the slice acquisition direction provided by the sites? In this case, I think before we think any further on the software side, we need to be doubly sure that they were actually acquired that way. My suggestion would be to work with the sites to get first-hand information on the sequence to make sure that they did not confuse slice acquisition and phase encoding direction :-) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJV2KSRTAT2WD5SVI4AV653SXNQPPANCNFSM4VMNZ33A> .

[HippocampusGirl]

It's actually two steps. First, you need to find which dimension stores the slices.

$ fslhd {file} | grep _dim
phase_dim       2
freq_dim        1
slice_dim       3

If they are all zeros, that means that the information is missing from the NIfTI header. However, if you get 1, 2, or 3, those correspond to the x, y, and z axes, respectively.

Now, you need to see which anatomical axis the dimension corresponds to. In this case, slice_dim is 3, so the axis is z. So we ask for the orientation of the z-axis, which is called qform_zorient. For the other axes, there are also qform_xorient and qform_yorient, and running fslhd {file} will print them all. However, we can also use fslval to get just the information we want.

$ fslval {file} qform_zorient
Inferior-to-Superior

This is exactly what Halfpipe does in the background, just with Python/Nibabel instead of FSL tools :-)

[ilyaveer]

Courtney, indeed very likely that some confused slice acquisition order and phase encoding direction. I second the fmriprep people, I don't know any data set where data was not acquired in the axial direction (i.e., I-S or S-I). Good to know that this confusion occurs, we should be very explicit in our manual about the difference between acquisition order and encoding direction.