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<br><br><div class="gmail_quote">On Fri, Nov 5, 2010 at 1:27 PM, Justin Mikell <span dir="ltr"><<a href="mailto:justin.mikell@gmail.com">justin.mikell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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>
<font color="#888888">
<br>-Justin</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Nov 5, 2010 at 12:25 PM, Mark Roden <span dir="ltr"><<a href="mailto:mmroden@gmail.com" target="_blank">mmroden@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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>
<font color="#888888">
<br>Mark</font><div><div></div><div><br><br><br><br><div class="gmail_quote">On Fri, Nov 5, 2010 at 9:49 AM, Justin Mikell <span dir="ltr"><<a href="mailto:justin.mikell@gmail.com" target="_blank">justin.mikell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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-color: rgb(255, 255, 51);">The direction</span><br style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 51);">
cosines tell the user the orientation of the patient as regards to the</span><br style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 51);">
scanner, and should be used to determine display, but not the coordinates of</span><br style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 51);">
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><font color="#888888"><br>-Justin<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>