-
Notifications
You must be signed in to change notification settings - Fork 16
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
Mapping of displacement fields #185
Comments
Yes, I think this is correct. I wonder if a more direct approach would be: return np.vstack(tuple(
- map_coordinates(
- self._field[..., i],
+ ijk.T + map_coordinates(
+ self._deltas[..., i],
ijk.T,
order=3,
mode="constant",
cval=0,
prefilter=True,
) for i in range(self.reference.ndim)
)).T By interpolating the deltas, we avoid needing a second step. We could also separate displacement fields from deformation fields, and treat displacement fields as I do and deformation fields as you do, which would prevent adding unnecessary floating point error to the mix. |
The rationale to adopt deformation fields (instead of displacements fields or "deltas") is float resolution. Deformation fields (SPM's preferred option) are more accurate than displacements fields (ANTs, FSL). BTW - @jbanusco has fixed this issue (and tested himself) here - master...jbanusco:nitransforms:master I'm in the process of getting him to submit those improvements as separate PRs... :D |
Is this still true when you start by converting from deltas to deformations? If you start with a deformation, then yes, you get:
If you start with deltas, then you get
I'm not sure why doing the addition in one place vs the other would accumulate more floating point error. |
Hello, I believe there is a bug during the mapping of deformation fields.
In the .map method of the DenseFieldTransform class, I believe the locations that are mapped out-of-domain should be set to the initial coordinates instead of 0. Otherwise, if for example you want to go back to the displacement field by subtracting the reference coordinates you end-up with very large displacements instead of 0.
Thanks for your work!
The text was updated successfully, but these errors were encountered: