I doublechecked but still sent you the information of the T1 instead of the original bold image, sorry. Below you see a screenshot of the python code you suggested, and as a last entry I added the fslhd info, this time really of the original bold image.
I’m using 6 dof BOLD T1w registration according to the html report. Further we just noticed " Note on orientation: qform matrix overwritten. The qform has been copied from sform." -> is this of importance?
Below a try to summarize the different voxel orientation in the different images:
Sharing a T1w image and volumes of the BOLD series of a healthy control would be possible. I try to get the data today from the MRI just in case. Those bold images are oriented coronal along the hippocampus. The axial slices I refered to are from a different bold series of our team (you find them on open neuro https://openneuro.org/datasets/ds001419/versions/1.0.1 ).
I hope I did not miss anything and those information helps to understand what is happening. Thank you!!
Thanks. This is interesting. So your original image is in LSP orientation, but the original zooms are (2.4, 2.4, 4), so it will be (2.4, 4, 2.4) in RAS space, which seems born out.
Not really. This is an “in the interest of full disclosure” sort of statement, not a problem. Our treatment of affine matrices can be surprising to some people, so what this means is that both the qform and sform matrices were valid, but were not identical. Because the standard says that sform takes precedence we sync the qform to the sform, to accommodate tools that don’t respect the sform.
Alright, thanks. I think I’m going to need to run this to track down exactly where the flip happens. I think I agree that the outputs should be in (2.4, 4, 2.4), instead of the original (2.4, 2.4, 4) zooms. But it really might be an effect of the pitch, and the transform application step making a best guess as to which zoom set will introduce the least distortion. For such a high rotation, it might be that interpolating to (2.4mm)^3 voxels is the best approach, or moving to a boldref output. Both of these options will require additions to fMRIPrep to make happen.
Could it be the case that both q-form and s-form matrices are set and correct under the definition of NIfTI? If so, the q-form and the s-form could differ in this flip and by overwriting the q-form we are imposing the s-form (that would mean aligning to the stereotactic frame instead of the scanner’s frame). Does it make any sense to you Chris?
@anna although you can’t share T1w images at this point, it would be incredibly helpful to have a look into the first 50 timepoints of one of your bold runs. In principle, these 50 timempoints are almost useless to address any research question and identification would not be an issue for a BOLD run.
To do that:
import nibabel as nb
nii = nb.load('sub-ZZZ_task-TaskName_bold.nii.gz')
nii.__class__(nii.get_data()[..., :50], nii.affine, nii.header).to_filename('clipped_bold.nii.gz')
I guess it’s possible if the pixdims don’t match the RSS of the sform columns that you could have a difference of axis ordering in the sform vs the qform, but that doesn’t seem to be the case here, by my reading.
I got the data of a healthy control, who gave consent to share the data. So I uploaded T1w and the whole bold run of one condition. Still thanks for the nibabel code, I think its a more convenient way to delete the dummy scans than I did before.
The data should have the same scanning protocol. I startet now preprocessing the data without fieldmaps and freesurfer to make sure they behave the same. I will update you when fmriprep is finished.
The fmriprep code I used for all the patients is (I included fieldmaps):
Fmriprep is finished and preprocessed bold in both T1w and MNI look the same in this dataset as in the patients data. I added the fmriprep outputs and the reoriented image by nibabel to the link.
I think I tracked down the issue. I’m realizing now that perhaps the better diagnostic would have been for you to run fslreorient2std on your BOLD files before running fMRIPrep and seeing if the problem persisted. I don’t think it would have, though, and have proposed a fix.
I’ll test it locally now, and we can see what the output looks like.
Thanks a lot for finding out and proposing the fix!! What is the best way to implement the fix into fmriprep? I’m currently using fmriprep 1.2.1 with the docker container.
May you have tried running fslreorient2std on your BOLD files and then rerunning fMRIPrep? I believe for the fix to have been implemented is pulling the latest fMRIPrep docker container. To preserve your version (1.2.1) it may be better to try the fslreorient2std approach before updating to see if the problem persists.
Hi @anna, if you’re okay updating to a newer version of fMRIPrep, I’m going to be pushing a (hopefully) fixed version to an experimental Docker tag within the next couple of hours. I’ll update here when it’s ready.
I started fmmriprep monday morning for some participants and it is still running, probably until friday evening, so I will try updating next week. However I ran the fslreoient2std on a single dataset and I got an fmriprep error log, because now the slice timing doesn’t match the right dimension anymore. I appended the errorlog. Is there a need for changing the dimension of the slice timing now?
Ah, good catch WRT slice timing. In any event, no. With the poldracklab/fmriprep:orientation-fix image you do not need to reorient your images prior to running fMRIPrep.
ok perfect thank you! So I will give this a try next week, when fmriprep finished running! Should the fix work well with the fieldmaps together, too? Or is there the need to change anything more for the fieldmaps?
I finally tried your fix with a niworkflow repository (using the niworkflows corresponding to fmriprep 1.2.1 and changing the lines according to your fix) together with fmriprep 1.2.1 and it works!! Thanks a lot for helping and solving the problem!!
