Potential Issue in ICA-AROMA report

Hello,

I’ve been using ICA-AROMA to denoise my data, and am a little concerned about what I’m seeing in the reports. A quick background regarding my data: TR=420ms, voxel size=3x3x3mm, and multiband factor = 8. Given previous concerns regarding the use of ICA-AROMA on multiband data, I’m following @mmennes recommendation ([here](Testing different noise models output from fmriprep - unclear results with ICA-AROMA and here) of limiting the number of components (i.e. --aroma-melodic-dimensionality 100). Given my low TR, I’m also skipping slice time correction (as suggested by Smith et al., 2013). Below is a screenshot of part of the AROMA report for a subject’s run:

Components 33 and 40 seem to have some “stripping” (there are other components that have this “stripping” going on as well, I just didn’t get all of them in the screenshot), and I worry that this is due to me not performing slice time correction on data. Is this a valid concern, or am I misunderstanding things? I’m still trying to wrap my head around interpreting these reports, so I could be wrong.

Thanks for the help.

Dan

Hi Dan,

As you can see, the “stripping” pattern does not occur every other slice or following the slice timing scheme of your choice. Those rather follow the MultiBand pattern of multiplexing and you indeed are seeing something that resembles one band being acquired.

Since AROMA was not trained on MB data, it is logical that some of these artifactual components are classified as signal.

That said, I think @jaetzel or @rastko (just to mention the first two people that ran into my mind) may have more authoritative opinions on this matter.

Those stripes do look very much like they’re multiband related; the spacing even looks about right for an MB8 (!) acquisition. It’s not ICA, but you can see some MB-caused striping in https://mvpa.blogspot.com/2017/09/voxelwise-standard-deviation-at.html and slide 29 of http://www.benjaminrisk.com/uploads/4/5/7/3/45739059/brisk_multiband.pdf (from the talk at https://www.pathlms.com/ohbm/courses/5158/sections/7810; Benjamin Zahneisen’s may also be very useful if you’re somewhat new to multiband/SMS acquisitions).

I doubt slice timing would help at all, especially given your very fast TR; slice timing is often omitted with multiband.

1 Like

Thanks @oesteban @jaetzel for your comments (and the links). Even though C40 appears to have been mislabeled as signal instead of noise, I’ve looked over other reports, and most (but not all), components with this stripping pattern do get classified as noise, which I assume is what we want. As long as this is primarily the case, would I be correct in assuming that ICA-AROMA is generally fine with handling mutliband artifacts? I realize mutiband acquisition comes with a host of tradeoffs, but I’ve mainly been concerned with how it potentially affects ICA denoising. I’ve seen others prefer FSL’s more stringent FIX strategy; however, I’ve been hesitant to look into it (thus far), due to the time required to classify the components by hand for the training set.

Huh, interesting. I’ve seen similar-appearing patterns in the ICA-AROMA reports for some of my data, but I am performing slice timing, my TR is much long (2s), and I don’t have multiband data.

Components 1 and 3 below are particularly obvious examples:

Any ideas what this might be? ICA-AROMA does seem to classify them correctly as noise in my case.

You can see how your banding (C1, C3) is really matching alternative slices (and actually, C1 and C3 look like interleaved). So I’d say they might be related to slice-timing. The fact that you ran slice-timing correction does not imply that you remove all the variability coming from it (think of subject motion, some variability stubbornly progresses through the most sophisticated pipelines).

The loading over time plot seems to depict some kind of scanner drift which would be quite logical and probably interacts with the slice-timing correction. Other factors (such as the non-uniformity of the HRF across the brain) may also result in non-uniformity of the slice-timing correction.

1 Like

Ohh, that’s fascinating and very informative. Yes, the data were acquired interleaved so that makes sense. Thanks so much @oesteban for your explanation. The more I use ICA (via ICA-AROMA in fmriprep or GIFT or other tools), the more I learn about what actually makes up “fMRI data”.