Censoring data within tedana

[handwerkerd]

Summary

I was just having a discussion with AFNI's @afni-rickr and @mrneont and a few others and the discussion of censoring within tedana came up.

Additional Detail

The context of our discussion involved datasets where a non-trivial number of volumes were censored due to head motion. If tedana processes the entire time series then it will get more ICA components and unnecessarily more rejected components, which hurts statistical degrees of freedom and other stuff.

From the practical side, it wouldn't be hard to run T2* map estimation, ICA, and component selection on data with censored volumes. The one issue is that the denoised time series might need to exclude censored volumes so we'd end up with time series with 0 or nan values. AFNI could easily deal with that, but I'm not sure about other programs.

Next Steps

• Decide if this is something work implementing

[tsalo]

Is there anything in tedana that would use the full data?

My first thought is that this would be a great feature, but should go in fmripost-tedana, along with the dummy volume removal.

[handwerkerd]

My assumption would be that censored volumes are calculated in AFNI or fMRIprep before tedana is run and then the list of volumes to censor would be an input to tedana.

[tsalo]

If running tedana with the censored volume mask and running it directly on the censored data would be equivalent, then I think we should put that step in a postprocessing workflow (i.e., fMRIPost-tedana). If tedana needs to use both the censored and uncensored versions of the run, then I think there's a strong argument to directly incorporate it into tedana.

[CesarCaballeroGaudes]

I would say that running tedana on censored data would not be equivalent to applying tedana and then censoring because censoring will block the artefacts that tedana aims to remove. Therefore, the components will be different very likely.

[afni-rickr]

Hi @handwerkerd,

Actually, this is more than just censoring. My intention (for many years now) was to clean up the data a bit before giving it to tedana, removing trends and motion parameters say, and to censor. The hopeful benefit is that the ICA components would not be focused on the bad time points, or even things like drift or other regressors that we would plan to regress later anyway.
On my side, the intention was to not even change tedana for this, if possible.

But perhaps projecting anything out would happen differently across the echoes, and therefore probably mess up tedana. And that might mean tedana would have to be the one to deal with such a thing.

To be clear, is the ICA step run on the OC data?

[handwerkerd]

@afni-rickr The ICA step is run on the OC data but is then fit to information across the echoes so we can't break the relationship between echoes. On removing other stuff, i decided that was a separate discussion so I opened #1054.

I think @CesarCaballeroGaudes and I are on the same page. Censoring would affect tedana in hopefully good ways. For example, large discrete spikes in time would need to be modeled with ICA components. If we know those time points are non-T2* noise and we already plan to censor them in later preprocessing steps, excluding them from ICA would mean that ICA would be better able to model other sources of variance.

[tsalo]

What about implementing something like Pham et al. (2023), which uses ICA and classifies components that exhibit burst noise? That would basically integrate "censoring" (flagging high-motion volumes) and ICA-based denoising into a single step.

EDIT: In that paper they also use FusedPCA. Might be a good PCA alternative if we want the PCA step to flag motion-related spikes?