-
Notifications
You must be signed in to change notification settings - Fork 24
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
Unexplained flip of the PE direction under some unknown circumstances #218
Comments
I vaguely recall FSL making strong assumptions about an image being left or right handed in some context. Could be related? |
The flip is A/P so I'm afraid this is genuinely an SDCFlows problem. It also occurs that correction is correctly performed on the reference (i.e., a combination of EPI scans that were fed into topup) but then incorrectly applied on the target bold. Registration of the bold target and the EPI reference seems okay (no gross error there), and I've checked the implementation a few times not. |
Is it possible that we have, e.g., an LPS file that we're reorienting to RAS without flipping the |
It is very possible, probably top 1 suspect. The alternative is also true: we have an LPS file and we are flipping two times. |
Well, ds003130 has A/P and P/A bold series, sbrefs and EPI fieldmaps. Everything's in LAS. Should be a good test dataset. |
After much thought, I have come to the conclusion that the VOX2RAS affine must be applied in all cases, regardless of whether the dataset is oblique or not. After all, the VSM (voxel-shift-map) is no more than a regularly gridded field of voxel coordinates. The transformation between voxels and mm is biyective and univocal, and formalized by the affine matrix of the image. This PR simplifies the calculation, and theoretically should resolve most of the issues we are experiencing when resampling data. Resolves: #218. Resolves: #236. Related: nipreps/fmriprep#2210.
After much thought, I have come to the conclusion that the VOX2RAS affine must be applied in all cases, regardless of whether the dataset is oblique or not. After all, the VSM (voxel-shift-map) is no more than a regularly gridded field of voxel coordinates. The transformation between voxels and mm is biyective and univocal, and formalized by the affine matrix of the image. This PR simplifies the calculation, and theoretically should resolve most of the issues we are experiencing when resampling data. Resolves: #218. Resolves: #236. Related: nipreps/fmriprep#2210.
After much thought, I have come to the conclusion that the VOX2RAS affine must be applied in all cases, regardless of whether the dataset is oblique or not. After all, the VSM (voxel-shift-map) is no more than a regularly gridded field of voxel coordinates. The transformation between voxels and mm is biyective and univocal, and formalized by the affine matrix of the image. This PR simplifies the calculation, and theoretically should resolve most of the issues we are experiencing when resampling data. Resolves: #218. Resolves: #236. Related: nipreps/fmriprep#2210.
@mgxd - after processing your data with the new version, I found that the problem persists. Then, I visually checked the distortion of the two EPI blips under
In other words, either the functional or both fieldmaps have reversed PE settings - by the looks of the distortion I'd say the functional is wrong. Flipping the setting for the functional resolved the issue. Affines don't show any axes flip or reordering that could affect the interpretation of the metadata by SDCFlows (although, the inconsistency above is independent of SDCFlows' interpretations):
I think we can keep this closed - please let us know if you make in further investigation on this particular problem. |
I stand corrected - editing the metadata |
@oesteban looking through fMRIPrep's 21.0.0 Dockerfile, I noticed we are not using topup from FSL6 - could that partially explain this? |
I doubt it because the field map looks okay. Also, I'm running locally with FSL 6, I believe. |
Probably more an artifact of failing to account for rotation of splines |
Using @mgxd's dataset in the debugging of the fMRIPrep + SDCFlows integration, we seem to have hit a difficult bug for which I haven't found the failure point (and hence the fix).
In order to permit progress on nipreps/fmriprep#2392, I'm separating this problem that seems to do with some idiosyncratic parameter (likely related to orientation headers) that makes the problem apparent.
The text was updated successfully, but these errors were encountered: