<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 4, 2016 at 4:09 AM, Richard Brown <span dir="ltr"><<a href="mailto:richard.j.brown@live.co.uk" target="_blank">richard.j.brown@live.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>I read that scaling, reflection/rotation, shear and translation are included in the 4x4 matrix. Given that shear is included in this matrix, shouldn’t gantry tilt be accounted for when I use GetPatientMatrix()?<br></blockquote><div><br></div><div>Yes, the shear will be will be included in the matrix.  However, the marching cubes algorithm expects a rectangular volume and will produce incorrect results if given a sheared volume (unless the shear is very small).  Actually, pretty much any image processing algorithm that looks at voxel neighbors will give incorrect results if the degree of shear is such that the neighbors found by connectivity (i.e. connected by faces) are not the nearest voxels in the spatial sense (i.e. by center-to-center distance).</div><div><br></div><div>Imagine a CT voxel that is 1mm x 1mm x 5mm.  Now imagine that the slice-to-slice shear is greater than 1mm, and draw the resulting parallelogram and its neighbors, and hopefully you'll see the problem.  Even basic operations like linear interpolation give poor results in such a situation, because the neighbors by connectivity are not the nearest neighbors spatially.</div><div><br></div><div>Hence, a gantry-titled CT should be rectified before any 3D processing is applied to it.  It can be un-rectified (re-sheared) before saving it back to disk.  The in-plane resolution of CT is generally very good (1mm or better) so rectification and de-rectification has very little impact on image quality.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And then moving on from 3D surfaces…<br>
<br>
If I didn’t want to produce 3D surfaces; if I wanted to manipulate vtkImageData, is there any precautions I should take?<br>
<br>
For example, if I want to superpose DICOM RT-Structures or other surfaces (notably .STL in my case) onto my vtkImageData, do I need to apply any sort of matrix to either the DICOM vtkImageData or the superposed structures to make sure that they superpose in the correct position with the correct orientation?<br></blockquote><div><br></div><div>My approach is to apply the matrix when I render the image data.  The vtkImageActor, vtkImageSlice, vtkVolume etc. have a SetUserMatrix() method that you can use to correctly orient the image within the world coordinate system.  Generally, this means that I also have to correctly set the camera position and focal point in order to get the desired view of the image.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And lastly, to get the world coordinates (x,y,z) from my vtkImageData coordinates (i,j,k), do I simply apply the GetPatientMatrix()? Is there a method for this? And the same question applies for world coordinate —> index coordinate conversions - I assume I calculate the inverse matrix and apply that in a similar fashion?</blockquote><div><br></div><div>The vtkImageData (i,j,k) coords are called "structured coordinates" in VTK-speak.  Applying the Origin and Spacing to these coords gives the "data coordinates".  VTK's data processing filters work in data coordinates, and if the spacing & origin are in millimeters, then the data coordinates are also in millimeters.  The patient matrix must be applied to the data coordinates, not to the structured coordinates.</div><div><br></div><div>Yes, there is probably a method to convert structured coords to data coords, but I always just explicitly multiply by the spacing and add the origin.</div><div><br></div><div>Cheers,</div><div> - David</div></div></div></div>