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

ENH: Remove t2s-coreg #2109

Merged
merged 14 commits into from
May 1, 2020
Merged

ENH: Remove t2s-coreg #2109

merged 14 commits into from
May 1, 2020

Conversation

tsalo
Copy link
Collaborator

@tsalo tsalo commented Apr 29, 2020

Resolves #1786. This builds off of #1800, but removes the T2*-based coregistration option completely, based on the most recent comments in #1786 and discussion with @emdupre.

Changes proposed in this pull request

  • Remove --t2s-coreg option from CLI
  • Remove t2s_coreg-related steps from workflows.
  • Remove mention of --t2s-coreg option from docs/workflows.rst.

Documentation that should be reviewed

  • In docs/workflows.rst, I remove a sentence about --t2s-coreg.

@auto-comment
Copy link

auto-comment bot commented Apr 29, 2020

Thank your for raising your pull request.

Some of the fMRIPRep maintainers will review your changes as soon as time permits.
I'm attaching below a Review Checklist for the reviewers, to check off during the
review.

PR Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work.

Please check what applies in the following aspects of the PR:

Code documentation

  • New functions and modules are documented following the guidelines.
  • Existing code required amendments in documentation and has been updated.
  • Sufficient inline comments ensure readability by other contributors in the long term.

Documentation site

  • The modifications to fMRIPrep in this PR do not require extra documentation. This is a common situation when a bug fix that does not change the code base substantially is submitted.
  • This PR requires documentation. The corresponding documentation will be submitted as an additional PR in the future.
  • This PR requires extra documentation, and will be included within this PR. Please check the boxes that apply best:
    • An existing feature is substantially modified, changing the interface and/or logic of a module.
    • A new feature is being added, therefore full documentation of it will be included
    • This PR addresses an error in existing documentation.
  • Yes, all expected sections of documentation were generated by the CI build, and look as expected

Tests

  • The new functionalities in this PR are covered by the existing tests
  • New test batteries have been included with this PR

Data

  • This PR does not require any additional data to be uploaded to OSF.
  • This PR requires additional data for tests.

Dependencies: smriprep

  • This PR does not require any update on smriprep; or
  • smriprep has correctly been pinned.

Dependencies: niworkflows

  • This PR does not require any update on niworkflows; or
  • niworkflows has correctly been pinned.

Dependencies: sdcflows

  • This PR does not require any update on sdcflows; or
  • sdcflows has correctly been pinned.

Dependencies: Nipype

  • This PR does not require any update on nipype; or
  • nipype has correctly been pinned.

Dependencies: other

  • This PR does not require any update on other dependencies; or
  • other dependencies have correctly been pinned.

Reports generated within CI tests

  • Yes, I have checked the reports of ds005 and they are not modified or the changes are as expected
  • Yes, I have checked the reports of ds054 and they are not modified or the changes are as expected
  • Yes, I have checked the reports of ds010 and they are not modified or the changes are as expected

Copy link
Member

@oesteban oesteban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't checked locally, but this looks pretty awesome. I'll try to review and get this merged tomorrow.

Thanks much for this!

('outputnode.skull_stripped_file', 'bold_ref_brain')]),
(t2smap_node, outputnode, [
('optimal_comb', 'bold'),
('t2star_map', 'bold_ref_brain')]),
Copy link
Member

@effigies effigies Apr 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This workflow is now inputnode -> t2smap_node -> outputnode, so the workflow itself can be replaced in the calling function by t2smap_node. Unless it's useful to keep this space open to expand the workflow in the future?

Also, bold_ref_brain does not seem to be being used anywhere.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if implementing it would require that bold_t2s_wf remain a workflow, but in #1010 (comment) I'm proposing a way to incorporate tedana's component classification into fMRIPrep. It might be worth it to keep the workflow around until #1010 is resolved at least.

I can remove bold_ref_brain now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Let's keep this change minimal and we can reconsider architecture later. I realized there's also the workflow description that would need to be moved out of this separate module.

Copy link
Collaborator

@mgxd mgxd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsalo
Copy link
Collaborator Author

tsalo commented May 1, 2020

@mgxd thank you for catching that. It should be good now.

@mgxd
Copy link
Collaborator

mgxd commented May 1, 2020

LGTM, thanks!

@oesteban
Copy link
Member

oesteban commented May 1, 2020

@effigies @mgxd merge? I'd like to see how #2108 is affected by this.

@effigies
Copy link
Member

effigies commented May 1, 2020

LGTM. Merge at will, @oesteban.

@oesteban oesteban merged commit c0fe8b0 into nipreps:master May 1, 2020
@tsalo tsalo deleted the enh/remove-t2s-coreg branch May 1, 2020 17:20
@tsalo tsalo mentioned this pull request May 5, 2020
@Shotgunosine
Copy link
Contributor

Sorry for the naive question, when would I expect to see this change in a release?

@effigies
Copy link
Member

effigies commented May 8, 2020

20.1.0, which is coming Real Soon Now.

Seriously, we're trying to wrap up as quickly as possible, but everything's taking longer than we intended.

Out of curiosity, is this a feature that you needed?

@Shotgunosine
Copy link
Contributor

If I've followed all of the references right, I think this PR started with an issue I had with masking multi-echo rest sequences:
https://neurostars.org/t/registrations-and-brainmasks/4876/16

I had forgotten about it and ran fmriprepv20.0.5 without selecting a single echo (which was my work around) and found that a lot of the rest sequences have brain excluded from the brain mask around the base of the brain, which was the original issue:

Screen Shot 2020-05-08 at 11 05 52 AM
I'm hoping that the new masking implemented here resolves this so that i can use the optimally combined rest instead of just a single echo.

@Shotgunosine
Copy link
Contributor

@tsalo, I know I'm lat to the party here, but did you by any chance check to see if the masking here works on this dataset: https://openneuro.org/datasets/ds002156/versions/1.0.0

@tsalo
Copy link
Collaborator Author

tsalo commented May 8, 2020

@Shotgunosine I haven't checked the masking at all, sorry. I built this PR off of @emdupre's initial work in #1800, which I believe dealt with the masking more than what I added, which was just removing the t2s_coreg option from the workflow (and thus didn't touch non-t2s-coreg masking).

However, there was a glaring masking bug in the t2smap workflow in tedana <= 0.0.8 (see ME-ICA/tedana#544). I think that that bug could be responsible for at least some of the problems, and we should probably check how the masking works once 0.0.9 is released and I've pinned that version in fMRIPrep (see #2117).

@Shotgunosine
Copy link
Contributor

Ok, sounds good. Looking at #1800 it seems like she verified that those changes worked with my data, so I'm optimistic that 20.1 will help when it gets here.

@emdupre
Copy link
Collaborator

emdupre commented May 8, 2020

In 04cf152 I moved all of the bold_mask generation steps outside of the T2* interface, so it should be using the same bold_mask that's generated from the SDC workflow. Which, in the case of multi-echo data, will be from the first echo rather than from the optimal combination ! So I don't think that the masking that you're mentioning @tsalo will really impact, here (but happy to discuss more out-of-band !).

Regardless, yes, I ran on yours locally and it looked right @Shotgunosine ! But fMRIPrep has had a lot of updates since then, so I'd be curious to re-run with a patched docker image for the current master.

@effigies
Copy link
Member

effigies commented May 8, 2020

To test with master:

fmriprep-docker -i poldracklab/fmriprep:unstable ...

@Shotgunosine
Copy link
Contributor

I tested with unstable yesterday and it seems like it got much better masks on that test subject.
Screen Shot 2020-05-20 at 3 03 48 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RFC: Updating t2s_coreg for MEEPI
6 participants