Apply smoothing before running rapidtide

[tsalo]

What would you like to see added in fMRIPost-Rapidtide?

Rapidtide has a parameter (gaussigma) that controls smoothing within the workflow, but I think we can run the smoothing step beforehand.

Do you have any interest in helping implement the feature?

Yes

Additional information / screenshots

No response

[bbfrederick]

I'm not sure what the advantage of doing this is, and it would change functionality, unless I'm misunderstanding how you plan to implement it.

The spatial smoothing is to improve delay fitting and sLFO regressor extraction. The underlying assumption is that the true delay structure is fairly smooth, so this is ok. These delay maps are used to generate the voxel specific regressors, but the original, completely unfiltered data (no spatial or temporal filtering) is read in prior to noise regression - the voxel specific sLFOs are regressed out of THAT, not the data that we've been using to find the delays. So the rapidtide filtered data is not spatially filtered.

Instead of using the raw data that was used to find the sLFO, you can read in a different file, and regress the noise out of that using --glmsourcefile. This option was put in so that you could find your sLFO regressors using minimally preprocessed HCP data, but regress the noise out of FIX processed data (applying FIX makes a hash of the sLFO in such a way that it really messes up rapidtide's ability to extract the sLFO from the data).

You could apply a spatial filter to the preprocessed data, and save that as a separate file, run rapidtide on that, and then use --glmsourcefile to specify the original, unfiltered preprocessed data, but I'm not sure what that buys you.

[tsalo]

Ohh okay. I thought the smoothing happened early enough in the rapidtide workflow that the unsmoothed data wasn't used for anything later on. I must have misread the code.

I was thinking we could allow different kinds of smoothing if we had it outside of the rapidtide call, such as CIFTI smoothing (once we support CIFTI inputs in the fMRIPost workflow) or smoothing that accounts for tissue boundaries like FSL SUSAN. Plus using a C package (e.g., AFNI) for smoothing would definitely be faster and less memory-intensive than relying on Python smoothing code.

Basically, I see the value of having many steps implemented in Python within rapidtide, but if there's anything that gets done at the beginning of the rapidtide workflow that I can outsource to a more efficient tool (e.g., C-based tools, like AFNI) or one which might allow more flexibility (e.g., SUSAN), I'd like to do that. It doesn't seem like that's possible with smoothing though.

[bbfrederick]

I see what you're saying. I'm ok with doing it that way as long as we keep track of what we should be using - we can do it all with external programs and using existing options. If we end up at the same place, but faster, I'm all for it. And I really DON'T want to implement CIFTI surface smoothing in rapidtide...