<div dir="ltr"><div>Hi all,<br><br>I am currently trying to use the "AddProjectionInRadians" method from the ThreeDCircularProjectionGeometry class in RTK to import my geometry.<br><br></div><div>First things first, I would like to know if the information on this pdf are still valid: <a href="http://www.openrtk.org/Doxygen/geometry.pdf">http://www.openrtk.org/Doxygen/geometry.pdf</a><br><br></div><div>Because I used them to deduce the source offset and Projection offset from my own matrix decomposition.<br><br></div><div>Notice that I don't want to use geometric informations coming from the projection images themselves, so their geometric origin is assumed to be (0,0,0) in my case.<br></div><div><br></div><div>In order to check if my geometry import method is correct, I print out one of the intermediate form of the projection matrix used in the backprojection process, in order to check if it is the same as in my own implementation.<br><br></div><div></div><div>To do so, I print out one of the intermediate matrix that is generated in rtkCudaBackProjectionImageFilter while launching a SART reconstruction for instance.<br><br></div><div>I was surpised by the fact that, the matrix allowing the transformation from 2D geometric world to 2D image index world, namely matrixIdxProj in <a href="http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html ">rtkCudaBackProjectionImageFilte.cxx</a> is not always the same along the reconstruction process ?</div><div><br>Here is the line that generates the matrix I don't understand:<br><br>   <span class="">for</span>(<span class="">unsigned</span> <span class="">int</span> i=0; i<2; i++)
<div class=""><a name="l00099"></a><span class=""> </span><span class="">//SR: 0.5 for 2D texture</span></div>
<div class=""><a name="l00100"></a><span class="">  </span>matrixIdxProj[i][2] = -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;</div><br></div><div>What I understand here, is that, we are generating a 2D translation matrix embedded in a 3*3 matrix that allows to take into account two things related to the 2D projection:<br><br></div><div>-If the internal behaviour of the imageContainer, allows buffering of only a part of the image, beginning at index (i,j), this information will be embeded in the projection matrix<br><br></div><div>-the ITK floating point addressing definition seems to differ from the one from cuda (and openCV):<br>When I take a look at <a href="http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching">this page</a> I understand that the floating point indexing (0.5,0.5) in Cuda points to the center of the pixel (0,0) hence a linear contribution of 100%, while it seems that we must add a translation of (0.5,0.5) to the ITK geometric framework in order to get the same behaviour.<br></div><div><br></div><div>In practice <span class=""></span>matrixIdxProj is based on a 3*3 identity matrix, where the inner 2D translation (ie 2 first term of the last column) in my case are:<br></div><div>-in X, a random number between 10 and 150 plus 0.5<br></div><div>-in Y: always 0.5<br><br></div><div>I understand the 0.5 part, but why is there always a 0 offset in Y but a random offset in X remains a mystery to me.<br></div><div><br></div><div>At first, I believed that each projection was splitted into multiple part, each having a different X and Y offset.<br>But reconstructing using only one projection generates only one backprojection operation, with a non zero offset in X, 123 in my case, for an image of size 780 in X.<br><br></div><div>Do you think there is something wrong whith the values of <span class=""></span>matrixIdxProjI am experiencing ?<br><br></div><div>Thank you in advance.<br><br></div><div>Kind regards<br><br></div><div>Thibault Notargiacomo<br></div></div>