Parcellation // Supplementary data about fmriprep HOT 10 CLOSED

Is this the template for brain extraction? IT's available here:
https://figshare.com/articles/ANTs_ANTsR_Brain_Templates/915436
We can make a fetcher (similar to those in nilearn) that downloads the
required templates from figshare.

On Tue, Mar 15, 2016 at 10:58 AM, Oscar Esteban [email protected]
wrote:

For now, there is only one data resource (a brain parcellation) that does
not belong to the FSL package and is used along the workflow.

I assume (@craigmoodie https://github.com/craigmoodie can correct me if
I'm wrong) that the user should have the possibility to change this file,
but generally, the default one will be used.

@chrisfilo https://github.com/chrisfilo: what do you think about having
a data/ or resources/ folder where we keep and distribute these files.
Right now we would place here a parcellation that is publicly available
through neurovault. We would need to have a LICENSE file in that folder,
indicating the appropriate licensing for each of the data files distributed.

Otherwise, a systematic solution to these data requirements should be
defined.

Once this decision is made, we would close this issue when @craigmoodie
https://github.com/craigmoodie places this file where we have decided.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8

from fmriprep.

Nope, it is a parcellation for the functional connectivity matrix. Am I correct, @craigmoodie ?

For those files supplied within other packages we will need to implement fetchers and a cache folder (btw, a nice new feature for nipype), but I think this is our file.

from fmriprep.

Calculating functional connectivity should not be part of this workflow. It
should only do preprocessing. Analysis pipelines (such as parcellation
based functional connectivity, but many others) should work on outputs of
the preprocessing pipeline as a separate package.

+1 for nilearn style fetcher as a nipype interface!

On Tue, Mar 15, 2016 at 11:09 AM, Oscar Esteban [email protected]
wrote:

Nope, it is a parcellation for the functional connectivity matrix. Am I
correct, @craigmoodie https://github.com/craigmoodie ?

For those files supplied within other packages we will need to implement
fetchers and a cache folder (btw, a nice new feature for nipype), but I
think this is our file.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8 (comment)

from fmriprep.

I don't think this workflow computes any connectivity. I may be wrong, but I guess it resamples the parcellation into subject space to be used in the connectivity pipeline afterwards (@craigmoodie?).

Anyways, we potentially may see this situation with some other file, maybe in some other project. I think it is worth making a decision on how to redistribute these resources...

EDIT: @craigmoodie , where do brain_probmask.nii.gz, brain_template.nii.gz and reg_mask.nii.gz come from?

from fmriprep.

Hi Oscar,

Chris is right that the original vision for the standard implementation of the workflow does not include generating parcel or ROI time series. I think having this as an option would be nice, but for now you can just remove the nodes related to transforming the parcels to native space, as this is not a top priority.

from fmriprep.

I used to Oasis template but another user might want to use a different template that better fits their data. All ANTs templates can be found at the address Chris posted above.

from fmriprep.

I think resampling the parcellation into subject's space is ok for a preprocessing workflow. Moreover it is implemented, so I don't see a good reason to remove it.

What do you think we should do with this kind of resources? Package them with the workflow? Just provide a link and fetch/cache them?

from fmriprep.

There are many parcellation schemes people would like to use. There are
also connectivity analyses that do not use parcellation schemes (for
example see based connectivity). I think we should aim at building a set of
tools each doing one thing very well instead of many things poorly. This
tool should focus on preprocessing providing inputs to many different
higher level analyses. Think a set of precision tools instead of swiss army
knife. Think google instead of altavista/yahoo.

Eventually, we will also build a tool for doing parcellation based
connectivity analysis, but that tool will not do any preprocessing and be
based on the outputs of the preprocessing workflow. Maybe instead of
removing the parcellation resampling code we could just move it to a place
which would eventually evolve to a parcellation connectivity analysis tool.

In terms of resources I like the idea of putting them in a repository like
figshare or dataverse and accessing it programmatically during installation
or packaging for pypi.

On Tue, Mar 15, 2016 at 5:39 PM, Oscar Esteban [email protected]
wrote:

I think resampling the parcellation into subject's space is ok for a
preprocessing workflow. Moreover it is implemented, so I don't see a good
reason to remove it.

What do you think we should do with this kind of resources? Package them
with the workflow? Just provide a link and fetch/cache them?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8 (comment)

from fmriprep.

Totally agree with this

Sent from my iPhone

On Mar 15, 2016, at 5:50 PM, Chris Filo Gorgolewski [email protected] wrote:

There are many parcellation schemes people would like to use. There are
also connectivity analyses that do not use parcellation schemes (for
example see based connectivity). I think we should aim at building a set of
tools each doing one thing very well instead of many things poorly. This
tool should focus on preprocessing providing inputs to many different
higher level analyses. Think a set of precision tools instead of swiss army
knife. Think google instead of altavista/yahoo.

Eventually, we will also build a tool for doing parcellation based
connectivity analysis, but that tool will not do any preprocessing and be
based on the outputs of the preprocessing workflow. Maybe instead of
removing the parcellation resampling code we could just move it to a place
which would eventually evolve to a parcellation connectivity analysis tool.

In terms of resources I like the idea of putting them in a repository like
figshare or dataverse and accessing it programmatically during installation
or packaging for pypi.

On Tue, Mar 15, 2016 at 5:39 PM, Oscar Esteban [email protected]
wrote:

I think resampling the parcellation into subject's space is ok for a
preprocessing workflow. Moreover it is implemented, so I don't see a good
reason to remove it.

What do you think we should do with this kind of resources? Package them
with the workflow? Just provide a link and fetch/cache them?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8 (comment)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

from fmriprep.

Thanks a lot, I guess this issue can be closed now.

from fmriprep.