[vtkusers] DICOM patient position and direction cosines?

[Mark Roden]

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