<div dir="ltr"><div><div>A small correction: it's actually the amount of data pre-processed (read from disk + all the processing before backprojection) but that should change nothing to what is backprojected.<br></div>I remembered something that can help you: you may want to run UpdateLargestPossibleRegion() to the projections (input 1 of the BackProjectImageFilter) before backprojection to avoid this and make things clearer instead of using a large volume as I was suggesting before.<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <span dir="ltr"><<a href="mailto:gnthibault@gmail.com" target="_blank">gnthibault@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Ok, using geometric information to reduce the amount of data to be backprojected is pretty clever ;)<br></div>This explains the "random" index I was asking about in my previous question, I now know what it is used for and continue my debugging process.<br><br></div>Kind regards<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Thibault Notargiacomo<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-11-10 14:21 GMT+01:00 Simon Rit <span dir="ltr"><<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Thibault,<br></div>You started digging in the code so that gets complicated. First thing first, yes, the link you provide is still valid.<br></div>The offset in X is not random but computed in <a href="https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx" target="_blank">BackProjectionImageFilter::GenerateInputRequestedRegion</a>. The idea is that we request only the part of the projections we need to do the backprojection. This optimizes the streaming (we only read from disk what we need). If you use a huge volume (the test I'd suggest to validate that I'm correct and there is nothing wrong with your code), then you'll need the full projection and you will always get 0 in X as in Y. If you use a small volume and do a computation projection per projection, you will get a varying index depending on your input volume and the geometry for that projection.<br></div>I think you understood the rest pretty well. Does that make sense or am I missing something else?<br></div>Simon</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <span dir="ltr"><<a href="mailto:gnthibault@gmail.com" target="_blank">gnthibault@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><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" target="_blank">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" target="_blank">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>for</span>(<span>unsigned</span> <span>int</span> i=0; i<2; i++)
<div><a name="150f19b7c526dc9e_150f18f42a723d12_150f1698858683f0_l00099"></a><span> </span><span>//SR: 0.5 for 2D texture</span></div>
<div><a name="150f19b7c526dc9e_150f18f42a723d12_150f1698858683f0_l00100"></a><span>  </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" target="_blank">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></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></span>matrixIdxProjI am experiencing ?<br><br></div><div>Thank you in advance.<br><br></div><div>Kind regards<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Thibault Notargiacomo<br></div></font></span></div>
<br></div></div>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank">Rtk-users@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/rtk-users" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>