[vtkusers] DICOM patient position and direction cosines?

[Scott Johnson]

Hello Justin and Mark,

 

The contour coordinates in an RT Structure Set are specified as spatial
coordinates in the patient coordinate space.  In practice, all
coordinates for a single contour will reside on a single image slice.
The image slice is identified by the SOP Instance Reference in the
Contour Image Sequence (3006,0016).

 

You can tell if the coordinate system for the RT Structure Set instance
is the same as for the images by comparing the Frame of Reference UID
(0020,0052) of the images to the Referenced Frame of Reference UID
(3006,0024) of the RT Structure Set.  If they are the same the
coordinate systems are the same.  If they are different there can be no
assumptions of the relationship from one coordinate system to the other
without some registration information.

 

As long as you work strictly in the patient spatial coordinate system
you shouldn't run into problems with orientation if the Frame of
Reference UIDs match.  If you try to work in pixels you will.

 

Hope that helps.

 

                                -- Scott

 

From: vtkusers-bounces at vtk.org [mailto:vtkusers-bounces at vtk.org] On
Behalf Of Mark Roden
Sent: Friday, November 05, 2010 3:45 PM
To: Justin Mikell
Cc: VTK
Subject: Re: [vtkusers] DICOM patient position and direction cosines?

 

Hi Justin,

It was actually because I received HFS, FFS, and left decubitus patients
that I had to implement this solution, most of which came from Eclipse,
some from Velocity.  Without the flipping, the RTStructs did not work,
and the coordinates when read into VTK were wrong.  Again, I'm not sure
if it's bugged behavior, or who would be responsible for it if it were,
just that I had to do this to get the data to register into the same
space.

The first patients I worked with were FFS, and they didn't require any
changes.  Then came the HFS, then the decubitus.  I think it's very site
and protocol specific as to the orientation of the patient into the
scanner.

Mark

On Fri, Nov 5, 2010 at 1:27 PM, Justin Mikell <justin.mikell at gmail.com>
wrote:

Hi again Mark,

I have worked with some TPS including Eclipse. I'm not sure on the exact
number, but I imagine a very large percentage of patients are scanned
head first supine putting 'patient left' at 'image right' and 'patient
posterior' at image bottom. These are the cases where the patient
coordinate axes and image axes are identical.

Have you worked on patients that were scanned in different positions,
prone, head first versus feet first, left decubitis, etc.?
For example, head first supine would give: Xxyz = (1,0,0) and
Yxyz=(0,1,0). Adding pixel spacing works.
Feet first supine: Xxyz=(-1,0,0) and Yxyz=(0,1,0). Adding pixel spacing
doesn't work.

So, for feet first supine the directional cosines provide the
information needed to know that you must subtract to obtain the proper
patient coordinates. The end result is to use the equation at the top of
(3.3 2009 pg 377). I believe that VTK interprets this correctly
according to your post.
 
-Justin

 

On Fri, Nov 5, 2010 at 12:25 PM, Mark Roden <mmroden at gmail.com> wrote:

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/d71a23f4/attachment.htm>