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: Confounds metadata #1708
ENH: Confounds metadata #1708
Conversation
rciric
commented
Jul 20, 2019
- Resolves Write out metadata about Global Signal regressors #1617
- Resolves Write out metadata about ICA-AROMA regressors #1618
At some point this evening I thought I'm mad when found myself with AROMA's
repo open and thinking about exactly that :p
A couple of things discouraged me from starting right away:
- First, the project seems a bit abandoned, judging by the outstanding PR
proposing a 0.4.4 release. We will need a fast turnaround
- The other is that we might just implement it as an interface for nipype
like compcor. The current implementation has a lot of boilerplate to run
normalization and MELODIC which we don't need. Maybe just picking up the
classification of components would suffice.
…On Wed, Sep 11, 2019, 18:04 Chris Markiewicz ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In fmriprep/workflows/bold/confounds.py
<#1708 (comment)>:
> @@ -687,6 +690,13 @@ def _getusans_func(image, thresh):
ica_aroma_confound_extraction = pe.Node(ICAConfounds(err_on_aroma_warn=err_on_aroma_warn),
name='ica_aroma_confound_extraction')
+ ica_aroma_metadata_fmt = pe.Node(
+ TSV2JSON(index_column='IC', output=None, enforce_case=True,
+ additional_metadata={'Method': {
+ 'Name': 'ICA-AROMA',
+ 'Version': '0.3-beta'}}),
Would it make sense just to help package ICA-AROMA, make sure it has
__version__, and put it on PyPI?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1708>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAESDRXJEER4Q3NQE436YV3QJGISDANCNFSM4IFN3O4A>
.
|
Maybe a good candidate for repackaging as a niflow (so we don't have to worry about perceived authorship, as we would if we just packaged up AROMA and pushed it without @maartenmennes' blessing)? Is there anything besides version numbering that we actually need to update in the short term? If not, we can target a hackathon where there are two or three of us who are familiar with nipype and AROMA to just get the thing done. As for determining the version dynamically, perhaps we can do a diff between releases and see if we can find a characteristic string or object that can be used as an indicator of the version. |
Just to note: this PR is still failing (https://circleci.com/gh/poldracklab/fmriprep/9634). It doesn't look like a big deal.
|