search

nipreps / fmriprep

fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
https://fmriprep.org
Apache License 2.0
631 stars 293 forks source link

Running only functionals #755

Open oesteban opened 6 years ago

oesteban commented 6 years ago

A good option to have would be running FMRIPREP without T1w images under two possible circumstances:

(comes from this discussion)

madeleinesnyder commented 6 years ago

Which script would be the best place to start with this? I tried changing run.py and just take away the raise exception when "No T1w images found", but then the workflow messed up. Is there a good junction to insert a "skip this part"?

oesteban commented 6 years ago

I think your target here would be writing an equivalent to init_single_subject_wf:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L210-L462

where no anatomical workflows are instantiated and run. Without meaning to discourage you, I must note that this will have a steep learning curve :P. We'll try to help as much as we can, but we can't take this as a priority right now. I can see that in one month this would probably change.

effigies commented 6 years ago

In run.py, there's an --anat-only option, that you can imitate:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88

You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban suggests). Any of these seems fine to me.

That will produce an opts.func_only (or bold_only or dismiss_t1w) that will need to be passed to init_fmriprep_wf:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327

This option will need to be added to the workflows in fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and fmriprep/workflows/confounds.py.

The effects of --anat-only will be easy to mimic in base.py, and I think confounds.py should be pretty easy to pick out the confounds that require anatomical inputs and disable them.

bold.py is going to be the complicated one, as a bunch of subworkflows and connections should only be created if anatomicals are going to be used. You may want to look at how if freesurfer blocks work, as there are workflows that are based on whether or not the user wants to use FreeSurfer.

madeleinesnyder commented 6 years ago

Cool. I'm trying to puzzle out the bold_reg_wf because i think this is the place I want to say: "if dismiss_t1w, then do the bold_reg_wf with the mni brain and not the t1w because it doesn't exist. My confusion comes from where 't1_brain' is inputted to this workflow. Is there a master function coordinating the 't1_brain', 'bold_mask', etc things inside the workflow.connect function?

On Wed, Oct 11, 2017 at 12:50 PM, Chris Markiewicz <notifications@github.com

wrote:

In run.py, there's an --anat-only option, that you can imitate:

https://github.com/poldracklab/fmriprep/blob/ a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88

You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban https://github.com/oesteban suggests). Any of these seems fine to me.

That will produce an opts.func_only (or bold_only or dismiss_t1w) that will need to be passed to init_fmriprep_wf:

https://github.com/poldracklab/fmriprep/blob/ a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327

This option will need to be added to the workflows in fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and fmriprep/workflows/confounds.py.

The effects of --anat-only will be easy to mimic in base.py, and I think confounds.py should be pretty easy to pick out the confounds that require anatomical inputs and disable them.

bold.py is going to be the complicated one, as a bunch of subworkflows and connections should only be created if anatomicals are going to be used. You may want to look at how if freesurfer blocks work, as there are workflows that are based on whether or not the user wants to use FreeSurfer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-335927482, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLdNBWQz-ZC3AFWpzyGhTW3MyLklYks5srRv2gaJpZM4P15YA .

madeleinesnyder commented 6 years ago

Or rather-- how are the input node fields (such as inputnode.t1_brain) populated?

On Thu, Oct 12, 2017 at 11:42 AM, Madeleine Snyder < madeleine.snyder.48@gmail.com> wrote:

Cool. I'm trying to puzzle out the bold_reg_wf because i think this is the place I want to say: "if dismiss_t1w, then do the bold_reg_wf with the mni brain and not the t1w because it doesn't exist. My confusion comes from where 't1_brain' is inputted to this workflow. Is there a master function coordinating the 't1_brain', 'bold_mask', etc things inside the workflow.connect function?

On Wed, Oct 11, 2017 at 12:50 PM, Chris Markiewicz < notifications@github.com> wrote:

In run.py, there's an --anat-only option, that you can imitate:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49f b57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88

You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban https://github.com/oesteban suggests). Any of these seems fine to me.

That will produce an opts.func_only (or bold_only or dismiss_t1w) that will need to be passed to init_fmriprep_wf:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49f b57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327

This option will need to be added to the workflows in fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and fmriprep/workflows/confounds.py.

The effects of --anat-only will be easy to mimic in base.py, and I think confounds.py should be pretty easy to pick out the confounds that require anatomical inputs and disable them.

bold.py is going to be the complicated one, as a bunch of subworkflows and connections should only be created if anatomicals are going to be used. You may want to look at how if freesurfer blocks work, as there are workflows that are based on whether or not the user wants to use FreeSurfer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-335927482, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLdNBWQz-ZC3AFWpzyGhTW3MyLklYks5srRv2gaJpZM4P15YA .

oesteban commented 6 years ago

They are set in by connecting this node:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L363-L364

to those fields in the top-level workflow, eg.:

https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L407-L408

sets the anatomical inputs.

effigies commented 6 years ago

To narrowly answer your question, t1_brain is set in bold_reg_wf in this line:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L353

I will say that registering BOLD to MNI is probably going to be the most difficult thing to attempt in our current setup. bold_reg_wf attempts to find affine transforms using FLIRT or mri_coreg/bbregister, which is then concatenated with a T1-MNI transform found by ANTs (in bold_mni_trans_wf).

If you want to estimate a nonlinear transform directly from BOLD to a template T2w or EPI image, that would probably be best handled by a new sub-workflow that bypasses both bold_reg_wf and bold_mni_trans_wf entirely, rather than repurposing these.

madeleinesnyder commented 6 years ago

Ok, my intuition is to insert:

if dismiss_t1w: [new workflow code here] return workflow

just before line 346 in bold.py

is this on the right track?

On Thu, Oct 12, 2017 at 11:51 AM, Oscar Esteban notifications@github.com wrote:

They are set in by connecting this node:

https://github.com/poldracklab/fmriprep/blob/ a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/ base.py#L363-L364

to those fields in the top-level workflow, eg.:

https://github.com/poldracklab/fmriprep/blob/ a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/ base.py#L407-L408

sets the anatomical inputs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336231746, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLe6hcm7-5ZZkNosV0XqzdK9otguyks5srl_PgaJpZM4P15YA .

oesteban commented 6 years ago

Yes, that's the right direction. The problem, as Chris mentioned, resides on the fact that currently, BOLD workflows depend on anatomical inputs.

Since the anatomical workflows do not depend on BOLD workflows, it was relatively easy to use the approach you mentioned.

So the hard problem here is where you wrote: "[new workflow code here]" because you'll indeed need a new workflow (without dependencies on anatomical) here.

madeleinesnyder commented 6 years ago

Ok, Really the problem I want to solve is that if there are no T1w images available for a certain scan, the whole thing won't run at all. I wanted to create a functional only workflow to solve this problem.

On Thu, Oct 12, 2017 at 12:11 PM, Oscar Esteban notifications@github.com wrote:

Yes, that's the right direction. The problem, as Chris mentioned, resides on the fact that currently, BOLD workflows depend on anatomical inputs.

Since the anatomical workflows do not depend on BOLD workflows, it was relatively easy to use the approach you mentioned.

So the hard problem here is where you wrote: "[new workflow code here]" because you'll indeed need a new workflow (without dependencies on anatomical) here.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336236987, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLX5iggrHZr1Xxup6ZB_w8UMOzcp9ks5srmR5gaJpZM4P15YA .

effigies commented 6 years ago

I'll try to pare this down to the minimum things you need to do just to get it running, and we can work from there to build out the remaining needed functionality, such as registration to MNI. Assuming you have a variable dismiss_t1w.

Split this chunk:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L346-L390

Into two bits, to be schematic as possible:

workflow.connect([
    # Only connect workflows that do not require T1w processing
    ])
if not dismiss_t1w:
    workflow.connect([
        # Connect up the rest
        ])

These lines take the following form:

(from_node, to_node, [('from_name', 'to_name')]),

Nodes that do not require T1w preprocessing are:

For the moment, I would entirely disable fieldmaps by commenting out:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L413-L480

And replace with:

if True:

Comment these lines out, as well:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L487-L489 https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L492-L579

Then pacify summary:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L280-L286

by adding the following lines:

if dismiss_t1w:
    summary.inputs.fallback = False
    summary.inputs.confounds_list = []

Finally, disable some reports by commenting out these lines:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L1605-L1612

I think that should technically run. You will get some minimal reports, but no derivatives. If you want BOLD series in their original BOLD space, that will need a new workflow, as will an MNI registration workflow.

Once you have this, start a PR, and we can comment directly on that, which should make things easier.

madeleinesnyder commented 6 years ago

Wow this a lot to go on thank you so much! I'll start cracking

On Thu, Oct 12, 2017 at 12:35 PM, Chris Markiewicz <notifications@github.com

wrote:

I'll try to pare this down to the minimum things you need to do just to get it running, and we can work from there to build out the remaining needed functionality, such as registration to MNI. Assuming you have a variable dismiss_t1w.

Split this chunk:

https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L346-L390

Into two bits, to be schematic as possible:

workflow.connect([

Only connect workflows that do not require T1w processing

])if not dismiss_t1w:
workflow.connect([
    # Connect up the rest
    ])

These lines take the following form:

(from_node, to_node, [('from_name', 'to_name')]),

Nodes that do not require T1w preprocessing are:

  • inputnode, outputnode
  • bold_reference_wf
  • bold_stc_wf
  • bold_hmc_wf
  • func_reports_wf
  • summary

For the moment, I would entirely disable fieldmaps by commenting out:

https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L413-L480

And replace with:

if True:

Comment these lines out, as well:

https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L487-L489 https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L492-L579

Then pacify summary:

https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L280-L286

by adding the following lines:

if dismiss_t1w: summary.inputs.fallback = False summary.inputs.confounds_list = []

Finally, disable some reports by commenting out these lines:

https://github.com/poldracklab/fmriprep/blob/ 0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/ bold.py#L1605-L1612

I think that should technically run. You will get some minimal reports, but no derivatives. If you want BOLD series in their original BOLD space, that will need a new workflow, as will an MNI registration workflow.

Once you have this, start a PR, and we can comment directly on that, which should make things easier.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336243011, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLfQWWMy2UYv9Fh0KJkkeSqhB_OqTks5srmoMgaJpZM4P15YA .

madeleinesnyder commented 6 years ago

I thought of another workaround that might be easier:

Would it be ok to use a dummy T1 dataset as a placeholder to get the pipeline to run, and have the --output-space be template so that the dummy T1 isn't used for coregistration? Or would the dummy be automatically used in other parts of the pipeline even if the output space is "template"?

On Thu, Oct 12, 2017 at 12:41 PM, Madeleine Snyder < madeleine.snyder.48@gmail.com> wrote:

Wow this a lot to go on thank you so much! I'll start cracking

On Thu, Oct 12, 2017 at 12:35 PM, Chris Markiewicz < notifications@github.com> wrote:

I'll try to pare this down to the minimum things you need to do just to get it running, and we can work from there to build out the remaining needed functionality, such as registration to MNI. Assuming you have a variable dismiss_t1w.

Split this chunk:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L346-L390

Into two bits, to be schematic as possible:

workflow.connect([

Only connect workflows that do not require T1w processing

])if not dismiss_t1w:
workflow.connect([
    # Connect up the rest
    ])

These lines take the following form:

(from_node, to_node, [('from_name', 'to_name')]),

Nodes that do not require T1w preprocessing are:

  • inputnode, outputnode
  • bold_reference_wf
  • bold_stc_wf
  • bold_hmc_wf
  • func_reports_wf
  • summary

For the moment, I would entirely disable fieldmaps by commenting out:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L413-L480

And replace with:

if True:

Comment these lines out, as well:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L487-L489 https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L492-L579

Then pacify summary:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L280-L286

by adding the following lines:

if dismiss_t1w: summary.inputs.fallback = False summary.inputs.confounds_list = []

Finally, disable some reports by commenting out these lines:

https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6 e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L1605-L1612

I think that should technically run. You will get some minimal reports, but no derivatives. If you want BOLD series in their original BOLD space, that will need a new workflow, as will an MNI registration workflow.

Once you have this, start a PR, and we can comment directly on that, which should make things easier.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336243011, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLfQWWMy2UYv9Fh0KJkkeSqhB_OqTks5srmoMgaJpZM4P15YA .

oesteban commented 6 years ago

Unfortunately, the BOLD is mapped to MNI through the T1w space :(. I'm afraid that would not work.

madeleinesnyder commented 6 years ago

Rats ok I'll work on chagning the pipeline then

On Thu, Oct 12, 2017 at 2:52 PM, Oscar Esteban notifications@github.com wrote:

Unfortunately, the BOLD is mapped to MNI through the T1w space :(. I'm afraid that would not work.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336284129, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLRTS82xKi5m6ZBBQj62cvoIkgLNvks5srooJgaJpZM4P15YA .

chrisgorgo commented 6 years ago

What about directly coregistering the BOLD images to an EPI MNI template?

madeleinesnyder commented 6 years ago

Would that work? If I put in the EPI MNI template as the dummy?

On Thu, Oct 12, 2017 at 2:55 PM, Chris Filo Gorgolewski < notifications@github.com> wrote:

What about directly coregistering the BOLD images to an EPI MNI template?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336285228, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLQgS2QCuO0WC29KxDKq5qwQiXoTrks5srorPgaJpZM4P15YA .

oesteban commented 6 years ago

@madeleinesnyder, @chrisfilo both statements from you are the shortest path to the goal.

oesteban commented 6 years ago

Sorry, @madeleinesnyder that means that the BOLD is co-registered to some image in MNI space. Probably the T2w image is a good target.

oesteban commented 6 years ago

An example of how that is done on mriqc:

https://github.com/poldracklab/mriqc/blob/master/mriqc/workflows/functional.py#L680-L749

However, in this case you will want to use the 'precise' settings set because you don't want a quick and dirty registration.

madeleinesnyder commented 6 years ago

Ok, so on a broad level:

If no t1 data for a subject: don't just abort; enter workflow that does epi_mni_align

Which are the parts of the current workflow that are analogs to where I should insert the epi_mni_align node?

On Thu, Oct 12, 2017 at 3:00 PM, Oscar Esteban notifications@github.com wrote:

An example of how that is done on mriqc:

https://github.com/poldracklab/mriqc/blob/master/ mriqc/workflows/functional.py#L680-L749

However, in this case you will want to use the 'precise' settings set because you don't want a quick and dirty registration.

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

oesteban commented 6 years ago

There are some other workflows you'll probably need. Chris pointed them out before:

You'll need to use those, plus the epi_mni_align workflow. Finally, we'll point you to the last bit, where the transforms from bold_hmc_wf and epi_mni_align are combined to generate the final _preproc file.

madeleinesnyder commented 6 years ago

Ok. Should I create a new python script or add all of this to bold.py?

On Thu, Oct 12, 2017 at 3:27 PM, Oscar Esteban notifications@github.com wrote:

There are some other workflows you'll probably need. Chris pointed them out before:

  • bold_reference_wf - generates a reference image in BOLD space, this is probably the reference you will want to use in the registration to MNI space.
  • bold_stc_wf - slice timing correction
  • bold_hmc_wf - head motion estimation
  • func_reports_wf - arranges the reports so they are collated in the final big html file.
  • summary - creates that summary part for the big html file.

You'll need to use those, plus the epi_mni_align workflow. Finally, we'll point you to the last bit, where the transforms from bold_hmc_wf and epi_mni_align are combined to generate the final _preproc file.

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

oesteban commented 6 years ago

Let's start in that bold.py and then we can help you if it grows too large

madeleinesnyder commented 6 years ago

Ok this amount of change merits inserting the dismiss_t1w flag. Should I include the following workflows in the dismiss_t1w workflow?:

bold_stc_wf nonlinear_sdc_wf bold_mni_trans_wf bold_surf_wf

Thank you so much, for all of your help, I really appreciate it!

On Thu, Oct 12, 2017 at 3:35 PM, Oscar Esteban notifications@github.com wrote:

Let's start in that bold.py and then we can help you if it grows too large

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

oesteban commented 6 years ago

I think

The surf one does not make sense since the surfaces are reconstructed on the T1.

madeleinesnyder commented 6 years ago

OK cool, and should bold_confounds be included?

On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban notifications@github.com wrote:

I think

  • bold_stc_wf
  • nonlinear_sdc_wf
  • bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on the T1.

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

oesteban commented 6 years ago

Yes, but taking care of not including aCompCor (anatomical Comp Cor)

On Thu, Oct 12, 2017 at 4:09 PM, Maddie Snyder notifications@github.com wrote:

OK cool, and should bold_confounds be included?

On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban notifications@github.com wrote:

I think

  • bold_stc_wf
  • nonlinear_sdc_wf
  • bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on the T1.

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

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

madeleinesnyder commented 6 years ago

Ok I got it working. I'll do a few test data runs and then maybe post it.

On Thu, Oct 12, 2017 at 4:13 PM, Oscar Esteban notifications@github.com wrote:

Yes, but taking care of not including aCompCor (anatomical Comp Cor)

On Thu, Oct 12, 2017 at 4:09 PM, Maddie Snyder notifications@github.com wrote:

OK cool, and should bold_confounds be included?

On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban <notifications@github.com

wrote:

I think

  • bold_stc_wf
  • nonlinear_sdc_wf
  • bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on the T1.

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

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

.

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

chrisgorgo commented 6 years ago

I asked around for manage to get this ENIGMA EPI template which seems to be a good candidate for coregistration: https://neurovault.org/images/55594/

@oesteban should we add it to niworkflows?

effigies commented 6 years ago

Seems reasonable to me to add it. There is also just the SPM EPI template that Vince used in the EPInorm paper. Not sure what advantages one has over the other, though.

Also @oesteban nonlinear_sdc_wf depends on the T1 in some pretty unescapable ways. We can do fieldmap correction, but not SyN-SDC, without the T1w images.

chrisgorgo commented 6 years ago

Wouldn't constrained nonlinear coregistration to the EPI MNI template work as a form of SDC?

On Oct 13, 2017 9:43 AM, "Chris Markiewicz" notifications@github.com wrote:

Seems reasonable to me to add it. There is also just the SPM EPI template that Vince used in the EPInorm paper. Not sure what advantages one has over the other, though.

Also @oesteban https://github.com/oesteban nonlinear_sdc_wf depends on the T1 in some pretty unescapable ways. We can do fieldmap correction, but not SyN-SDC, without the T1w images.

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

oesteban commented 6 years ago

Depends on how you built the template and how well the images used were corrected.

@effigies right, SDC uses the T1

Yes, good addition to niworkflows

On Oct 12, 2017 6:49 PM, "Chris Filo Gorgolewski" notifications@github.com wrote:

Wouldn't constrained nonlinear coregistration to the EPI MNI template work as a form of SDC?

On Oct 13, 2017 9:43 AM, "Chris Markiewicz" notifications@github.com wrote:

Seems reasonable to me to add it. There is also just the SPM EPI template that Vince used in the EPInorm paper. Not sure what advantages one has over the other, though.

Also @oesteban https://github.com/oesteban nonlinear_sdc_wf depends on the T1 in some pretty unescapable ways. We can do fieldmap correction, but not SyN-SDC, without the T1w images.

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

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

effigies commented 6 years ago

Certainly if we believe the EPInorm paper, and can figure out the "right" constraints. I'm not worried about trying to combine them; was just responding to an earlier point.

madeleinesnyder commented 6 years ago

One last bug to fix-- the dismiss-t1 pipeline option is generating the bold_hmc, bold_reference, func derivatives and func reports, but it isn't putting an actual preprocessed image under fmriprep/sub-X/func/; which script is responsible for generating the actual preprocessed functional?

On Thu, Oct 12, 2017 at 6:52 PM, Chris Markiewicz notifications@github.com wrote:

Certainly if we believe the EPInorm paper, and can figure out the "right" constraints. I'm not worried about trying to combine them; was just responding to an earlier point.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336328223, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLTIsxgi0rPjjzPxdEGnB-p3y4M-Hks5srsJIgaJpZM4P15YA .

effigies commented 6 years ago

The preprocessed functionals are created by bold_reg_wf (registered to T1) and bold_mni_trans_wf (registered to MNI). We don't currently output anything in native BOLD space, and MNI registration right now requires T1.

So it sounds like you've gotten where you can without adding new features. I'd suggest opening a PR and we can see how things look and discuss how to get the outputs you need.

madeleinesnyder commented 6 years ago

Ok, I just created a new repo ( https://github.com/StanfordCosyne/fmriprep_snyder.git) to compare with yours. The issue is my code contains a file under cli called BIDSgenerator.py, which takes the format our data is in and turns it into BIDS format. It doesn't significantly interact with the pipeline internals at all though, there are just a few steps added to the beginning of run.py checking that everything BIDSgenerator was supposed to do is done.

On Mon, Oct 16, 2017 at 11:02 AM, Chris Markiewicz <notifications@github.com

wrote:

The preprocessed functionals are created by bold_reg_wf (registered to T1) and bold_mni_trans_wf (registered to MNI). We don't currently output anything in native BOLD space, and MNI registration right now requires T1.

So it sounds like you've gotten where you can without adding new features. I'd suggest opening a PR and we can see how things look and discuss how to get the outputs you need.

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

effigies commented 6 years ago

Hi Maddie; would it be possible for you to fork our repository and copy your relevant changes onto that fork? The advantage to forking is that it makes comparing and ultimately integrating new code much simpler, as the history embedded in git can help distinguish changes made on your end versus changes that we've made since you last checked out our code.

I'll try to walk you through this process, though I may make some wrong assumptions about how things look on your computer. From a quick-ish glance, it looks like you last checked out our code at 1.0.0-rc5. I'm going to assume you have two folders in the same base directory $BASE:

And I'll assume you're working in fmriprep/, given that's the one that shares history with this repository.

First we need to create an "upstream" remote, which will make sure you have all of the release tags, and help sync with our repository, when needed.

git remote add upstream https://github.com/poldracklab/fmriprep.git
git fetch upstream

You can now checkout the release tagged 1.0.0-rc5 into a new branch called dismiss_t1, and copy the relevant files in:

git checkout -b dismiss_t1 1.0.0-rc5
cp $BASE/fmriprep_snyder/fmriprep/workflows/bold.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/workflows/base.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/cli/run.py fmriprep/cli/

Here, I assumed that workflows/bold.py, workflows.base.py and cli/run.py are the only ones relevant to your PR. If there are others, copy those as well.

Now, if you use git add -p, you'll be able to look at each change that was made, and decide whether it's relevant. This will help you avoid changes related to BIDSgenerator and other lab-specific changes.

Once you've settled on the changes you'd like us to review, you can commit and push your working branch, e.g.:

git commit -m 'ENH: Add --dismiss-t1w option to skip anatomical processing'
git push -u origin dismiss_t1w

Then, if you browse to https://github.com/poldracklab/fmriprep/, then you'll see something like this:

new_pr

You can then open a new pull request by clicking the "Compare & pull request" button. This will make it much easier for us to give you feedback.

Please let me know if this works for you, and feel free to ask any questions if anything is unclear.

(P.S. I've tried to give fairly specific advice here, which can sometimes leave the "why" context a bit unclear. You may find some more general guidelines useful for getting the hang of the Github workflow.)

madeleinesnyder commented 6 years ago

ALright I did this but it created a branch on the StanfordCosyne github. https://github.com/StanfordCosyne/fmriprep

On Mon, Oct 16, 2017 at 12:56 PM, Chris Markiewicz <notifications@github.com

wrote:

Hi Maddie; would it be possible for you to fork our repository and copy your relevant changes onto that fork? The advantage to forking is that it makes comparing and ultimately integrating new code much simpler, as the history embedded in git can help distinguish changes made on your end versus changes that we've made since you last checked out our code.

I'll try to walk you through this process, though I may make some wrong assumptions about how things look on your computer. From a quick-ish glance, it looks like you last checked out our code at 1.0.0-rc5. I'm going to assume you have two folders in the same base directory $BASE:

And I'll assume you're working in fmriprep/, given that's the one that shares history with this repository.

First we need to create an "upstream" remote, which will make sure you have all of the release tags, and help sync with our repository, when needed.

git remote add upstream https://github.com/poldracklab/fmriprep.git git fetch upstream

You can now checkout the release tagged 1.0.0-rc5 into a new branch called dismiss_t1, and copy the relevant files in:

git checkout -b dismiss_t1 1.0.0-rc5 cp $BASE/fmriprep_snyder/fmriprep/workflows/bold.py fmriprep/workflows/ cp $BASE/fmriprep_snyder/fmriprep/workflows/base.py fmriprep/workflows/ cp $BASE/fmriprep_snyder/fmriprep/cli/run.py fmriprep/cli/

Here, I assumed that workflows/bold.py, workflows.base.py and cli/run.py are the only ones relevant to your PR. If there are others, copy those as well.

Now, if you use git add -p, you'll be able to look at each change that was made, and decide whether it's relevant. This will help you avoid changes related to BIDSgenerator and other lab-specific changes.

Once you've settled on the changes you'd like us to review, you can commit and push your working branch, e.g.:

git commit -m 'ENH: Add --dismiss-t1w option to skip anatomical processing' git push -u origin dismiss_t1w

Then, if you browse to https://github.com/poldracklab/fmriprep/, then you'll see something like this:

[image: new_pr] https://user-images.githubusercontent.com/83442/31631889-2fa7f450-b289-11e7-9e4d-4eda5f592e15.png

You can then open a new pull request by clicking the "Compare & pull request" button. This will make it much easier for us to give you feedback.

Please let me know if this works for you, and feel free to ask any questions if anything is unclear.

(P.S. I've tried to give fairly specific advice here, which can sometimes leave the "why" context a bit unclear. You may find some more general guidelines https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution useful for getting the hang of the Github workflow.)

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

effigies commented 6 years ago

Oh, wow, I'm sorry. I didn't realize there was another repository of that name that isn't a fork of fmriprep. It looks like there's one in StanfordCosyne/fmriprep-1, but you also have one at https://github.com/madeleinesnyder/fmriprep. That might be the easiest one to use.

What I'm about to suggest is going to cross lines between repositories, which may not be the cleanest thing in the long run. It might be best to just clone a new folder:

mkdir tmp/
cd tmp/
git clone git@github.com:madeleinesnyder/fmriprep.git
cd fmriprep/

Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll call cosyne:

git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git
git fetch cosyne

Now you'll have access to your dismiss_t1w branch, so we'll just check it out and push it to your fork of fmriprep:

git checkout -t cosyne/dismiss_t1w
git push -u origin dismiss_t1w

If you used a temporary directory, you can now remove it:

cd ../../
rm -r tmp/

Now you should be able to make a pull request.

madeleinesnyder commented 6 years ago

cool, done.

On Mon, Oct 16, 2017 at 4:54 PM, Chris Markiewicz notifications@github.com wrote:

Oh, wow, I'm sorry. I didn't realize there was another repository of that name that isn't a fork of fmriprep. It looks like there's one in StanfordCosyne/fmriprep-1, but you also have one at https://github.com/ madeleinesnyder/fmriprep. That might be the easiest one to use.

What I'm about to suggest is going to cross lines between repositories, which may not be the cleanest thing in the long run. It might be best to just clone a new folder:

mkdir tmp/cd tmp/ git clone git@github.com:madeleinesnyder/fmriprep.gitcd fmriprep/

Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll call cosyne:

git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git git fetch cosyne

Now you'll have access to your dismiss_t1w branch, so we'll just check it out and push it to your fork of fmriprep:

git checkout -t cosyne/dismiss_t1w git push -u origin dismiss_t1w

If you used a temporary directory, you can now remove it:

cd ../../ rm -r tmp/

Now you should be able to make a pull request.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-337077020, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLQ0Z84f3gimwRyYqHqQ88nSZnf-9ks5ss-y9gaJpZM4P15YA .

madeleinesnyder commented 6 years ago

Quick question about the new script: I updated all the packages and stuff but it's still erroring out with:

from niworkflows.interfaces.base import SimpleInterface

even though there doesn't appear to be a base script in niworkflows. Am I missing something silly?

On Mon, Oct 16, 2017 at 6:02 PM, Madeleine Snyder < madeleine.snyder.48@gmail.com> wrote:

cool, done.

On Mon, Oct 16, 2017 at 4:54 PM, Chris Markiewicz < notifications@github.com> wrote:

Oh, wow, I'm sorry. I didn't realize there was another repository of that name that isn't a fork of fmriprep. It looks like there's one in StanfordCosyne/fmriprep-1, but you also have one at https://github.com/madeleinesnyder/fmriprep. That might be the easiest one to use.

What I'm about to suggest is going to cross lines between repositories, which may not be the cleanest thing in the long run. It might be best to just clone a new folder:

mkdir tmp/cd tmp/ git clone git@github.com:madeleinesnyder/fmriprep.gitcd fmriprep/

Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll call cosyne:

git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git git fetch cosyne

Now you'll have access to your dismiss_t1w branch, so we'll just check it out and push it to your fork of fmriprep:

git checkout -t cosyne/dismiss_t1w git push -u origin dismiss_t1w

If you used a temporary directory, you can now remove it:

cd ../../ rm -r tmp/

Now you should be able to make a pull request.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/755#issuecomment-337077020, or mute the thread https://github.com/notifications/unsubscribe-auth/AJctLQ0Z84f3gimwRyYqHqQ88nSZnf-9ks5ss-y9gaJpZM4P15YA .

atkinsonap commented 3 years ago

Hello, Do you know if and when it will be possible to run fmriprep without anatomical scans? I have a dataset for which there are only functional scans for 4 of the participants and both anatomical and functional scans for the remaining participants. Thanks, Anthony

oesteban commented 3 years ago

Hi Anthony,

This has been on our backlog for very very long. Although we are making progress toward making this possible, there's still a long way until fMRIPrep can run without anatomical data. Long story short, we haven't had the resources to push this forward.

I'm writing this issue in the discussion about the roadmap (https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6). We will be having a community roundup over Zoom next July 14.

If you want to be kept updated, please join our fmriprep-contributors team - https://github.com/orgs/nipreps/teams/fmriprep-contributors

atkinsonap commented 3 years ago

OK, thanks Oscar. I will wait for now and see what happens.

Thanks,

Anthony

On 3 Jun 2021, at 09:30, Oscar Esteban @.***> wrote:

[EXTERNAL EMAIL]

Hi Anthony,

This has been on our backlog for very very long. Although we are making progress toward making this possible, there's still a long way until fMRIPrep can run without anatomical data. Long story short, we haven't had the resources to push this forward.

I'm writing this issue in the discussion about the roadmap (https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6 https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6). We will be having a community roundup over Zoom next July 14 https://arewemeetingyet.com/Zurich/2021-07-14/17:00/NiPreps%2FfMRIPrep%20roundup.

If you want to be kept updated, please join our fmriprep-contributors team - https://github.com/orgs/nipreps/teams/fmriprep-contributors https://github.com/orgs/nipreps/teams/fmriprep-contributors — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nipreps/fmriprep/issues/755#issuecomment-853688910, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKIYPIA7H2HN34NYIUZHUB3TQ44SRANCNFSM4D6XSYAA.

deschsimon commented 2 years ago

Hi!

I'm also curious to hear if there has been any progress on implementing the featrure to run fmriprep without anatomical scan. Has this been implemented now? If not, is there a way to get confounds output only? Thanks! Simon

atkinsonap commented 2 years ago

Hello,

I’m also eagerly awaiting this functionality (if it can be implemented).

Kind regards,

Anthony

Dr Anthony Atkinson Department of Psychology Durham University Durham, UK https://www.durham.ac.uk/staff/a-p-atkinson/ https://atkinsonap.github.io/

From: deschsimon @.> Date: Monday, 7 February 2022 at 11:58 To: nipreps/fmriprep @.> Cc: ATKINSON, ANTHONY P. @.>, Comment @.> Subject: Re: [nipreps/fmriprep] Running only functionals (#755) [EXTERNAL EMAIL]

Hi!

I'm also curious to hear if there has been any progress on implementing the featrure to run fmriprep without anatomical scan. Has this been implemented now? If not, is there a way to get confounds output only? Thanks! Simon

— Reply to this email directly, view it on GitHubhttps://github.com/nipreps/fmriprep/issues/755#issuecomment-1031387363, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIYPIE6OOMSWPZECAFGPG3UZ6XVDANCNFSM4D6XSYAA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

effigies commented 2 years ago

We don't have any contributors with the bandwidth to take this on at the moment. We are, however, happy to help orient new contributors, if you would be interested in working on this feature.

FioritoAnna commented 10 months ago

Hi! Thanks for working on such an amazing pipeline! In my dataset fmriprep crashes for two participants. One doesn't have the anatomical scan, and the other's got a T1 scan, but there's a ton of movement (and I think that's what's causing the fmriprep crash?). Thus I am also interested in running fmriprep without the anatomical scan. Has this feature recently been implemented by any chance? Otherwise should I have to exclude this participants or is it a way to keep them? Thanks a lot, Anna

effigies commented 10 months ago

This has not been implemented. I think it will likely be simpler after the upcoming release (#3108), but I haven't thought this all the way through.

The main way to exclude participants is to run one per fMRIPrep instance, and just skip the subject you don't want. Alternately you can pass a big list of IDs to the --participant-label flag.