Fmriprep, nilearn and slice time correction

Greetings,

When taking advantage of the nilearn.glm.first_level.first_level_from_bids function on my fmriprep’d data (version 20.2.7) I got a userwarning saying that

UserWarning: SliceTimingRef not found in file […] It will be assumed that the slice timing reference is 0.0 percent of the repetition time. If it is not the case it will need to be set manually in the generated list of models
warn(‘SliceTimingRef not found in file %s. It will be assumed’

At my own peril I disregarded this because the online tutorials on the website also didn’t make a big deal of it, but upon inspecting the strength of the visual response in my task data as well as reading this blogpost and the relevant fmriprep issue I realize now that it is very important.

If I understand correctly fmriprep has a --slice-time-ref parameter with a default value of 0.5, but this value is not outputted into the preproc_bold.json (all I have is “SliceTimingCorrected” and “StartTime” field) so Nilearns FirstLevelModel won’t be able to pick it up.

I guess I just wanted to ask whether other people also missed the mark on that and whether slice-time-ref is getting outputted to json in newer fmriprep version or not because I think it should :slight_smile:

Hi,
I haven’t looked at that in detail, but I would not be surprised that this is a Nilear bug, as Nilearn may not read the parameter correctly. This may be in part because BIDS conventions are still being built.
PR welcome :wink:
Bertrand

I believe that the nilearn tools were written before the SliceTimingCorrected and StartTime fields were created by fMRIPrep, and the expected metadata field was probably written to conform to nilearn (then nistats) internal parameter names.

SliceTimingCorrected was added as a simple boolean to identify a difference between BOLD series that had STC applied and those that did not have SliceTiming information available. StartTime was chosen because it corresponds to a field added in PET-BIDS (BEP 009); we anticipate that there will be a preference in BIDS to re-use existing terms.

Probably the best thing to do is to submit a patch to nilearn to handle both SliceTimingRef (which presumably they have derivatives prepared with) and StartTime. The alternative approach could be to shift all of your event times by -TR/2, but it’s not ideal to encode details of your preprocessing in events files, which should describe the task.

1 Like

Thanks. Just to clarify - and I know this came up on the blogpost - we subtract, not add TR/2, more precisely we subtract, not add the value of StartTime (in my data the value is less than TR/2), right?

Shouldn’t StartTime be a negative offset then? The naming kind of implies that the experiment starts at ≈TR/2.

Also in the blogpost it still says " If you’re using nilearn (which is used within fitlins to estimate the model) and you would like to ensure that the model and data are aligned, you can simply shift the values in the frame_times by +TR/2."

If you want to modify event onsets, then you subtract. If you want to modify volume times, you add. They are equivalent operations when creating design matrices.

1 Like