ANTs and antsRegistration produce different qform orientations #873
Comments
|
Can you please provide a complete reproducible example (with data). |
|
Did you read this? Regardless, antsApplyTransforms should work with either |
|
I did more testing. I use antsRegistrationSyNQuick.sh. When moving and fixed images are two-time point NIFTI files ( I had T1W imaged glued to its FreeSurfer segmentation), then qform of the output Warp.nii (deformation field) is qform_yorient Anterior-to-Posterior. When I supply single time point (T1W itself), the qform of the warp is qform_yorient Posterior-to-Anterior I was always supplying single time point to ANTs and thus the discrepancy. Is qform of the warp field meaningful (used somewhere)? From description y=x + u(x) it should not. Is it expected that behavior should change with the number of time points? Are they both used in the search? |
|
The dimensions of the images must match the -d argument or you will get problems
#250
See the -e option if you want to apply a 3D warp to a 4D image
…Sent from my iPhone
On Oct 10, 2019, at 10:35 PM, moskvich412 <notifications@github.com<mailto:notifications@github.com>> wrote:
I did more testing. I use antsRegistrationSyNQuick.sh. When moving and fixed images are two-time point NIFTI files ( I had T1W imaged glued to its FreeSurfer segmentation), then qform of the output Warp.nii (deformation field) is
qform_yorient Anterior-to-Posterior.
When I supply single time point (T1W itself), the qform of the warp is
qform_yorient Posterior-to-Anterior
I was always supplying single time point to ANTs and thus the discrepancy. Is qform of the warp field meaningful (used somewhere)? From description y=x + u(x) it should not.
Is it expected that behavior should change with the number of time points? Are they both used in the search?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#873?email_source=notifications&email_token=AAEVJM6FCLLMPPK5LL6K65LQN7Q5HA5CNFSM4I7S2SQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA6RM4Y#issuecomment-540874355>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEVJM3T3HVB233AN55GBZ3QN7Q5HANCNFSM4I7S2SQQ>.
|
|
The -d argument puzzles me in general. NIFTI header has this information. So, if this is not a bug, this issue should be closed. At the same time, perhaps something should force consistency between -d and NIFTI header or produce error on mismatch since conflicting information is being supplied., |
|
We've actually been working on this software for quite some time and, as a result, it has been vetted by us and many users over that same period of time. So perhaps instead of assuming or questioning if certain behavior constitutes a bug, it would probably be more helpful (and respectful) if you, instead, ask why things are a certain way. Although the Nifti header contains that information, at times it's useful to force the program to read things as having a specific dimension which is why that option is in most, if not all, of ANTs programs. |
|
In addition, it simplifies the IO situation in ANTs where we're handling multiple image formats and not just Nifti. |
|
I did not assume it is a bug. To quote my first post: "If it is not used [in reference to qform of warp fields], it is irrelevant and this is not a bug. But is it used by antsApplyTransforms?" In the last post, I wrote: " if this is not a bug, this issue should be closed". I did not assume. I asked. Respectfully. And I read before hand how qform is used and sform is not in the ANTs manual. The manual does not mention how qform is used in the warp field file. Only in moving and fixed images. But seeing different qforms from what seemed to me should produce identical results I searched the web. Not finding anything, I asked. Is it a bug? Is qform used? I need this qform to be valid for what I am doing. And precisely because I knew people worked and tested this many times, I had to understand why it changes. Cookpa helpfully provided link to issue 250, which is similar but not identical. Thus, I am not the only one puzzled, if puzzled is something that was interpreted as disrespect. I still do not know reasoning behind change of qform. But I know it is not a bug. If someone can explain or provide link, I promise I will read. Otherwise, I will be careful to watch how many time points I supply knowing that it will work right without knowing the reason. |
|
Can you please provide a complete reproducible example (with data). |
|
I definitely can provide complete example. But this does not seem to be a bug. A bug is when a routine behaves not as intended. I can only determine if routine behaves not as I expect. I can not determine if this is a bug. Only developers can. Nick seems to indicate that this is not a bug and is indeed intended behavior. Then, no more effort should be spent. But if providing example data and command is nevertheless useful in some way, I will. Please let me know. |
I think it's related to the reason for the This same idea is also in the ITK code. The ITK filter for reading an image is the same for all dimensions, so it has a single routine for dealing with the case that the input image has more dimensions than expected, which has to be consistent over all dimensions and file types. And they decided that for reading D dimensions from a (D+i)-dimension image, to just read the first D dimensions of the (D+i) voxel grid. But they do not attempt to figure out the physical space transform, instead setting it to ITK's default. This is the reason that your qforms are different. From the ANTs code perspective, we pass a file name and ask for a D-dimensional image, and the ITK filter returns a D-dimensional image. It doesn't tell us if it subsetted that image out of a (D+i) image. So there's not much we can do about this unless someone gets a pull request approved for ITK to do things differently. |
|
Thank you, cookpa, for explanation. As understood, if there is mismatch between requested (via -d D ) and actual (file header D+/- i ) dimensions, ITK uses default orientation for the requested D. ITK does not inform when such substitution took place. But there is only one -d for all the images. If fixed and moving (and reference for antsApplyTransform) images have different dimensions, then all calculations will be based on incorrect orientations. That is why there is -e 3 for time series, which effectively means "use -d 4 for the moving image". This also explains a problem I had with -e 3, which produced incorrect output. I used NIFTI with 2 time points as reference. |
|
Yes -d should match the same argument in antsRegistration, and the reference image should also have the same dimensionality. -d 4 means do / apply a 4D registration, with 4D warps. -d 3 and -e 2 means apply a 3D warp to each volume of a 4D time series |
|
If NIFTI with single time point (not a 5D, not a vector in 3D) is passed as warp to antsApplyTransform, then antsApplyTransform still succeeds (exit code is 0) with nonsense output. I understand the root of the problem is ITK. Despite ITK noticed discrepancy, a user must duplicate the code (on scripting level) to detect such input errors. |
|
Well.. same applies to corrupt files. I truncated moving NIFTI image (this can happen if a previous process is killed while writing a file to disk) and antsApplyTransform did not complain (exit code 0). |
|
I'll make a note of this on the wiki, but it's unlikely we could fix this as the information is not exposed by the ITK filter we use to read the (many) different file types. |
ANTs and antsRegistration produce wrap fields with different q-forms:
ANTs:
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
antsRegistration:
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
One is left the other is right handed (y-orient is swapped). If it is not used, it is irrelevant and this is not a bug. But is it used by antsApplyTransforms?
The text was updated successfully, but these errors were encountered: