Hello, I am new to fmriprep and have some data preprocessed through the pipeline. (Fmriprep is an excellent resource, btw!)
When I open the preprocessed images
*_preproc.nii.gz as an overlay on the the 2mm MNI brain as provided by fsl on
fslview_deprecated, I am unable to view them. I get an image mismatch warning.
When I run fslhd to look at the header information of
*_preproc.nii.gz, it looks like:
and same with sform
on the MNI brain provided by fsl, the header information looks like:
and same with storm
Looks like the images come right-left flipped out of fmriprep. It seems to me that majority of images have qform/sform as Right-to-Left, so what was fmriprep’s rationale to choose Left-to-Right orientation? Do I need to switch storm and qform to do further analyses, because I can’t use
fslmaths function right now between two images because of this mismatch issue. How do I switch the qform/sform to give a proper orientation? Any help would be appreciated, thanks, I am still learning fmriprep!
Thank you for the kind words.
Outputs of FMRIPREP are in the same orientation and resolution as the input images (unless you used the
--output-grid-reference option to point to the specific template you are using).
To avoid issues please use a viewers and tools that can properly use the header information to interpret the images and interpolate them if necessary such as fsleyes, Mango and nilearn (for resampling and/or extracting time series from ROIs).
Thank you for your response @ChrisGorgolewski.
My input data into fmriprep (version 1.0.15) has the following header info:
For the output data from fmriprep (
qform_xorient was switched to
Left-to-Right (see original post).
I did not manipulate the images beyond default fmriprep and I did not use (
--output-grid-reference), so something within fmriprep definitely caused the switch.
Hmm… I would have to double check, but it’s possible that only the resolution is taken from input files but the orientation comes from the template used for the coregistration (
MNI152NLin2009cAsym). This does not change the solution: either rerun everything with
--output-grid-reference does the same, but is deprecated see https://fmriprep.readthedocs.io/en/stable/usage.html#Workflow%20configuration) or use tools that can handle header information properly.
Thank you @ChrisGorgolewski.
--template-resampling-grid flag’s description on the website sounds like it modifies preproc output images in a specified spatial resolution, doesn’t say anything about maintaining original image’s orientation. Anyways, I have launched fmriprep for one test subject with the flag to see if orientation is maintained. Will report back once fmriprep is complete.
I also want to avoid rerunning fmriprep for ~200 subjects I just completed preprocessing, so it would be great if you could suggest a tool that can handle this orientation change. I am familiar with and tried
fslswapdim, but it didn’t seem to work.
Just out of curiosity - why do you focus on orientation only? The voxel size (resolution) and FOV (voxel count along each direction) of your output data probably does not match the particular template you are trying to work with. Right?
I am focusing on orientation because I was able to fix the other factors by resampling data to 2x2x2, and also chopping out slices to have the right FOV dim. and still the problem persists, because of orientation.
the way i discovered this issue is by using standard atlas (Powers et al 2011) ROI’s to extract timecourses and fslmaths would not let me to do so…that’s when i realized that orientations aren’t matching up
I see! You can save yourself all this trouble by using
NiftiLabelsMasker from nilearn to extract timeseries. It understands the headers so you don’t have to change anything (FOV, resolution, orientation) about your FMRIPREP outputs. Here’s a tutorial: http://nilearn.github.io/connectivity/functional_connectomes.html
Thank you for the suggestion of
By the way, fmriprep finished running for the test subject with
--template-resampling-grid "2mm" and the change was from 3.125 x 3.125 x 3.60 to 2.00 x 2.00 x 2.00 for voxel size, but the R-L orientation still changed from Right-to-Left to Left-to-Right. Is this orientation switching a common result of fmriprep?
fslreorient2std doesn’t fix this issue.
Try pointing --template-resampling-grid to a particular file (template or atlas) you wish to inherit the orientation parameters from.
Thank you @ChrisGorgolewski, this worked!
I want to re-run fmriprep with the
--template-resampling-grid flag, but I do not want to re-run
freesurfer again because of computing time. So I am planning to delete all the files in
$BIDS_dir/output/fmriprep/sub-*/func and re-run fmriprep with the
--fs-no-reconall flag. But my concern is
bbregister won’t run in the presence of the
--fs-no-reconall flag, even if the freesurfer outputs exist in the
$BIDS_dir/output/freesurfer/sub-* folder. Is this true or should I not worry about it? Should I use the flag
Also, is deleting previous
_preproc files and rerunning fmriprep the smartest way of re-running fmriprep? I launched the command without deleting previous files and got errors since output files with the same names were detected?
If you remove
$BIDS_dir/output/fmriprep/sub-*/ but keep
$BIDS_dir/output/freesurfer FMRIPREP should reuse existing recon-all without having to issue any flags.
I still think using nilearn to extract your timeseries would’ve been faster and would save you disk space (outputs in 2x2x2mm will be larger) and compute resources.
Did you manage to keep the input orientation? I am encountering the same problem.
- Could I just use TemplateFlow for my output space and reorient the template I want to use to my desired output orientation (LAS)? https://fmriprep.org/en/stable/spaces.html
And then use the --output-spaces command?
I am only having problems with reorienting the existing template file in TemplateFlow (e.g. mri_info does
not work with the files. The command is unable to open them)?
And would I need to reorient all round about 50 files which belong to the template?
- Or would reorienting my output file sub-50_ses-1_task-rest_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz to LAS actually end in the same result?