[vtkusers] DICOM patient position and direction cosines?

[Mark Roden]

Hi Justin,

Practically, what happens is that RT structs won't register if the default
VTK coordinates are used.  The implementations I've seen treat the x and y
coordinates as I've described; namely, as positive offsets multiplied by
spacing, and that the patient position is the upper left coordinate of the
image.  As in (3.3 2009 Table C-7-10 on page 375):

Image Position (Patient) (0020,0032) 1

The x, y, and z coordinates of the upper
left hand corner (center of the first voxel
transmitted) of the image, in mm. See
C.7.6.2.1.1 for further explanation.

and

C.7.6.2.1.1 Image Position And Image Orientation
The Image Position (0020,0032) specifies the x, y, and z coordinates of the
upper left hand
corner of the image; it is the center of the first voxel transmitted. Image
Orientation  (0020,0037)
specifies the direction cosines of the first row and the first column with
respect to the patient.
These Attributes shall be provide as a pair. Row value for the x, y, and z
axes respectively
followed by the Column value for the x, y, and z axes respectively.

So there's some ambiguity here (at least, from the two sections we've both
just quoted).

My interpretation is that the coordinate of the upper left point has already
had direction cosines applied to it such that increasing the x coordinate
requires multiplying the offset by the spacing to get the real-world
coordinate.  From what I've seen of the implementations of RTStructs stored
by Eclipse, they share that interpretation.  In this interpretation, the
direction cosines can then be manipulated to change how the image is
displayed (whether from a radiologists view or a neurologists view, for
instance), but that the 'real world spatial coordinates' are already defined
by  20,32 and the spacing tags.

The reason I'm interpreting the standard this way has to do with software
that's been deployed in the field.  Eclipse is the software I've dealt with
the most, and Eclipse behaves this way.  Velocity, another package, also
appears to behave the way I've described.  As I said, I'm not sure if it's
bugged behavior, but the behavior that treats the x coordinate the way I've
described is the behavior I've had to deal with.  I'm not an expert on DICOM
by any means-- as you say, it's a beast of a thing.

A better update to my code would be to ensure that the RTstruct registers
properly on to the space, in case Eclipse or Velocity or someone else is
bugged.  And, as I've said, the whole solution is incorrect once the
direction cosines are no longer unitary.

Mark



On Fri, Nov 5, 2010 at 9:49 AM, Justin Mikell <justin.mikell at gmail.com>wrote:

> Hi Mark,
>
> This is in reference to your vtkusers list post.
>
> "DICOM specifies that each imaging plane has the upper left xy coordinate
> in
> each 2d slice specified.  That coordinate is in tag 0020,0032 (Image
> Position (Patient)).  DICOM then specifies that each subsequent pixel in
> the
> x y plane is determined by the spacing from that coordinate (generally
> positive).  So, if you have an x extent of -300 and a pixel spacing of 1 on
> a 512x512 image, then your x coordinate will span from -300 to 212.  This
> is
> true regardless of the direction cosines in the image.  The direction
> cosines tell the user the orientation of the patient as regards to the
> scanner, and should be used to determine display, but not the coordinates
> of
> the data."
>
>
> As the DICOM standard is a huge beast, I could definitely be interpreting
> it incorrectly, but I have looked at part 3 of the DICOM standards from 2007
> (PS3.3 pg 301) and 2009 (PS3.3 pg 375 available at NEMA website) and I think
> the image positions (patient coordinates) (x,y,z) depend on the direction
> cosines.
>
> An excerpt from the standard:
>
> *The direction of the axes is defined fully by the patient’s orientation.
> The x-axis is increasing to
> the left hand side of the patient. The y-axis is increasing to the
> posterior side of the patient. The
> z-axis is increasing toward the head of the patient.*
> ...
> *Note: In previous versions of this Standard, image position and image
> orientation were specified
> relative to a specific equipment coordinate system. This equipment
> coordinate system was not
> fully defined and a number of ambiguities existed. The equipment based
> coordinate system has
> been retired and replaced by the patient based coordinate system defined in
> this Module.*
>
> -Justin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20101105/3ddc785f/attachment.htm>