Fmriprep: Possible bug or user error? Echoes look suspitiously similar after fmriprep.

[dangom]

Hi guys,

we have an issue here but it's possible that we are the ones doing something wrong.
In one of our experiments we acquire a 3-echo dataset and preprocess it with fmriprep 1.0.13 running the following command:

FMRIPrep command: /home/mrphys/zahfaz/anaconda3/bin/fmriprep --participant-label sub-07 --low-mem --use-syn-sdc --ignore fieldmaps slicetiming --use-aroma --aroma-melodic-dimensionality 100 --no-submm-recon --output-space T1w template -w /data/fmripreptest-task-sub-07 --nthreads 12 --fs-license /home/mrphys/zahfaz/usr/local/freesurfer/license.txt --fs-no-reconall /project/3015046.02/task-experiment-datasets /project/3015046.02/task-derivatives/temp participant

For completion, here's how the func directory looks like:

$ tree
.
|-- sub-07_ses-01_task-stroop_acq-mb_bold.json
|-- sub-07_ses-01_task-stroop_acq-mb_bold.nii.gz
|-- sub-07_ses-01_task-stroop_acq-mbme_echo-01_bold.json
|-- sub-07_ses-01_task-stroop_acq-mbme_echo-01_bold.nii.gz
|-- sub-07_ses-01_task-stroop_acq-mbme_echo-02_bold.json
|-- sub-07_ses-01_task-stroop_acq-mbme_echo-02_bold.nii.gz
|-- sub-07_ses-01_task-stroop_acq-mbme_echo-03_bold.json
`-- sub-07_ses-01_task-stroop_acq-mbme_echo-03_bold.nii.gz

BIDS-Validator says things are OK except for a missing 'TaskName', but I wouldn't expect that to be relevant to the issue at hand.

Our problem is that after processing, all of the three echoes look extremely alike, as you can see in the shots below:

Echo 1 raw

Echo 1 fmriprep

Echo 2 raw

Echo 2 fmriprep

Echo 3 raw

Echo 3 fmriprep

Apologize for the suboptimal contrast windows used for the raw datasets. These are screenshots taken from within FSLEYES.
In any case, the preprocessed echoes "look" identical despite containing different information. It also looks like the distortion correction was applied independently in each of them (shouldn't we have the same warp applied to all images? To a good approx. the distortion should be the same for all echoes).

Could it be that the first echo is being cloned somewhere along the pipeline and overwriting the other echoes?

Curious to hear your suggestions / interpretations. If you need any more info, let me know and I'll be happy to provide it.

[emdupre]

Just to jump in— if you'd like the same coregistration to be applied across multi-echo data sets, I'd recommend throwing the --t2s-coreg flag, which will generate a T2* map from the echos and then use that as the coregistration target.

As to whether or not specifically the distortion should be the same across all echos, I'm not sure that's the case, and would advocate that the distortion correction is actually calculated from the T2* map rather than from any of the individual echos. This was something @oesteban and I were discussing in #1031

[dangom]

Thanks for the quick response.

In my specific case where I have both a single-echo and a multi-echo dataset for the same task, would the --t2s-coreg flag know that it should only try to compute a map for the multi-echo dataset?

The distortion should be the same for all echoes given that the ETL is the same, the PE direction is the same (I don't think anyone is doing alternate polarities nowadays), and to a very good approximation dB0/dt = 0 within those ~40ms between the acquisition of all k-space center lines. Because of different dropouts the distortion may look different to the eye, though.

I never tried calculating the warp field from the T2* map. That could work, but would it be robust against edge artefacts? I would think of the first echo as a better candidate, but my intuition could be wrong.

[oesteban]

Hi @dangom, you are right, this is very suspicious. I'll check we are not writing the same image three times. Since you are actively using the multi-echo processing it is probably a good time to make a revision of the ME pipeline and #1031. Can we count on your expert eyes to help?

[emdupre]

@dangom --t2s-coreg should only apply to the multi-echo run. If this is not your experience, please let us know !

@oesteban I just compared ds210 outputs and confirmed that derivatives of echo 1 and 2 for ds210 are the same. This is not the case with data I processed myself for fmriprep v 1.0.9, so it likely arose from a subsequent refactor.

[oesteban]

Thanks a lot for checking this. I'll try to find out where this is
happening.

On Tue, May 15, 2018 at 10:57 AM, Elizabeth DuPre [e-mail]
wrote:

@dangom https://github.com/dangom --t2s-coreg should only apply to the
multi-echo run. If this is not your experience, please let us know !

@oesteban https://github.com/oesteban I just compared ds210 outputs and
confirmed that derivatives of echo 1 and 2 for ds210 are the same. This is
not the case with data I processed myself for fmriprep v 1.0.9, so it
likely arose from a subsequent refactor.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/1131#issuecomment-389257560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxprvS-PbleA_CA82QKPgSgiX-YRhks5tyxcLgaJpZM4T_d97
.

[dangom]

@oesteban Definitely. If there is anything specific that I could help with, just let me know.
@emdupre Thanks again for the feedback. I'll give the --t2-coreg option a try.

[oesteban]

Effectively, this early node

https://github.com/poldracklab/fmriprep/blob/e5d1ad7d311e90b8dc14c26176d046d3060200bf/fmriprep/workflows/bold/base.py#L349

has just the first echo as input.

[emdupre]

Ok, I _think_ (before boldbuffer was added as a field) we were passing just the first echo to STC since that metadata should be consistent across echos. Now that you've streamlined that part of the workflow, we're missing that inputnode.bold_file is actually an iterable. I can look into patching this.

[oesteban]

If you can get this off my plate, I'd really, deeply appreciate it :)

On Wed, May 16, 2018, 07:45 Elizabeth DuPre [e-mail]
wrote:

Ok, I think (before boldbuffer was added as a field) we were passing just
the first echo to STC since that metadata should be consistent across
echos. Now that you've streamlined that part of the workflow, we're missing
that inputnode.bold_file is actually an iterable. I can look into
patching this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/1131#issuecomment-389545336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxkdTDP6zytge3m-xW455-P7FIlDhks5tzDuWgaJpZM4T_d97
.

[oesteban]

Fixed via #1134. @dangom, could you please double check that we fixed the problem indeed?

[dangom]

Running

[dangom]

Fixed. Thank you guys!