Skip to content
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

Open
glasserm opened this issue May 21, 2023 · 18 comments
Open

Post tICA Cleanup MIGP Failures #266

glasserm opened this issue May 21, 2023 · 18 comments
Assignees

Comments

@glasserm
Copy link
Contributor

glasserm commented May 21, 2023

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.

@coalsont
Copy link
Member

Do we know how the VN file ended up with 0s where the data isn't 0?

@glasserm
Copy link
Contributor Author

Incomplete FOV coverage.

@coalsont
Copy link
Member

coalsont commented May 22, 2023

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?

@glasserm
Copy link
Contributor Author

I don't know if it is zero variance, it is just low and it was causing problems by inflating values.

@coalsont
Copy link
Member

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.

@glasserm
Copy link
Contributor Author

Very small values are also pathologic.

@coalsont
Copy link
Member

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.

@glasserm
Copy link
Contributor Author

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.

@coalsont
Copy link
Member

So, to clarify, you are running MIGP on data that has already been through tICA cleaning?

@glasserm
Copy link
Contributor Author

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).

@coalsont
Copy link
Member

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.

@glasserm
Copy link
Contributor Author

We don't need to make this more complicated that it needs to be. I have already fixed the problem that I discovered.

@coalsont
Copy link
Member

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.

@glasserm
Copy link
Contributor Author

I'm not sure there is a general solution.

@coalsont
Copy link
Member

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.

@glasserm
Copy link
Contributor Author

These are not at this time workable; however. Changing the _vn bad values threshold is.

@coalsont
Copy link
Member

Suggested fix added as d73c7d9

@coalsont
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants