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

Blezek, Daniel J (GE, Research) blezek at crd.ge.com
Wed Jan 18 10:02:10 EST 2006 

Luis,  My understanding of Bill's experiment was that he had 6 images of the same object loaded as oriented images in ITK, which he then displayed using VTK (Slicer3?, I don't remember).  His experiment indicated that the VTK-ITK bridge correctly took each of the 6 images in different acquisition directions correctly into the VTK coordinate system.

Having been through this mess over the past 2 years...

It is my understanding of the DICOM standard that DICOM images using the tags that Gordon quoted are specified in the 3rd coordinate system that you mention, i.e. Physical Coordinate System.  The coordinates are specified relative to the landmark done when the patient is scanned and have no bearing on the scanner coordinate system.

My initial experience with OrientedImages were quite positive.  I registered an axial of my head with a sagittal.

-dan

-----Original Message-----
From: insight-developers-bounces+blezek=crd.ge.com at itk.org
[mailto:insight-developers-bounces+blezek=crd.ge.com at itk.org]On Behalf
Of Luis Ibanez
Sent: Wednesday, January 18, 2006 8:09 AM
To: Gordon Kindlmann
Cc: Bill Lorensen; insight-developers at itk.org; Mathieu Malaterre
Subject: Re: [Insight-developers] [GDCM] ITK Origin and coordinate
system




Hi Gordon,


It seems that it will be helpful to add a couple of definitions here.


For example, I would suggest:


1) Image Grid : The discrete grid used for sampling the image.
                 Coordinates in this grid are given by indices
                 that have N integers (N being the dimension of
                 the image).  In most cases we assume that the
                 first pixel in the image has index = (0,0,0..).
                 The exception is when the image is a subregion
                 of another image.

                 (this is like the itk::Index)



2) Image Coordinate System: The coordinate system attached to
                the axis of the image grid. If we have the N unit
                vectors that are parallel to each one of the grid
                axis, then the coordinates of a point in the image
                space are given by N float numbers (that can be
                grouped into an itk::Point type. Conversions from
                Point to Index only require rounding. The unit
                vectors describing the grid are not necessarily
                orthogonal.

                (this is like the itk::ContinuousIndex)



3) Physical Coordinate System: The physical coordinates of the
                patient/scanner space. These are given in
                millimeters and use orthogonal axis.

                (this is like the itk::Point)


   Conversions between the Image Coordinate System and the Spatial
   coordinate system are made by using the unit vectors of the image
   grid. These unit vectors are in the Spatial Coordinate System.



   The physical point Q corresponding
   to an image point P is computed as



          Qi = Si *[ Sum{over j}[  Vij * Pj ] ]      Eq. (1)


   Where

          Qi   is    the i-th component of the point Q

          Si   is    the i-th pixel spacing

          Vij  is    the i-th component of the
                         j-th unit vector
                             (the vector parallel to the
                              j-th axis of the image grid)

          Pj   is    the j-th component of the point P.



In our parlance, the components of the unit Vectors Vj are
the "direction cosines" of the image grid axis.


Our question at this point is whether DICOM specifies the Image Origin
in the "Image Coordinate System" or in the "Spatial Coordinate System".


    ... and the answer to that question
        is still to be determined with certainty...



Bill's experiment points to the conclusion that the origin is given
by DICOM in the "Image Coordinate System" and therefore need to be
converted to the "Physical Coordinate System" using Eq.(1).


We must fear the posibility that different scanner vendors interpret
the origin definition in different ways....



      Luis



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

More information about the Insight-developers mailing list