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

[Williams, Norman K]

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.



>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.


>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.

>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.

>
>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.
>



________________________________
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.
________________________________