Exclude lesioned areas from confound masks.

[danlurie]

Segmentation algorithms are often confused by lesioned areas, resulting in incorrect automated segmentation results in these regions. As such, it is good practice is to subtract the lesion mask from these tissue masks before calculating confound time series (e.g. mean WM/CSF signals, CompCor), which rely on tissue masks.

When FMRIPREP detects a lesion mask and uses it during spatial normalization, it should also consider this mask when calculating confounds.

[I'm happy to implement this at some point. I'm mostly adding this ticket as a reminder to myself and so that others are aware of this issue.]

[oesteban]

This might be of interest to @rciric. Thanks!!

[danlurie]

Speaking of @rciric: For now, I am working on a hack that re-runs the aCompCor node (outside of fmriprep) with a modified mask and then pumps the corrected regressors into xcpEngine. Will post a note here to the code when it's ready.

[mitchellxh]

Hi, I am also very interested in this - so thank you for working on it! Quick question - is the lesion mask used in registration of EPI to T1w? I'm not sure what the best method is to improve this step...

[effigies]

Hi @mitchellxh, it is not. I suspect that in general, the boundary-based registration will perform poorly with lesioned data, so the rigid coregistration will be used.

[mitchellxh]

Thanks @effigies. That's last part of the puzzle for my data.

Also, I've had success using enantiomorphic normalization to getting normalized T1w images and allowing for Freesurfer to run. Is this functionality too niche in potentially including as an option in the pipeline? Thanks!

[effigies]

It doesn't strike me as overly niche, but I don't know this space very well. Is the community working with lesion data converging around a few core algorithms at this point, or is it still largely exploratory? The reason I ask is that it will affect our approach to inclusion.

If this is one of the "standard" algorithms for lesioned data, then it makes sense to add it, and use it opportunistically when a lesioned brain is detected. sMRIPrep is where our structural pipelines now live, so if this is the route we go down, that's where you should open an issue and we can start orienting you to the code and work out how best to incorporate this improvement.

If there's still a lot of controversy over the best way to do things, then it may make sense to go with more of a plugin architecture, which @oesteban, @satra and I have been talking about a bit. The idea there is to allow users to utilize the core of fMRIPrep, while keeping modifications in a public repository that can also be audited. This should help us turn fMRIPrep from a tool for users who want bog-standard fMRI preprocessing to one that can enable development of new methods or analysis of new imaging types. We don't really have a process or template for fMRIPrep plugins yet, but if that's what you're interested in, we can figure it out as we go.

[satra]

@effigies - i meant to say that this would be a simple add on case. in terms of the lesion world, nothing is set in stone, but there are algorithms and manual steps that people create to identify these things. perhaps this can also help add that kind of information to derivatives, and the plugin will instruct fmriprep to use those pieces. seems like a use-case to develop/architect a plugin architecture.

[danlurie]

@satra @effigies Agree that the enantiomorphic registration sounds like a good use case for a plugin.

The cost-function masking was already built-in to ANTs, so enabling it in fmriprep was simply a matter of adding a new input (the lesion mask) and tweaking a few things in the existing registration workflow.

My understanding of enantiomorphic registration is that it involves replacing lesioned voxels with homotopic voxels from the undamaged hemisphere, and so adding this to fmriprep would likely require building that new functionality.

[mitchellxh]

Thanks, and yes - there is not a converged method in terms of lesioned fmri preprocessing. That said, I have had good results doing a combination of this enantiomorphic registration for T1w correction and applying a T2w intermediate between the EPI and T1w image (lesions will have same contrast as EPI, yet same spatial-resolution as T1w). Much of the method is described by the Yourganov/Rorden paper here.

Having a plugin for this would be great! There is an existing SPM toolbox (developed by the authors) that I've used that requests at minimum the T1w image and lesion-map in T1w space. However, it will also accept and transform a T2w lesion-map and T2w image (which is what we tend to use for lesion mapping), helping automate getting the lesion-map in T1w-space.

Let me know how I can help facilitate creating such a plugin. Thanks again!

[satra]

here is a general plan for plugins, with the current assumption that plugins are sequential:

inside fmriprep

# first create the fmriprep wf based on cmdline specs
wf = ...
for plugin in plugins:
    plugin_func = load_plugin(plugin, fmriprep_version)
    wf = plugin_func(wf)

wf.run(...)

for a plugin:

1. create a function that takes a versioned fmriprep workflow as input and returns a modified workflow
2. for the plugin creator, this will tantamount to changing nipype workflow using disconnect and connect methods, and in some settings modifying the data grabbing nodes.

[oesteban]

versioned fmriprep workflow

How do you think we should do this?

[satra]

versioned fmriprep workflow How do you think we should do this?

since this is inside fmriprep, perhaps simply using version from inside the library. it will be upto plugin creators to support future versions.

[oesteban]

But the plugin needs to identify the workflow being passed in. E.g., whether you are running with or without FreeSurfer.

[satra]

yes the plugin would need to understand where it will make the change. so potentially the options to fmriprep could be passed along to the plugin.

to help the developer, we can develop additional surgery tools in nipype, such as find sub workflow by name.

this will get easier with pydra, but the initial patterns will have to depend on nipype 1.x

[oesteban]

Could we perhaps generate a checksum of the workflow? Some mechanism to allow us to decide whether we are using the right workflow and version?

[satra]

Could we perhaps generate a checksum of the workflow?

this exists in pydra. we could backport the concept, but a workflow checksum also depends on inputs. so the checksum will change depending on the inputs. i think as a start it would be more tractable to let the developer:

1. figure out what graph shape to expect given fmriprep version and inputs to fmriprep
2. perform a specific surgery
3. verify some things and return the altered graph

[oesteban]

but a workflow checksum also depends on inputs.

I think splitting these two checksums would be useful (or maybe have a just-workflow checksum and a data+workflow checksum). WDYT?

[satra]

how would you handle checksums of conditional workflow surgeries inside niworkflows? don't they depend on the inputs?

[danlurie]

I'm back to working on lesion data after a bit of a break and figured I'd update this thread. I actually ended up creating a NiPype workflow that piggybacks on an existing FMIRPEP working directory to re-run aCompCor and generate regressors after subtracting lesioned voxels. The vast majority of the workflow is just nodes copied from FMRIPREP with an extra customsubtract_roi node dropped in between the acc_tfm_lf node and the acompcor_lf node. In this sense, it sounds a lot like the plugin architecture that @satra described.

I haven't tested it with any version of FMRIPREP other than the one I developed it with (1.3.2), so it would likely need to be updated to work with the current version. It's designed to be run from within the FMRIPREP singularity container.

It would be nice to get this properly integrated into FMRIPREP (as it builds directly on the work we did to implement constrained cost function masking), but I don't have the bandwidth to tackle that right now myself.

[mitchellxh]

I realize this is a very out-of-date question but just wanted to loop back and ask about some of the existing denoising methods in place for when a lesion-mask is detected for clarity sake.

Is the lesion-mask currently transformed to our requested standardized space? If so, where might they be saved? And is it in-fact subtracted from the workflow that calculates csf, wm, and aCompcor confounding time series as described here?

And if we were to add the --use-aroma flag, is the lesion mask subtracted before melodic is run? I ask because I'm interested in running melodic on the normalized bold without the lesion subtracted, so that I can manually denoise components that overlap with the lesion-mask.