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
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
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.
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.
Hi all, just to clarify since this pertains to my current analysis:
I have done slice timing correction on my bold task data and need to shift my events by 0.5TR to account for this (the middle slice was my reference slice in fmriprep preprocessing). Is that accomplished by nilearn’s FirstLevelModel parameter slice_time_ref=0.5 already, or should I shift all the event times by 0.5TR manually too?
