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

[Johnson, Hans J]

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