Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fmriprep handling of multi-echo data with single-band reference scans #1745

Closed
markushs opened this issue Aug 23, 2019 · 16 comments · Fixed by #1803
Closed

Fmriprep handling of multi-echo data with single-band reference scans #1745

markushs opened this issue Aug 23, 2019 · 16 comments · Fixed by #1803

Comments

@markushs
Copy link
Contributor

Hi, I posted this on neurostars a while ago:
(https://neurostars.org/t/fmriprep-handling-of-multi-echo-data-with-single-band-reference-scans/4822).
Registration of Multi-echo multi-band (MEMB) data would likely benefit from using single-band reference scans (when available). Right now I believe registration is done based on some kind of average of the volumes representing the first echo, and with multiband the contrast in these images gets very low.

As we cannot openly share participant data from the relevant project, we've collected MEMB data on two volunteers in our lab for the purpose of sharing. If someone thinks it's worthwhile looking into this, let me know and I will provide you with the data (or put it on openneuro, if that's better).

Thanks!
Markus

@effigies
Copy link
Member

If your participants are willing to have their scans put on OpenNeuro (note that OpenNeuro releases all data under CC0), that would probably be simplest (we can just grab it with DataLad), and make it easier for others to benefit from the effort you went to.

@markushs
Copy link
Contributor Author

Here it is:
https://openneuro.org/datasets/ds002147/versions/1.0.0

@oesteban oesteban added the me-epi label Sep 3, 2019
@tsalo
Copy link
Collaborator

tsalo commented Sep 16, 2019

How should single-band reference images fit into the multi-echo workflow?

I assume that the goal here is to use the single-band reference images (probably the one for the first echo) as BOLD reference images for motion correction and brain-mask generation. Then, if t2s_coreg is not enabled, use the single-band reference image for coregistration?

Is that roughly the extent to which the single-band reference images would be used with multi-echo data?

@markushs
Copy link
Contributor Author

In addition to the steps mentioned above I would ensure that the echo-1 sbref is used for all co-registration steps not involving the T2*-map (e.g. with fieldmaps). We get sub-optimal results for quite a few subjects at this step.

An example.:

image

@tsalo
Copy link
Collaborator

tsalo commented Sep 17, 2019

Would it make sense to use the mean SBRef (averaged across echoes) instead of just echo 1?

@markushs
Copy link
Contributor Author

Dropout typically becomes quite prominent at later echoes, and in my experience there is sufficient contrast in the echo-1 sbref. So my immediate intuition would be to just use echo 1 rather than the mean, at least when sbrefs are available.

@tsalo
Copy link
Collaborator

tsalo commented Sep 19, 2019

I could be very wrong, but it does seem like this could be solved by just removing the multi-echo-specific elif here:

https://github.com/poldracklab/fmriprep/blob/243b227fd3dfa841aa115b0369246301f8d7f854/fmriprep/workflows/bold/base.py#L320-L333

I read through the workflow connections and it seems like the T2* image would take over for the original reference image at the right time, regardless of whether that reference image is an SBRef or something pulled from the first echo.

@emdupre does that sound right?

@effigies
Copy link
Member

I'm having trouble remembering if we put that simply because we didn't have test data, or some other reason. I can try to look around later today, if y'all don't figure it out first.

@tsalo
Copy link
Collaborator

tsalo commented Sep 20, 2019

It seems reasonable to default to using the first echo's SBRef as the reference image, but if possible I'd like to feed all SBRefs into niworkflows.func.util.init_bold_reference_wf and to let that workflow select the first echo internally. That way, if there are improvements that can use multiple echoes' SBRefs, they can be implemented directly in niworkflows without having to make any changes to fMRIPrep.

Does that sound alright to everyone?

@effigies
Copy link
Member

@tsalo That sounds perfectly reasonable to me.

@tsalo
Copy link
Collaborator

tsalo commented Sep 21, 2019

@effigies Awesome. I'll open a corresponding issue in niworkflows to allow multiple values for sbref_file. It should also be pretty easy to pass multiple SBRefs from fMRIPrep to init_bold_reference_wf. I think it would just be a good idea to be more explicit about selecting rec-magnitude SBRefs instead of rec-phase ones at that point.

@emdupre
Copy link
Collaborator

emdupre commented Sep 24, 2019

I read through the workflow connections and it seems like the T2* image would take over for the original reference image at the right time, regardless of whether that reference image is an SBRef or something pulled from the first echo.

@emdupre does that sound right?

Yes, that sounds right. @effigies is also right that we didn't have access to multi-echo data with these scans when originally writing the workflow, so we weren't making use of that data (hence the elif). I think your solution sounds great, @tsalo, thanks !

@emdupre
Copy link
Collaborator

emdupre commented Sep 25, 2019

Another data point on the need to handle SBRefs with MEEPI data: https://neurostars.org/t/fmriprep-poor-registration-between-functionals-and-anatomical/4981/3

@cphaneuf
Copy link

Thanks for raising this issue! We are also having problems with our fMRIPrep brain mask output for select participants, due to the creation of the “boldref” volume for a multiecho series. That is, our brain masks are accurate when running fMRIPrep with only echo 1, instead of summing echoes 1 and 4. Will the proposed fix be incorporated into fMRIPrep soon? Thanks again!

@oesteban
Copy link
Member

oesteban commented Jun 3, 2020

Yes @cphaneuf, we are actively working on that fix and will be included in the upcoming 20.2 release.

@cphaneuf
Copy link

cphaneuf commented Jun 5, 2020

Great, thanks for the update!

@oesteban oesteban added this to Triage in pipelines via automation Jun 7, 2020
@oesteban oesteban moved this from Triage to Awaiting review in pipelines Jun 7, 2020
@oesteban oesteban added this to the 20.2.0 LTS milestone Jun 7, 2020
pipelines automation moved this from Awaiting review to Done Jun 9, 2020
@oesteban oesteban removed this from Done in pipelines Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants