[Insight-developers] HDF5 Transform I/O Again -- definitions of fixed/moving parameters

[Williams, Norman K]

I haven't waded into itk::NiftiImageIO for a couple of years.  I don't
have a strong opinion one way or the other about which data to use for the
Image Directions.  I do what the smart guys tell me to do.

So the best suggestion I have is for you to log a bug in the ITK Bug
Tracker, and I (or someone else) will get to it before release.

I'd also like it if the ITK brain trust would look carefully at
Christopher's suggestion and comment whether this change is a good idea.
It  theoretically could break backwards compatibility, but I don't know if
it would really sabotage real-world code in any serious manner.


On 3/31/11 2:15 PM, "Rorden, Christopher" <rorden at gatech.edu> wrote:

>Hello-
>  I would personally suggest that by default you use the s-form when it is
>available, and only use the q-form if the s-form is not available. This
>would be consistent with the other popular tools (SPM, FSL with
>'usesqform', and MRIcron). Likewise, SPM's display feature only adjusts
>the s-form, allowing you to revert to scanner settings but allowing you to
>manually adjust the origin. Likewise (thanks to a great tip from Brian
>Avants) I have been working with Babak Ardekani to adapt his acpcdetect
>software to translate and rotate an images' sform so that the origin is
>the AC and the image is aligned to ac-pc space. This is a huge  benefit
>for normalization tools that can get trapped at the local minima (in the
>attached image, the top row shows images where normalization failed using
>the original scanner coordinates, with the bottom row showing each
>individuals successful normalization following automated origin location).
>Further, this step makes the sophisticated normalization routines run much
>quicker, as they quickly converge on a good solution. In theory,
>individual users could manually convert the sform to its qform (e.g. use
>MRIcron for Windows and choose 'Use for Quat' in the header's reorient
>tab), but it does seem like conventions are good.
>
>I actually do not agree with this interpretation of the NIfTI
>specification:
>>>This is an issue with NIfTI files -- when I wrote that filter I tried
>>>to follow the NIfTI spec and use the appropriate transform.  If
>>>there's still a problem with this, it needs to be fixed in the NIfTI
>>>file reader.  The only ambiguity is which matrix gets read when the
>>>NIfTI image is read in, and that's a separate issue from Transform I/O.
>If the qform code is "NIFTI_XFORM_SCANNER_ANAT" and the sform code is
>"NIFTI_XFORM_ALIGNED_ANAT", "NIFTI_XFORM_TALAIRACH", or
>"NIFTI_XFORM_MNI_152", then you should certainly use the latter. This is
>also a consensus of all the other NIfTI implementations.
>
>I think this would be easy to implement, even if you include quats to
>represent the data internally. You can use mat44_to_quatern to get the
>sform to look like a qform.
>
>As an aside, and for full disclosure, when the NIfTI standard was being
>proposed I was ardently against the inclusion of both matrix and
>quaternion representations. It means each program needs to support both.
>Personally, I think matrices are much more familiar to most users, more
>flexible, etc; but I would much rather have had two quats than a quat and
>a matrix. However, this is the standard that was decided upon, and we will
>save our users a lot of grief if we can standardize on a single
>convention. Personally, I did not realize that ANTS ignored the sform and
>got frustrated with its poor performance, so I went through a convoluted
>process of combining SPM and ANTS for different stages. In hindsight, I
>only needed to set the qform, but that was certainly not obvious to me.
>
>-chris
>
>-----Original Message-----
>From: brian avants [mailto:stnava at gmail.com]
>Sent: Thursday, March 31, 2011 1:36 PM
>To: Johnson, Hans J; Rorden, Christopher; Gang Song
>Cc: Williams, Norman K; ITK; Michael Stauffer (Circular Logic)
>Subject: Re: [Insight-developers] HDF5 Transform I/O Again -- definitions
>of fixed/moving parameters
>
>hi chris
>
>see some of hans's comments below ---
>
>hans -- thanks for the feedback.  i can see why you would decide to apply
>the qform alone --- in fact, the use case chris mentioned to me was
>exactly what you describe, that is, setting the s-from as a
>post-processing step.    chris suggested that we at least provide a
>warning to the user that the s-form will be ignored --- even better
>the warning should suggest the solution.   i think that's a touch
>smarter than just ignoring the s-form.
>
>re: additional stuff to include in the I/O --- michael and i discussed
>this a while back and he has the list of ideas somewhere.  one thing not
>covered that's important to record for high-dimensional transformations is
>the interpolator that is used to generate /
>interpret the transformation.   it becomes very important if one is
>integrating velocity fields which can involve accumulating hundreds of
>interpolations to generate a deformation.
>
>re: bspline stuff, i am sure marius, nick and mark j will have more
>insight ... but again, the specific type of bspline should probably be
>recorded, not just the order but also the model.
>
>generally, it might be useful to have a sample transformed point embedded
>in the header as well that can be used as a reference for
>interpretation.   i.e. that specifies the output of the tx at a point.
>
>if x= (  a, b , c ) , the  T ( x ) = ( d , e , f ) .
>
>so a future user would know what to expect.
>
>B
>
>
>On Thu, Mar 31, 2011 at 12:26 PM, Johnson, Hans J <hans-johnson at uiowa.edu>
>wrote:
>> Brian,
>>
>> Thanks, and let's keep this conversation going.
>>
>>
>> I've also added some comments below.
>>
>> Hans
>>
>>
>> On 3/31/11 11:07 AM, "Williams, Norman K"
>> <norman-k-williams at uiowa.edu>
>> wrote:
>>
>>>
>>>On 3/31/11 10:29 AM, "brian avants" <stnava at gmail.com> wrote:
>>>>this is a nice start ... one note is that we do want to be able to
>>>>read/write deformation field transforms, as well as velocity fields,
>>>>with this I/O framework.
>>>
>>>I am working on HDF5 ImageIO, and fields are generally a form of
>>>image.  I presume that field transforms would be a wrapper around an
>>>image.  One advantage of HDF5 is that once I define the layout of an
>>>image as HDF5 group, that image data can be added in-line into a
>>>transform file, as one of a list of heterogenous transforms.
>> One of the really nice things about HDF5 is that it is dynamically
>> flexible and has the ability to store whatever we want in it!   The
>> trick is not about the capabilites of HDF5, but rather about our
>> convention for using those capabilities in a consistent way.
>>
>> One could put Displacementfields, AffineMatricies, intensity images,
>> and all their associated meta-data into HDF5 format quite easily, and
>> in many ways using the HDF viewer tools (I.e. Matlab) they would
>> appear as "files/objects in a directory".
>>
>>
>>>
>>>
>>>
>>>>deformation / velocity fields and bsplines should probably keep track
>>>>of the physical space for their domain of definition.
>>>
>>>Deformation Fields are images, and if they don't have the same
>>>physical space as the images they're meant to transform, I'm not sure
>>>what use they are. Is there additional information about the reference
>>>image that should be saved?
>>>
>>>As for BSplines, the fixed parameters comprise the grid size, grid
>>>origin and grid spacing.  Would that not naturally map to the
>>>reference image physical space? What information that is part of the
>>>reference image would need additionaly to be saved with the BSpline
>transform.
>>
>> While we don't immediately see the utility of this in the current
>> understanding of the framework, HDF5 is capable of doing what ever we
>> need,  we just need to define a consistent and un-ambiguous protocol
>> for interpretation.
>>
>>>
>>>
>>>>additionally,
>>>>chris rorden has brought up other issues with itk prioritizing qform
>>>>transforms rather than sforms .... my understanding is that what this
>>>>means is that an image that contains both an sform and a qform will
>>>>be transformed differently by different programs depending on the
>>>>interpretation of these header fields.
>>>
>>>This is an issue with NIfTI files -- when I wrote that filter I tried
>>>to follow the NIfTI spec and use the appropriate transform.  If
>>>there's still a problem with this, it needs to be fixed in the NIfTI
>>>file reader.  The only ambiguity is which matrix gets read when the
>>>NIfTI image is read in, and that's a separate issue from Transform I/O.
>>
>> I agree with Kent here.  We are aware that different tools interpret
>> the sform/qform matricies differently.  Some tools even use both.  We
>> had several conversations, but could never figure out what the
>> definitive one correct way to do it was.  In the end we choose to only
>> interpret one, and somewhat arbitrarily choose that if both exists
>> then only the qform would be respected.  The sform only is used if the
>qform is ascent.
>>
>> The reason for this was that our interpretation was that the qform
>> came from the DICOM data and was representative of an acquisition
>> process (and suitable for image direction cosigns, origin, spacing),
>> and the sfrom was an optional post processing alignment (more suitable
>> to be interpreted as a transform to be applied to the physical space
>> of the qform transformed image).  If one wanted both, our
>> interpretation was that the image would have to be read twice: step
>> one itk image file reader to create an image, and step two, itk
>> transform file reader to read the sform matrix only as an affine
>> matrix.  NOTE:  ITK can not write SFORM images under this set of
>assumptions!
>>
>> If we are wrong in this approach, then ITKv4 is our time to try to fix
>> this, or we will be stuck for another 10 years.
>>
>>>
>>>>anyway, if we want itk to be
>>>>able to interact more cleanly with toolkits such as spm and fsl, then
>>>>we need to consider some of these issues.
>>>
>>>I can use all the guidance on these issues I can get, since I'm a
>>>simple caveman programmer and not an image processing expert.
>>
>> We have considered this many times in the past.  There has just been
>> no definitive solution that we've found to satisfy all these
>> constraints simultaneously.
>>
>>>
>>>>
>>>>i am cc'ing mark jenkinson and chris rorden because these guys know
>>>>far more about these issues than i do and it would be really great if
>>>>we could make decisions that would allow us to work a little more
>>>>easily with these other code bases.  for instance, i know chris has
>>>>spent significant time debugging failures that come down to
>>>>inconsistent use of header transformations.
>>>>
>>>
>> Thanks!  We look forward to someone telling us that we are definitely
>> wrong, and that the solution is simple :)
>>>
>>
>>
>>
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by
>the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>confidential and may be legally privileged.  If you are not the intended
>recipient, you are hereby notified that any retention, dissemination,
>distribution, or copying of this communication is strictly prohibited.
> Please reply to the sender that you have received the message in error,
>then delete it.  Thank you.
>> ________________________________
>>



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________