<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hello Justin and Mark,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hope that helps.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> --
Scott<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
vtkusers-bounces@vtk.org [mailto:vtkusers-bounces@vtk.org] <b>On Behalf Of </b>Mark
Roden<br>
<b>Sent:</b> Friday, November 05, 2010 3:45 PM<br>
<b>To:</b> Justin Mikell<br>
<b>Cc:</b> VTK<br>
<b>Subject:</b> Re: [vtkusers] DICOM patient position and direction cosines?<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Hi Justin,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Mark<o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Nov 5, 2010 at 1:27 PM, Justin Mikell <<a
href="mailto:justin.mikell@gmail.com">justin.mikell@gmail.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi again Mark,<br>
<br>
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.<br>
<br>
Have you worked on patients that were scanned in different positions, prone,
head first versus feet first, left decubitis, etc.?<br>
For example, head first supine would give: Xxyz = (1,0,0) and Yxyz=(0,1,0).
Adding pixel spacing works.<br>
Feet first supine: Xxyz=(-1,0,0) and Yxyz=(0,1,0). Adding pixel spacing doesn't
work.<br>
<br>
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.<br>
<span style='color:#888888'> <br>
-Justin</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Fri, Nov 5, 2010 at 12:25 PM, Mark Roden <<a
href="mailto:mmroden@gmail.com" target="_blank">mmroden@gmail.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi Justin,<br>
<br>
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):<br>
<br>
Image Position (Patient) (0020,0032) 1 <br>
<br>
The x, y, and z coordinates of the upper<br>
left hand corner (center of the first voxel<br>
transmitted) of the image, in mm. See <br>
C.7.6.2.1.1 for further explanation. <br>
<br>
and<br>
<br>
C.7.6.2.1.1 Image Position And Image Orientation <br>
The Image Position (0020,0032) specifies the x, y, and z coordinates of the
upper left hand <br>
corner of the image; it is the center of the first voxel transmitted. Image
Orientation (0020,0037) <br>
specifies the direction cosines of the first row and the first column with
respect to the patient. <br>
These Attributes shall be provide as a pair. Row value for the x, y, and z axes
respectively <br>
followed by the Column value for the x, y, and z axes respectively. <br>
<br>
So there's some ambiguity here (at least, from the two sections we've both just
quoted).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<span style='color:#888888'><br>
Mark</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Nov 5, 2010 at 9:49 AM, Justin Mikell <<a
href="mailto:justin.mikell@gmail.com" target="_blank">justin.mikell@gmail.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>Hi Mark,<br>
<br>
This is in reference to your vtkusers list post.<br>
<br>
"DICOM specifies that each imaging plane has the upper left xy coordinate
in<br>
each 2d slice specified. That coordinate is in tag 0020,0032 (Image<br>
Position (Patient)). DICOM then specifies that each subsequent pixel in
the<br>
x y plane is determined by the spacing from that coordinate (generally<br>
positive). So, if you have an x extent of -300 and a pixel spacing of 1
on<br>
a 512x512 image, then your x coordinate will span from -300 to 212. This
is<br>
true regardless of the direction cosines in the image. <span
style='background:#FFFF33'>The direction</span><br>
<span style='background:#FFFF33'>cosines tell the user the orientation of the
patient as regards to the</span><br>
<span style='background:#FFFF33'>scanner, and should be used to determine
display, but not the coordinates of</span><br>
<span style='background:#FFFF33'>the data</span>."<br>
<br>
<br>
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.<br>
<br>
An excerpt from the standard:<br>
<br>
<i>The direction of the axes is defined fully by the patient’s orientation.
The x-axis is increasing to<br>
the left hand side of the patient. The y-axis is increasing to the posterior
side of the patient. The<br>
z-axis is increasing toward the head of the patient.</i><br>
...<br>
<i>Note: In previous versions of this Standard, image position and image
orientation were specified<br>
relative to a specific equipment coordinate system. This equipment coordinate
system was not<br>
fully defined and a number of ambiguities existed. The equipment based
coordinate system has<br>
been retired and replaced by the patient based coordinate system defined in
this Module.</i><br>
<span style='color:#888888'><br>
-Justin</span><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>