[Insight-developers] [GDCM] ITK Origin and coordinate system

[Peter Cech]

Hello Gordon,

don't be too sorry, it seems that the difference beetween itkImage and
itkOrientedImage is one of the crucial points in this discussion (I did
not realize it myself untill Bill asked me if I used itkOrientedImage).

By "local image coordinates" I meant "Index" in the formula you quoted.

Computation of point from index in itkImage:

    Point = S * Index + Origin

Computation of point from index in itkOrientedImage:

    Point = M * S * Index + Origin

Index' elements are always stored according to image's orientation
(let's say RSP).

In the case of itkOrientedImage, matrix M takes care of prermutation and
flipping between RSP and LPS orientations. It also expects Origin
according to LPS orientation.

On the other hand, itkImage expects Origin according RSP orientation and
also gives Point according to RSP orientation.

Regards,
Peter

On Wed, Jan 18, 2006 at 05:24:09 -0700, Gordon Kindlmann wrote:
> hello,
> 
> Sorry to be a total pest, but can someone help me understand the  
> relationship between
> 
> 1) itkImage
> 2) itkOrientedImage
> 3) The nice mathematical description that Luis previously gave:
> >
> >       Point = M * S * Index + Origin
> >
> 
> Peter, can you help me understand what you mean by "local image  
> coordinates"?  It is the same as the "Index" that appears in Luis's  
> description?
> 
> Gordon
> 
> On Jan 18, 2006, at 2:13 AM, Peter Cech wrote:
> 
> >On Tue, Jan 17, 2006 at 23:14:13 -0500, Bill Lorensen wrote:
> >>In your experiment you must use an itkOrientedImage, not an  
> >>itkImage. Is
> >>that what you used?
> >
> >Exactly. My data volumes are not axis-aligned and itkOrientedImage  
> >gives
> >much better spatial relation between anatomical structures (in global
> >coordinates).
> >
> >itkImage assumes not only volume to be axis-aligned, but local frame
> >actually matches global ITK frame. Recent decision to fix global ITK
> >frame as LPS breaks this assumption.
> >
> >We clearly need different treatment of origin in itkImage and
> >itkOrientedImage. What about having two representations of origin: in
> >global ITK coordinates and in local image coordinates? Local origin
> >would be permuted and axis-flipped to match itkImage orientation (for
> >axis-aligned images, it's the same as applying direction cosines to
> >origin, for the rest permutation+flipping would retain behavior from
> >before direction cosines were introduced).
> >
> >How do you like the idea?
> >
> >Regards,
> >Peter
> >
> >>
> >>Bill
> >>
> >>At 08:13 PM 1/17/2006, Peter Cech wrote:
> >>>On Tue, Jan 17, 2006 at 18:06:02 -0500, Bill Lorensen wrote:
> >>>>In an experiment I did a few months back, I had 6 MR scans done  
> >>>>of the
> >>>same
> >>>>object in each of the 6 orthogonal directions. I read them in  
> >>>>using the
> >>>>current GDCMImageIO  (which transforms the origin using the  
> >>>>direction
> >>>>cosines). All of the volumes roughly lined up without any  
> >>>>additional
> >>>>transformations.
> >>>>
> >>>>If I did not apply the direction cosines, the datasets were all  
> >>>>shifted.
> >>>
> >>>I got several MRI scans of head, the same scanning sequence, but  
> >>>taken
> >>>at various times over last half-year. My experience is exactly  
> >>>opposite
> >>>to yours. With directional cosines applied to origin, there  
> >>>alignment
> >>>was very poor (cca. 10cm shift, both in I-S and A-P direction).  
> >>>Today I
> >>>tried without directional cosines applied to origin and they aligned
> >>>much better, maximum shift was around 5cm and only in S-I direction.
> >>>
> >>>>Go figure,
> >>>
> >>>Yes, go figure...
> >>>
> >>>Regards,
> >>>Peter
> >>>_______________________________________________
> >>>Insight-developers mailing list
> >>>Insight-developers at itk.org
> >>>http://www.itk.org/mailman/listinfo/insight-developers
> >_______________________________________________
> >Insight-developers mailing list
> >Insight-developers at itk.org
> >http://www.itk.org/mailman/listinfo/insight-developers