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

brian avants stnava at gmail.com
Thu Mar 31 11:29:42 EDT 2011


hi norman

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.   deformation / velocity fields and bsplines
should probably keep track of the physical space for their domain of
definition.   that is, the physical space of the reference image with
which they were defined.   note that this does not mean these objects
have the same resolution as their reference image, but they would
almost always have the same orientation and origin.  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.    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 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.

brian




On Wed, Mar 30, 2011 at 3:00 PM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> I spent a couple of hours reading source code today to come up with a
> single document describing what the Transform classes do with their
> parameters & fixed parameters.  Since I'm not sure how -- or where -- it
> should go in the ITK Wiki I put it in a Google Doc file:
>
>
> https://docs.google.com/document/pub?id=1zgOCVJ5s6R4rBCK56GS5B_9eVQrBCslNAj
> WGviA2yOU
>
> The goal is to write a more useful representations of transforms into the
> HDF5 file.  Right now each transform is represented thusly:
>
>  /TransformGroup
>  /TransformGroup/N/TransformType            -- string
>  /TransformGroup/N/TransformFixedParameters -- list of double
>  /TransformGroup/N//TransformParameters     -- list of double
>
>
>
> Where I'm thinking would be good would be something like
>
>  /TransformGroup/N/TransformType            -- string
>  /TransformGroup/N/TransformRepresentation  -- 'generic' or 'native'
>    <native transform representation>
>
>
> For example:
>
>  /TransformGroup/0/TransformType "AffineTransform_double_4_4"
>  /TransformGroup/0/TransformRepresentation "native"
>  /TransformGroup/0/Rotation [ [1 0 0 0], [0 1 0 0], [0 0 1 0], [0 0 0 1] ]
>  /TransformGroup/0/Translation [ 0 0 0 ]
>  /TransformGroup/0/CenterOfRotation [0 0 0]
>
> This would make it possible to, from any language with an HDF5 binding,
> write out a transform in an understandable format instead of by reading
> the ITK source to reverse engineer the meanings of the parameters & fixed
> parameters.
>
> What I'd like to get is some feedback on the layout in HD5, as it needs to
> be consistent and documented to be of much use.
>
>
>
> ________________________________
> 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.
> ________________________________
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>


More information about the Insight-developers mailing list