RestingStateStats in the context of multi-run-fix #61
Comments
|
The development version of RestingStateStats supports multi-run-fix. It produces a single output perconcatinated run. |
|
Can you send me a copy? Not having the RSS equivalents per individual run is going to be unfortunate, but off the top of my head, I'm not sure if there is a meaningful way to apply the "variance partitioning" inherent to RSS to the individual runs in the context of multi-run FIX. |
|
Well that is not hard, just compute the single run variances off of the multi-run cleanup stages. I'm less certain that it matters to not have single run variances though... |
|
Not having them available for the individual runs is inevitably going to lead to "missing data" situations, given that individuals runs are a basic "unit" of data. e.g., If you wanted to use RSS to provide some QC measures for an analysis that is specific to a given task, that won't be possible. |
|
Like I said one can compute single run versions if one saves out the intermediate timeseries. Which measures are you most worried about? |
|
tSNR/CNR would be a natural one to want available per run. There may be others (haven't thought about it too deeply). |
…s filtered only intermediates *Delete single run high-pass only files from multi-run fix and reapply multi-run fix *Generate highpass volume timeseries if not already existing in ReApplyFixPipeline
@glasserm
What's your thinking for how best to apply RestingStateStats in the context of multi-run-fix? If we run RSS on individual runs, that won't really reflect the manner in which the multi-run data was cleaned.
The text was updated successfully, but these errors were encountered: