Testing the application of slice-timing correction over the right axis and direction

[Gab-D-G]

After conversion to RAS, the Y dimension should correspond to anteroposterior slices, where the slices are usually acquired from front to back. AFNI's 3dTshift applies correction over the Z axis, since in humans slices are acquired over the superior-inferior axis. Thus, axes are temporally swapped within RABIES to match the desired axis for correction (axis Y by default) with the Z axis.

However, in the anteroposterior axis, the index order is inverted where the first index is at the back of the brain and the last index is the front of the brain.
The first slice acquired in the olfactory bulb -> corresponds to the last index in the data array

The last slice acquired in the cerebellum -> corresponds to the first index in the data array

It is unclear in which direction 3dTshift will be applying the correction, so here I am testing its application.

First, using a negative direction with -tpattern seq-z, we can observe in a voxel from the front slice that with the correction (shown in orange) the data is shifted relative to the original timecourse (in blue) to be more similar to the next timepoint. This means that the interpolation was applied to shift the slice timing to be later in time:

Conversely, in a voxel from the last slice, the data is shifted to be more similar to the last timepoint, which means that the timing was shifted to be earlier in time:

This is the outcome desired if slices were acquired from front to back, thus the default in RABIES is set to be with a negative direction. However, the correction can be applied in the positive direction (from back to front) by specifying the --tpattern seq+z instead when running RABIES.

If we look at a voxel in the middle slice, we can see that no correction was applied (the corrected orange trace is overlapping with the blue trace):

From the slice:

This confirms that the correction was applied over the anteroposterior axis.

[gdevenyi]

Ideally the acquisition direction should be parsed from the BIDS input data, I believe its required in the metadata?

[Gab-D-G]

I am not sure how common this information is, there are definitely cases where it is lacking. Sometimes the TR isn't even part of the metadata, or the data itself can be artificially modified (e.g. axes swapped), which requires flexibility with the parameter settings.

[gdevenyi]

You can start by using pybids to query SliceEncodingDirection[1] and allow overrides.

[1] https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html

[Gab-D-G]

that can be raised as an issue.