Apply PPD reorientation for tensor data in antsApplyTransforms #1879
Conversation
|
@ntustison @stnava will this interfere with any of your workflows? Should I make this not the default behavior? I could add a |
|
I'm pretty sure this will be fine with anything I'm doing. Thanks @cookpa. |
|
Thanks Nick! I remembered Brian had posted some code from antsPyMM over at Looking at that, I see he is splitting the channels, warping, then reorienting. This would continue to work and would be the alternative I would recommend to use |
|
yeah - I think this change that you are making will not impact antspymm. although I tested antspymm reorientation with a large variety of cases, am still not sure it's correct. I'd be happy to switch to something that is more well validated if possible. |
|
Thanks @stnava I think the antspymm method does have some of the same problems I have been working on. It is a really tricky thing to debug because the image headers, the code, and the visualization software can all change things. Will open an issue on antspymm. I need to evaluate more, and am getting some help from a collaborator soonish. |
|
I'm going to merge later unless I think of any other issues. I think this + other recent fixes solve the coordinate basis problem, and the new ImageMath edits allow for import of tensors from FSL, taking into account the change in sign of the x-axis for direction matrices with positive determinants. There remains the question of how best to estimate the local rotation from a displacement field. I have a couple of prototype scripts that I will try to develop further, and test on real data somehow. I think the real test is doing whole-brain tractography |
Now that the PPD filter supports composite transforms, it is feasible to add it directly to antsApplyTransforms. This avoids the need to use a separate program and keep track of the transforms to use.
This simplifies things for users, and reduces potential for mistakes in transform composition.
To make this happen, I had to change the tensor type in AAT from a general itk::SymmetricSecondRankTensor to a DiffusionTensor3D. Typing this, I realize I should document this in the usage.
I think DiffusionTensor3D is the vast majority of use cases, so I'm thinking it would not be worth complicating usage by separately supporting generic tensors. Non-diffusion tensors might not also work with the log transformation that we apply automatically.