nipreps / fmriprep

fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
https://fmriprep.org
Apache License 2.0
637 stars 295 forks source link

Misaligned registrations between BOLD and T1w #2648

Open ly6ustc opened 2 years ago

ly6ustc commented 2 years ago

What happened?

Hi, I‘m trying to handle some rs-fMRI data using fMRIprep 21.0.0rc2. But I found some failed registrations between BOLD and T1w. I screenshot some reports as follows:

image

image

image

image

image

For the last figure, I couldnot certain if it shift down a bit. But it appears that there are apparent shifts for other results. Could you give some suggetions for this situation? How to improve it?

These are my superficial thoughts: 1) My dataset doesn't have fieldmaps files, but I forget use the flag "--ignore fieldmaps". I thinks it doesn't matter because the program will skip SyN distortion correction automatically. Am I right?

2) I found some subjects didn't use bbr-register methods with this notice, "mri_coreg (FreeSurfer) was used to generate transformations from EPI space to T1 Space - bbregister refinement rejected. Note that Nearest Neighbor interpolation is used in the reportlets in order to highlight potential spin-history and other artifacts, whereas final images are resampled using Lanczos interpolation.". Therefore, could the results of these two methods (i.e., bbr or not bbr) could be used together? (We usually keep the preprocessing method of all subjects consistent ). Should I try to use the flag "--force-no-bbr" for failed registrations?

3) When I find the failed registrations in SPM toolbox, I usually reorient them manually (shown in figure below) and run again. Could I combine the reorientation and fmriprep? For instance, I reorient the BOLD images of those subjects in the BIDS folder before run fmriprep. What I afraid is it will effect some subsquent analysis of fmriprep, e.g., slicetiming, realign, or some steps which need the orientation imformation, etc.. 图片1

Thanks a lot!

What command did you use?

docker run -i --name fmriprep$name --rm \
            -v $fs_licence:/opt/freesurfer/license.txt:ro \
            -v $BIDSdir:/data:ro \
                        -v /home/z/Data/Toolbox/templateflow:/home/fmriprep/.cache/templateflow \
            -v $prepre_dir/fmriprep:/out \
            -v $work_dir/work:/scratch \
            nipreps/fmriprep:latest \
            /data /out \
            participant --participant-label $name \
            -w /scratch \
            --use-aroma \
            --nthreads $nthreads \
            --output-spaces $out_space \
                        --cifti-output"

What version of fMRIPrep are you running?

21.0.0rc2

How are you running fMRIPrep?

Docker

Is your data BIDS valid?

Yes

Are you reusing any previously computed results?

FreeSurfer

Please copy and paste any relevant log output.

[WARNING] Citeproc: citation mni152nlin2009casympd25 not found

Additional information / screenshots

No response

ly6ustc commented 2 years ago

The reason for the warning "Citeproc: citation mni152nlin2009casympd25 not found" is that I use my custom template "mni152nlin2009casympd25", but I got what I want in results. So could I ignore this warning? Or any suggestions?

effigies commented 2 years ago

I'm sorry I somehow missed this issue entirely.

The reason for the warning "Citeproc: citation mni152nlin2009casympd25 not found" is that I use my custom template "mni152nlin2009casympd25", but I got what I want in results. So could I ignore this warning? Or any suggestions?

This is probably okay, but you are likely to need to do some manual adjustments to the citation boilerplate to reflect your changes, if you intend to use it in a publication.

effigies commented 2 years ago

My dataset doesn't have fieldmaps files, but I forget use the flag "--ignore fieldmaps". I thinks it doesn't matter because the program will skip SyN distortion correction automatically. Am I right?

Correct.

I found some subjects didn't use bbr-register methods with this notice, "mri_coreg (FreeSurfer) was used to generate transformations from EPI space to T1 Space - bbregister refinement rejected. Note that Nearest Neighbor interpolation is used in the reportlets in order to highlight potential spin-history and other artifacts, whereas final images are resampled using Lanczos interpolation.". Therefore, could the results of these two methods (i.e., bbr or not bbr) could be used together? (We usually keep the preprocessing method of all subjects consistent ).

The idea is to try to get you the best possible registration, whether it accepts the BBR refinement or not. It is up to you to choose whether "fMRIPrep's best" is consistent or you want to use --force-bbr or --force-no-bbr.

Should I try to use the flag "--force-no-bbr" for failed registrations?

You could give it a shot. There definitely seems to be something wrong there. I'm guessing the contrast in your BOLD images is just so low that BBR is struggling.

When I find the failed registrations in SPM toolbox, I usually reorient them manually (shown in figure below) and run again. Could I combine the reorientation and fmriprep? For instance, I reorient the BOLD images of those subjects in the BIDS folder before run fmriprep. What I afraid is it will effect some subsquent analysis of fmriprep, e.g., slicetiming, realign, or some steps which need the orientation imformation, etc..

It depends on what you mean by reorient. If you are simply updating the affine without changing the voxel data, then slicetiming and alignment should continue to work as expected (assuming the slice-encoding direction is still the third axis). If you resample to a new grid, then a voxel axis will no longer correspond to slice, and slicetiming correction will be impossible to do correctly. If you rotate axes (e.g., IPL -> LPI), you will need to update your BIDS metadata with an updated SliceEncodingDirection.

Since you're not doing any SDC, failing to update the PhaseEncodingDirection won't have any effect on fMRIPrep, but it's good data hygiene to make sure that you do anyway.