search

bbfrederick / rapidtide

rapidtide - a suite of programs for doing time lag correlation analysis on fMRI data
Apache License 2.0
75 stars 14 forks source link

Allow rapidtide's `--fixdelay` argument to accept an imaging file #171

Open tsalo opened 1 month ago

tsalo commented 1 month ago

Is your feature request related to a problem? Please describe. This might already be implemented in one of the other CLIs in rapidtide (and if so sorry about the spam), but would it make sense to accept a file in the same space/resolution as the input file for --fixdelay?

There are two use-cases I can foresee:

  1. If you have an external estimate of the delay times (e.g., an arterial transit time [ATT] map from an ASL scan) and want to run rapidtide with it. This is related to https://github.com/nipreps/fmripost-rapidtide/issues/18.
  2. If you have run rapidtide on multiple runs, then combined them to reduce noise in the individual delay maps, as we have discussed in https://github.com/nipreps/fmripost-rapidtide/pull/17. In that scenario, it seems like the other outputs estimated from the run-wise rapidtide runs (especially the sLFO regressor) should be recalculated using the new delay map.

Describe the solution you'd like I was thinking you could modify --fixdelay to accept either a float (current behavior) or a file, where the file would have to have the same dimensions as the input image.

It might also be nice to just use the external delay map as an initial estimate that rapidtide could refine across passes.

Describe alternatives you've considered I think the current plan in fMRIPost-rapidtide is to just run retroglm using the denoised delay map with the original run-wise rapidtide outputs, which seems reasonable but might be suboptimal?

Additional context None

bbfrederick commented 1 month ago

I like this idea, especially the idea of a "hint" map. These are two features really, and we'd have to figure out the best way to have them interact. Perhaps two flags --initialdelay, which could be a float or a map, and --nodelayfit, to not fit the delay in the voxel, just use the current delay value (either constant or voxelwise)? I think that would be most flexible. Not sure about the option names I gave though.

tsalo commented 1 month ago

I think that's a great idea. The --initialdelay option is what I was envisioning, but --nodelayfit makes a lot of sense too.