Hi, I’m working through the steps of BOLD preprocessing. I had the data processed through the HCP pipelines (structural, functional, ICA+FIX, MSMAll, temporal ICA), and used the preprocessed files to run the BOLD preprocessing. I generated the group reports using the following parameters for the “compute_bold_stats” command:
The group report showed that almost all BOLD runs had all frames flagged as outliers by the “dvars” metric, and none by the “dvarsme” metric. So if I am to use the “udvarsme” to flag bad frames, it will basically be dictated by the “mov” metric since all “dvarsme” are equal to zero. I attached here the group report showing this.
My questions are: what could be driving all frames being flagged as bad by dvars? Can it be that I processed the data using the temporal ICA pipeline? Any sensible suggestions on how to proceed with data scrubbing given this?
If you have processed BOLDs using both ICA+FIX and temporal ICA, then the data should be in principle cleaned and no additional movement scrubbing and nuisance regression should be needed. That is what one wants to achieve using ICAFIX and tICA, and Matt Glasser has some convincing data in that respect.
If you want to use scrubbing data or need to for data that does not have ICAFIX and tICA completed, my advice would be to always use dvarsme (and the related udvarsme) rather than dvars. The issue is with the threshold. For dvars one should adjust the threshold to match the characteristics of the data. The factors that may impact sensible dvars threshold are scanner characteristics, TR, resolution … If you would want to use dvars, the best would be to inspect the PDFs generated by create_stats_report and based on them estimate what a sensible dvars criterion might be. You can then set it as the mov_dvars parameter.
dvarsme was created specifically to handle the above dvars issue. dvarsme is dvars timeseries normalized to its median. If you use dvarsme=1.5, as is default, you are marking all the frames for which dvars is more than 1.5 the median across the timeseries. In our experience this works well across the datasets from different scanners. A possible problem could be with a participant for which most of the timeseries has movement and so the median would be overly high and bad frames would not be detected.
To get back to your question. Since you have completed ICA+FIX and tICA, you need not make use of motion scrubbing and you need not regress out V, WM, WB or m signals from the timeseries. It might be that some of the functions would still search for scrubbing data. To resolve that issue, run motion scrubbing, but set the criterion to quite high and use udvarsme. E.g., set mov_udvarsme:3 and then in the following steps just ignore any information on bad frames.
Looking at your report, it is clear that the data is quite clean. dvarsme does not identify any frames as bad. So in udvarsme the only frames identified as bad are those for which fd (or mov) criterion is reached. In this case you can just define dvarsme as the relevant criterion by setting: mov_bad : dvarsme, mov_post: dvarsme, mov_fidl: dvarsme and not regress nuisance regressors from your data.
It seems that you are not using the latest version of the container. Would you mind trying your call with the latest version. There are two possibilities in play. (i) There might have been a bug introduced in on one of the versions that got manifested in some specific cases, and was resolved in the latest updates. (ii) There might be another previously unidentified issue, as I don’t remember testing fc_preprocess w/o using nuisance regression. It might be that a part of the code expects nuisance signal even if it is not needed in later steps.
I would appreciate if you could try with the latest version and I’ll test and resolve any possible additional issues for your use case. It might take about a week, though.
I’m using the qunex container version 0.97.3. I was under the impression that this is the latest version available, at least when I check the GitLab page: Sign in · GitLab
Is there another version that I can download and try?
The latest QuNex version is 0.98.0. The specific line that errors out for you was first introduced in commit 0a720b31fcb565816d9ab22ccd2324a47f26611e, QuNex version 0.97.0, it was still present in QuNex 0.97.3 and is not present (or is rather in a different line) since a15c386eedc24282857ac4e2c9eb905b0abdb0e2. It seems that the latest version was not yet build into a container. I have asked @demsarjure about the planned release date and will let you know.
In the meantime I’ll check if no nuisance signal might be an issue when filtering is performed in the latest version of the code.
Yes, 0.97.3 is the latest released version. 0.98.0 has not been released yet, it is the internal development version that is staged for end of May release (both as source and as a container).
I have identified and resolved the issue. When fc_preprocess was used to process the data w/o regression, it still expected some of the data to be present. This is now fixed and tested. fc_preprocess and fc_preprocess_conc still require that movement and motion scrubbing data is present, which in some cases might not be needed. In the future we will make the functions more flexible so that it will be possible to use them even w/o these data. This will take a while, but the fix that is already implemented and tested should address your needs. It will be part of the next release that Jure mentioned.