Hello - First, thank you for this wonderful package. I am running this pipeline on images collected from two scanners (PRISMA and TRIO). The PRISMA images are working just fine. The TRIO images had some problems with reconstruction, and we were actually given the reconstructed files (.hdr/.img) by our MR center. Using the reconstructed TRIO .nii files (and a .json file constructed using heudiconv), I am able to successfully run the pipeline. However, for two out of six of my tasks, there is an extra figure in sub/ses/figures called *_desc-coreg_bold.svg. It seems that this figure shows failed coregistration.
The resulting preprocessed functional nii files look fine, and also the other figures (e.g. _desc-rois_bold.svg). Any ideas why fmriprep would create these files for only two of the runs? Does it indicate that there was an error in the processing? (I do not see any corresponding errors or warnings.)
Additional info, in case it is relevant: As mentioned above, I used .heudiconv (using raw images) to create the .json file and also needed to modify that. The problem had to do with the dimensions of the image (it is multiband x3, and the dimension in dcmmeta_shape was 18, when it should have been 54). Anyway, I believe that I fixed this, but I am not sure if it has something to do with this image.
As you mention, these *_desc-coreg_bold.svg are generated because the default preprocessing path using BBR (boundary-based registration) failed (otherwise, these reports would be called *_desc-bbregister_bold.svg - please check the reports of the runs that worked are named this other way).
Typically, bbregister will fail if there is a lot of distortion on the BOLD reference. Other factors I’ve seen before making bbregister fail are less glamorous, such as a nasty X-flip (please check for this possibility).
What version of fMRIPrep are you using? Would it be possible for you to share some failing data with us?
So I am also getting a *_desc-bbregister_bold.svg file that looks fine from these sequences. I am not sure how to interpret that? It seems that the coreg_bold.svg is just “extra”. E.g. here is the one from the same sequence above.
I am actually attempting to do fieldmap correction, but for some reason am getting the message: SDC: no fieldmaps found or they were ignored. This is a bit odd, since the dataset is BIDS compatible and contains a fieldmap. This is another issue that I am trying to figure out.
There does not seem to be an x-flip.
Re: the question about which fmriprep I am running. I am running the singularity container poldracklab_fmriprep_latest-2019-05-16-e6afe8840920.simg. I am not sure the best way to find the exact version, though I imagine it is the most recent version.
And happy to share the data. Can I attach that here? (I could upload rest and t1w for a single participant - would that be sufficient?)
Thanks for confirming this. So there has to be some detail making this run different from others. Essentially, you should get a *_desc-bbreg_bold per bold run.
I bet you need to define the IntendedFor metadata field in the fieldmap json sidecar.
Are x-form headers consistent across all runs?
What does singularity run poldracklab_fmriprep_latest-2019-05-16-e6afe8840920.simg --version says?
In general, I would build and keep track of versioned containers avoiding the ‘latest’ or ‘master’ tags, which are wildcards in a way.
The example you are showing would be fine (T1w + rest). I’m a bit confused why fMRIPrep would generate BOTH the desc-coreg and desc-bbregister reportlets. Maybe you can share the full report of that subject first?
Re: x-flip, Using fsleyes, the A-P axis is the same across all runs, and the images appear to be in the correct orientation.
Re: SDC, I figured it was an IntendedFor issue from another posting. I will add this to the json file to see if that helps. Since a -bbregister_bold file was created (in addition to the coreg file), do you think it is still an issue of distortion?
By the full report of the subject, do you mean the .html file that is generated? I can attach that, and also upload the .nii files to openneuro.
I was able to use fieldmaps for SDC in the analysis - however, the coreg figures for these two tasks (rest, efnback1) are still created. I cannot seem to attached the .zip file here. Can I email this to you? Thanks!
Thanks for the report. We will need to replicate this in house because fMRIPrep seems to be malfunctioning on some of your runs. Let’s take the next step, could you share some data on openneuro then?
Thanks - As I mentioned in my last email, I am waiting for permission to upload the data, since per our lab manager we might need to have a Data Use Agreement. (She will be getting in touch with you about this, if that is ok.) Any alternative suggestions in the meantime?
I just ran another subject from the TRIO scanner and that one created just one coreg file, but from a different task. So it seems very random. Does it seem that the other runs are processing fine (the ones that don’t generate the weird coreg figure)? Thank you!
Just to be clear, uploading to OpenNeuro does not mean it will be openly shared. You can choose who you share it with. Still, if that is a problem, then Dropbox, Box, Google Drive, etc, would be just fine.
Yep, those coreg files are generated when fMRIPrep understands bbregister didn’t work okay. We need to figure out 1) why it thinks they are not fine; and 2) why both reports are kept, when only the coreg one should be there.
will solve your problem; 2) is more about fMRIPrep’s correctness.
I will work on sending you the data. In the meantime…
I am pretty sure that the problems are related to the .json file or .nii header of the reconstructed TRIO images. Would you be able to tell me which of these fields are used in the fmriprep analysis, so I can double check them?
Thanks!
Danella
