Closed tsalo closed 1 week 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.
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?
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.
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.
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.
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.
--brainmask MASK[:VALSPEC]--graymattermask MASK[:VALSPEC]--whitemattermask MASK[:VALSPEC]--datatstep TSTEP--datafreq FREQ--padseconds SECONDSJust use the max (number of volumes minus 1)--zeropadding PADVALUse the max (number of volumes minus 1)?--motionfile MOTFILE--motderiv--slicetimes FILEReplace with--ignore slicetiming
--savelags--saveintermediatemaps--version--detailedversion--nprocs NPROCS--reservecpu--mklthreads MKLTHREADS--nonumba--noprogressbar--cifti--simulate--displayplots--nosharedmem--memprofile--infotag tagkey tagvalue--tincludemask FILE--texcludemask FILE--debug--focaldebug--verbose--disabledockermemfix--alwaysmultiproc--isatest