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

[brian avants]

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