-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Post tICA Cleanup MIGP Failures #266
Comments
Do we know how the VN file ended up with 0s where the data isn't 0? |
Incomplete FOV coverage. |
If the FoV is missing something in the BOLD scan, wouldn't that result in 0 values in that location (possibly dilated into at some point, but that wouldn't have 0 variance)? How does it end up with nonzero data with 0 in the VN file? |
I don't know if it is zero variance, it is just low and it was causing problems by inflating values. |
Basically, that max is intended to only prevent zero divided by zero. If the VN doesn't match the data, there is probably a better solution, and it would be good to know why they don't seem to match. |
Very small values are also pathologic. |
wb_command and applywarp should both output 0 when asked to sample outside the FoV, so the output of OneStepResample should not have small values because of that. Do you know what step is changing them to be small values rather than zeros? The proposed edit basically is asking tICA to deal with not-quite-sane input data. I'd rather check why we are generating such conditions in the first place. |
I think the issue is related to regressing out dilated signal producing near zero signal. We did not encounter it prior to tICA cleanup, so it is probably that. |
So, to clarify, you are running MIGP on data that has already been through tICA cleaning? |
Right, but I still use the MIGP module for that. This is an expected thing to do (MIGP is a general tool for making group average fMRI data). |
So, tICA is finding the dilated region (single subject? semi-common problem area in the study?), calling it artifact/nuisance, and effectively reverting it to the undilated data, but with rounding error. This implies that the tICA output has near-zeros in some subjects in areas we specifically chose to dilate into, which is something we should consider how we really want to deal with for data we release. |
We don't need to make this more complicated that it needs to be. I have already fixed the problem that I discovered. |
For this one purpose we could hide the problem behind the zero-variance handling, sure, but that doesn't change the fact that the tICA cleaned output currently produces values that are neither 0 nor dilated in FoV issue locations, and therefore the tICA data will do strange things for anyone who tries to variance normalize it, while the MR FIX data won't. |
I'm not sure there is a general solution. |
The general solution is to compute an explicit mask of where we had to dilate zeros out of the data, and keep that alongside the timeseries. A less certain possibility would be to see if reclassifying dilation-related tICA components would keep the dilated data. |
These are not at this time workable; however. Changing the _vn bad values threshold is. |
Suggested fix added as d73c7d9 |
Another post-hoc strategy would be to detect per-run locations where the vn file has excessively small values, and use that to do another round of dilation after tICA. |
I have looked at some of the post-tICA cleanup MIGP results and the HCP-YA 7T rest and movie had some issues related to incomplete FOVs in some subjects leading to inflated values in the caudal medulla, which messed up the MIGP processing. It seems that changing the below line from 0.001 to 10 resolves the issue:
https://github.com/Washington-University/HCPpipelines/blob/0a8416e224d5c97ce0330f9a48f4453adedd5c4d/tICA/scripts/MIGP.m#LL58C80-L58C82
The typical VN file values are still substantially larger than 10.
Matt.
The text was updated successfully, but these errors were encountered: