Storage order after fMRIprep is changed from radiological to neurological


After running fmriprep, I found that the storage order of the *_preproc file is changed from radiological to neurological. I’m using the output_spaces option with the atlas MNI152NLin6Asym (both res:2 and res:1) that is the same as FSL. Also, I skip the t1w processing using the option: --skull-strip-t1w skip (I did the skull stripping in a separate pipeline).

When I import in fsleyes the corresponding MNI space (1 mm) I got the warning message about the usage of different orientations/fields of view. Not only th eorientation is changed, but also the QForm/SForm matrices between the MNI space in the FSLDIR and the preproc file are slightly different (91 instead of 90), please see the attached files.

Orientation/SForm/QForm information for the func file after fMRIprep:

Orientation/SForm/QForm information for the MNI template after fMRIprep:

The images I feed to fmriprep are all in radiological convention (both functional and anatomical data).
What is the issue here?

I hope that someone can help me on this matter :slight_smile:

Thank you.




Be aware that the FSL template images all use LAS storage order, rather than RAS. I do not know why a negative determinant was chosen. Be aware that some FSL tools will flip the first dimension as stored to disk based on the determinant, while others will not. I describe some of these inconsistencies here.

For diffusion scans, you should be especially cautious that the bvec file is in image space, but assumes the first dimension has been flipped if required to provide the desired sign for the determinant. This is described here as well as here.

Thank you for your reply and suggestions, Chris.

The MNI template stored in FSLDIR has negative determinant (LAS) for storage order while my images after fmriprep have positive determinant (RAS).

Hence, the solutions I’m now thinking about are:

  1. apply a fslswapdim -x y z command to my fmriprep images in order to have them matched with the orientation of the FSL MNI template
  2. apply fslswapdim -x y z to change the orientation of the MNI template stored in the FSLDIR (and also I need to apply this to all the related atlases I’ll used later on).

If I chose the latter (all images in RAS) I can use fslmaths safely in later processing? because all the determinant will be positive and the flipping of the first dimension, that is supposed to happen intrinsically inside the fslmaths command, will be prevented to happen. However, I do not think that changes the images stored in the FSL path is a good idea. Instead, if I chose the former (all images in LAS), I have to avoid using fslmaths and I might be on the safe side using the niimath command.

What do you think about these solutions? do you have others solutions to suggest?

As a side note, when converting from dicom to nifti I’m using dcm2bids, and I set the dmc2niix option -x i (full command is -b y -ba y -z y -x i -f '%3s_%f_%p_%t) in order to have also the anatomical images in LAS orientation. So, I’m really trying to have consistency, but then after fmriprep I got back as preprocessed results the RAS orientation. I think there is a step that I’m missing in the fmriprep pipeline and maybe some of the fmriprep experts can help me understanding this.

Thank you in advance.


My own advice is to worry less about your input and what fMRIprep creates and make your inference flexible enough to handle the output of fMRIprep.

I am surprised that dcm2niix with the -x i parameter creates LAS output for your anatomical scans. Most 3D Anatomical T1-weighted images are sagittal slices, so one expects the raw data to be PSR (e.g. the slice direction is Left-Right).

Perhaps someone from the FSL team could create a table showing which tools flip the first axis based on the determinant.

Ok. Thank you.

I obtain the RAS orientation if I use the -x n option. These are 7T MP2RAGE data, and I think they follow the right-left direction for slice acquisition. I might need to check some parameters acquisition more accurately with the MR facility.



Had the same issue when started to use fmriprep. Took me few WTF moments before realising it. Advise is the same as above. I used simple fslswapdim to deal with it. It’s easy enough and there are example scripts on FSL website on how to convert your data.