nipreps / fmripost-aroma Goto Github PK

Rather than wrapping ICA-AROMA, it may be more maintainable long-term to wrap the components it wraps and construct the workflow ourselves.

This does not necessarily need to be done in this project, but it could be a testing ground for upstreaming into an independent AROMA package.

What would you like to see added in this software?

This came up in today's NiPreps roundup call. I initially assumed that the fMRIPost workflow would use standard-space derivatives from fMRIPrep. However, what would be better would be for the fMRIPost Apps to have workflows that apply transforms from the minimal fMRIPrep outputs.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

What would you like to see added in fMRIPrep?

html report naming:
For my use case, I need to run fmriprep on two sessions separately. i'd like to be able to merge the outputs into the same derivatives directory afterwards. however, since the html reports in the new layout (eg. in v22) are above the ses-* directory, i would need to rename the html reports in order to not have two files named the same in the same location. it would be great if the html report naming could include ses-* in addition to sub-*.

ICA aroma regressor naming:
I noticed that the naming of ICA aroma regressors in *_desc-confounds_timeseries.json and *_desc-confounds_timeseries.tsv is inconsistent. Naming the two regressors the same would make workflows just a little smoother. For example, the first motion regressor in the json is called "aroma_motion_1" but in the tsv it's called " aroma_motion_01". i got this with v22.0.2.

Do you have any interest in helping implement the feature?

Yes, but I would need guidance

Additional information / screenshots

No response

The reporting for fmripost-aroma should be relatively straightforward. The workflows copied in #2 should include boilerplate text that can be included as well as produce figures for inclusion in reports.

We will also want to shift to nireports for compiling the reports, while we're here. nipreps/mriqc#1085 should be our model, though it will take some work to sift through that diff, since the reporting in MRIQC is pretty extensive. Our use should be much less so.

I have been having some issues with BrokenProcessPool errors (i.e., out-of-memory errors), and these usually occur around the melodic and susan commands. Would it be possible to add a mem_gb of a few gigabytes to both of these, so that the nipype scheduler knows not to start too many at the same time?

https://github.com/nipreps/fmriprep/blob/a45ea486a8aa58541add3370a60ae87a70af8efb/fmriprep/workflows/bold/confounds.py#L668-L673

Hi!

Would it be possible to run single subject ICA as an option in fmriprep?
We use this information to inspect our data and eventually train FIX. While I know AROMA is doing something similar, the ability to use FIX and have some flexibility in what is removed would be useful.

Thank you!
Amy

What would you like to see added in this software?

The report will be pretty short if the only figure in there is the MELODIC components image.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

Currently, fMRIPrep only supports one ICA-based denoising method (AROMA), in which components classified as noise are retained in the confounds tsv. However, there are also plans to support MEICA in fMRIPrep, which involves running ICA and classifying components as noise or signal (much like AROMA). To facilitate both AROMA and MEICA, along with any other ICA-based denoising algorithms one might want to apply, I propose that we output BEP012-compatible versions of the ICA outputs (i.e., the mixing matrix, component maps, and the "component table"/json). (EDIT) I realize the mixing matrix is already outputted, and I assume it's in BEP012 format, but the other elements are not.

This stems from nipreps/fmriprep#1010 (comment) and nipreps/fmriprep#1784 (comment). The general idea was accepted in those issues, but I'd like to discuss the exact settings that should be used, given that AROMA and tedana have slightly different standards for their ICAs.

Open issues:

1. Space
   • tedana assumes native space
   • AROMA assumes standard space
   • Either one could run ICA on another space, retain the component time series, and then estimate component maps in their own required space as needed (see ME-ICA/tedana#565).
2. Smoothing
   • tedana assumes unsmoothed data
   • AROMA assumes smoothed data
   • Again, as long as the component time series are valid, either approach can estimate component maps using whatever imaging data they want.
3. Storage of component metrics and classifications
   • tedana stores metrics and classifications in the decomposition json file. We could probably include a prefix in those fields to delineate metric/classification source (e.g., tedana vs. AROMA)
   • I don't think AROMA retains metrics in its current form, but hopefully a pure Python version would be able to do that.

Pinging tedana, AROMA, and BEP012 folks who might be able to weigh in:

• tedana: @CesarCaballeroGaudes, @handwerkerd, @emdupre
• AROMA: @jdkent, @rciric
• BEP012: @effigies

We are processing the GSP 1000 dataset, which does have dummy frames in the fMRI data, but we want to use the ICA-AROMA output. It would seem more logical to remove these frames up front before MELODIC is run. Informal comparison finds distinct differences in fcMaps between leaving them in vs truncating the file before fmriprep is run. What should be the appropriate sequence of steps here?

At minimum, I think we need:

• AFNI 3dTShift, for slice timing correction
• FSL SUSAN, to smooth BOLD data before running MELODIC
• FSL MELODIC, to perform the ICA

ICA-AROMA (https://github.com/maartenmennes/ICA-AROMA) uses the following FSL commands as well:

• bet
• fslmaths
• fslinfo
• zeropad
• fslroi
• fslmerge
• flirt
• applywarp
• fslstats
• fsl_regfilt

Of course, most, if not all, of the ICA-AROMA dependencies could be replaced with Python code. Not sure if a fork with that change already exists. I know that the ME-ICA team (myself included) worked hard to write a pure Python version, but progress on that stalled when we tried to extend ICA-AROMA to work on native-space BOLD data. Still, it might be worth resurrecting: https://github.com/ME-ICA/aroma.

Do we need any other non-Python dependencies?

As a relatively small workflow, this would be a good candidate to rewrite from Nipype 1 to Nipype 2 (Pydra).

The advantages of Pydra include more Pythonic syntax, improved parallelism and concurrency, and ongoing support (while Nipype 1 is in palliative maintenance mode).

ICA-AROMA was removed from fMRIPrep in nipreps/fmriprep#2966.

The first release of ICA-AROMA should simply copy the workflows in here. Future versions can refactor or reimplement portions of AROMA, if desired.

Should we use semver or calver? I created 1.0 and 2.0 milestones, but there's no need to stick with them. I'm a little inclined toward the nipreps-calver system, as it will clearly mark age of last significant updates.

I'm not sure if we want to support CIFTI outputs or not. If so, should fMRIPost-AROMA project the volumetric data to CIFTI or just denoise preprocessed CIFTI files?

What happened?

I think the "minimal" version needs the boldref-space brain mask: sub-01/func/sub-01_task-mixedgamblestask_run-[01|02]_desc-brain_mask.nii.gz, which the "full" version shouldn't have since func-space outputs weren't requested.

What command did you use?

n/a

What version of the software are you running?

n/a

How are you running this software?

Docker

Is your data BIDS valid?

Yes

Are you reusing any previously computed results?

No

Please copy and paste any relevant log output.

n/a

Additional information / screenshots

n/a

What would you like to see added in this software?

If we want to be able to chain nipost workflows, we'll need to include the ability to ingest common targets, depending on the workflow. In this case, I'm thinking specifically about chaining ICA-AROMA and ME-ICA. Typically, I think we'd run ME-ICA after ICA-AROMA, since AROMA requires specific ICA settings (e.g., SUSAN-based smoothing, ICA in MNI152NLin6Asym-2mm space), but I do want to support the opposite organization, which would mean (1) ingesting ICA derivatives and (2) checking that they match what ICA-AROMA expects (at minimum checking the space and resolution).

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

What would you like to see added in this software?

It might be good to let users filter the motion parameters using either a notch filter (for MB data) or a low-pass filter (for SB data) if they way.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

https://xcp-d.readthedocs.io/en/latest/workflows.html#motion-parameter-filtering-optional

What would you like to see added in this software?

In cases where users run fMRIPrep without setting MNI152NLin6Asym as an output space, fMRIPost-AROMA will not automatically find the chain of transforms it needs. Instead, we want users to be able to provide their own list of transforms to get the data to MNI152NLin6Asym.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

fmripost-aroma should be a BIDS app of the form:

fmripost-aroma <bids-dir> <out-dir> participant -d <fmriprep-dir> [OPTIONS]

The reason for taking the fmriprep directory as a separate derivative input is to permit the utility to retrieve some data from the raw dataset instead of relying entirely on the fmriprep derivatives. This will become necessary when fMRIPrep supports a minimal mode where only transforms are generated, so we might as well start the CLI where we expect it to end.

We should include the CLI arguments --melodic-dimensionality and --error-on-warnings, corresponding to the fMRIPrep arguments --aroma-melodic-dimensionality and --error-on-aroma-warnings.