nipreps / fmripost-rapidtide

A BIDS App for running rapidtide on a preprocessed fMRI dataset.
https://fmripost-rapidtide.readthedocs.io
Apache License 2.0
1 stars 0 forks source link

Drop unnecessary parameters #7

Closed tsalo closed 1 week ago

tsalo commented 2 weeks ago

I'm trying to figure out which rapidtide parameters we can drop. @bbfrederick are there any that jump out to you?

As an fMRIPost workflow, it'll load input files automatically, so I think we can drop many of the parameters. Also, on a side note, it looks like there are 149 parameters, which is a lot for a CLI.

I'm going to check off ones I think we can drop.

bbfrederick commented 2 weeks ago

Yes, most of the options are there for tuning weird types of experiments, or came from when I was designing the program - I've since picked default values that are generally pretty good. Also, most of the tuning is only necessary when you want to do delay mapping in pathology - for straight up denoising, you don't need to and don't want to mess with most of the defaults. It might be easier for me to specify which options to expose, rather than which to hide.

Github seems to let me check and uncheck boxes in your list, but I don't know if they stick or not. I'll leave this comment, come back, and see if they have stuck.

bbfrederick commented 2 weeks ago

Ok, well it looks like they stick. So for straight up denoising, this is the maximum number of things you'd support (honestly, at least half of them can probably be locked down as well). But then there's a philosophical question - what is fmripost-rapidtide FOR? If it's to do denoising, which I'd argue is a necessary step if you are going to do any sort of resting state analysis, then these options are good. If we also want to allow people to do delay calculations and other more interesting hemodynamic measures, we might want to enable more options. But if people do that, I think probably they should do the whole rapidtide installation and just use it directly. Thoughts?

tsalo commented 2 weeks ago

Given rapidtide's flexibility, I imagine that fMRIPost-rapidtide's scope may change over time as users make requests, but I personally see it as a tool for both denoising and generating regressors for denoising. The main outputs for me will be the HTML report and the voxel-wise (unfitted) confounds file, which I will then pass on to other tools. The delay map would also be amazing to get.

The key, for me, is that I am trying to build an ecosystem of self-contained post-processing BIDS Apps. I see people chaining them together as necessary, rather than having a one stop shop workflow for denoising.

Theoretically, one project workflow I can imagine would be to do (1) fMRIPrep for preprocessing, (2) fMRIPost-tedana for multi-echo denoising, (3) fMRIPost-rapidtide for dGSR, and (4) XCP-D to take the preprocessed data from fMRIPrep, the ICA confounds from fMRIPost-tedana, and the voxel-wise dGSR confounds from fMRIPost-rapidtide, and then denoise the data using a combination of those confounds. I'm not going to make XCP-D (which I maintain) a necessary endpoint, but it's one option of many.

tsalo commented 2 weeks ago

Just to be clear, that is not a top-down mission statement for this tool. It is just how I personally envision it. I'm definitely open to modifying the plan.

tsalo commented 2 weeks ago

The current list of 33 parameters seems much more manageable. I think we can still drop --confoundfile, --territorymap, and --glmsourcefile though. I'm hopeful that we can identify and load those internally.