I want to use scans with inverted phase encoding direction for SDC for my BOLD data (PEPOLAR). As far as I can tell this works fine when placing these files in the fmap dir and appending “_epi” as suffix, and specifying in the json file the “IntendedFor” field accordingly; i.e., listing the BOLD data runs for which this SDC is intended.
I also want to use single band reference scans for each of my multiband data runs. These sbref scans with their json files are placed next to the BOLD data in the func dir, with “_sbref” as suffix. This also seems to work fine.
My question: How do I use sbref scans for my inverted PE scans (fmap)? What information does fmriprep need in order to correctly use these? Any pointers, or even a link to an example dataset would be very welcome.
In a related matter, should the “IntendedFor” field of the fmap point towards the “_bold” or “_sbref” data, or both? I saw a similar question discussed before on github, but the answer wasn’t quite clear to me.
The nice thing about having your data in BIDS is that BIDS-apps such as fMRIPrep can easily search for files without you having to specify much. I would recommend using the bids validator before using fMRIPrep, to ensure that your data is BIDS compliant.
By default, fMRIPrep will search for sbref and fmap files to include in the pre-processing, unless you specifically request to have them ignored, using the --ignore option (e.g. --ignore sbref).
Regarding your “IntendedFor” mapping question, this should point to your bold acquisitions, not the sbref.
Yes, I am aware of bilds validator and how to use sbref and fmap files in general. Unfortunately, from this I cannot seem to deduct how to use sbref files for inverted PE scans specifically.
A few options I have considered: An _sbref file in the same folder as the inverted PE multiband data, like for usual func data, would not be bids compliant for the inverted PE scans in fmap. That is, to my knowledge bids validator will flag _sbref files if found in the fmap folder.
The alternative I can think of, moving the _sbref file belonging to the inverted PE scan to func, does not make sense either, as the _sbref file would be in a different folder than the run it belongs to.
I am sure i am missing something obvious, but I do not really see what other sensible options there are.
My understanding is that fMRIPrep is able to automatically detect the presence of sbref and apply SDC to them, in addition to your multiband bold acquisitions. Therefore you shouldn’t need to do anything additional on your end.
Yes, correct - fmriprep does detect sbref files. However, i only get this to work with sbref files of normal bold runs, not the sbrefs of the inverted PE runs that are used to later perform the SDC itself. So, i have no problem with using sbref and fmaps in general, but only a problem with using sbref files for the specific case of (presumably) using them for improved registration of the inverted PE scans. That said, I am not completely sure whether there is much reason to use the sbref files in the SDC workflow. It is possible that there is no use for sbref scans in this case and maybe that is where the confusion stems from - confirming this would be equally helpful for me.
Ah sorry, so you’re saying that you have sbref that go to the fmap acquisitions themselves?
If that’s the case, I’m personally not sure how fMRIPrep would use them, if at all. My hunch is that these fmap sbref files are unnecessary, since the fmap files are used for SDC anyway, in which case you could add them to your .bidsignore file or remove them entirely, as I don’t see any examples of this in the BIDS specification.
Exactly! And I indeed could not find any BIDS specification for these files either. It would be nice nonetheless to have confirmation for this suspicion, thus my initial question here So, if someone can still confirm this, that would be much appreciated. For now i will indeed just ignore the files. In any case, thanks for thinking along Dan!
So, if someone can still confirm this, that would be much appreciated. For now i will indeed just ignore the files. In any case, thanks for thinking along Dan!