Fmriprep image orientation question

fmriprep

#1

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:
qform_code 1
qform_xorient Left-to-Right
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
and same with sform

on the MNI brain provided by fsl, the header information looks like:
qform_code 4
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
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!


#2

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).


#3

Thank you for your response @ChrisGorgolewski.

My input data into fmriprep (version 1.0.15) has the following header info:
qform_code 1
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior

For the output data from fmriprep (*_preproc.nii.gz), 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.


#4

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 --template-resampling-grid (--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.


#5

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.


#6

Try fslreorient2std.


#7

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?


#8

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 :frowning:


#9

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


#10

Thank you for the suggestion of NiftiLabelsMasker!
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?
Also fslreorient2std doesn’t fix this issue.


#11

Try pointing --template-resampling-grid to a particular file (template or atlas) you wish to inherit the orientation parameters from.


#12

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 --force-bbr?

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?


#13

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.