<div dir="ltr"><div><div><div><div><div><div>Hi,<br>Thank you for your interest in RTK. Please use the mailing list for questions that are of interest to anyone using RTK.<br></div>There are many ways to model the direct problem (forward projection). Without going into too many details (available in the publications of each method) :<br>- "As far as I understand the goal of this approach is to calculate the intersection length of a ray through a voxel, right ?" False. Joseph's method samples the ray with one pixel per slice in the main direction but it does not compute the intersection of the ray with each voxel. <a href="http://www.ncbi.nlm.nih.gov/pubmed/4000088">Siddon's method</a> does that. In fig 2 of <a href="http://www3.cs.stonybrook.edu/~mueller/papers/ISBI_06_quality_2.pdf">[Xu and Mueller, 2006]</a>, Joseph is referred to "slice interpolated" and Siddon to "box-line-integrated".<br>- "I can calculate the intersection length of the ray within a voxel by a simple substraction, this runs very fast." This sounds very interesting, don't hesitate to share the code and/or the publication! BTW, what is DDA?<br></div>- Small voxels / pixels,  "Did you find a way to handle this ? " We don't handle this in RTK except if you consider that spatial regularisation (e.g., total variation) will overcome this problem in a way. But generally we use matching resolution between pixels and voxels so the problem is minimal. For the backprojection, we typically used voxel-based backprojection using the center of the voxel which is faster than what you (seem to) use. I think that if these things are a problem for you, there is a nice solution called <a href="http://stacks.iop.org/PMB/49/2463">distance driven (back-)projection</a> (by De Man and Basu). I think it will do exactly what you want. I haven't implemented it in RTK (yet).<br></div></div></div>Thanks for the last trick, I am aware of it (<a href="http://dx.doi.org/10.1109/TMI.2006.876169">Riddell published it calling this "Rectification"</a>), I'm not sure that would change the computation time by a large factor but I should check. I think you then need an additional interpolation no to resample the "moved" object, no?<br></div>I hope this helps. Let me know if sg is not clear in my answer!<br>Cheers,<br>Simon<br><div><div><div><div><br><div><div><a href="http://in2p3.fr/home/q/quinones/simulations/pct_spiral/run.uSTG" target="_blank"></a></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:31 PM, Robert Calließ <span dir="ltr"><<a href="mailto:robert.calliess@gmx.de" target="_blank">robert.calliess@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="DE"><div><p class="MsoNormal">Dear Mr. Simon Rit,<u></u><u></u></p><p class="MsoNormal">I had a look at the very interesting project RTK that you’re currently<u></u><u></u></p><p class="MsoNormal">working on  and I’m also interested in methods you use for forward and <u></u><u></u></p><p class="MsoNormal">back projection in the fields of S-ART. I saw that you use Joseph’s method <u></u><u></u></p><p class="MsoNormal">for the projectors. As far as I understand the goal of this approach is to calculate <u></u><u></u></p><p class="MsoNormal">the intersection length of a ray through a voxel, right ? I’m working on a S-ART <u></u><u></u></p><p class="MsoNormal">reconstruction and use a modified 3D-DDA where I can calculate the intersection <u></u><u></u></p><p class="MsoNormal">length of the ray within a voxel by a simple substraction, this runs very fast. <u></u><u></u></p><p class="MsoNormal">So I think both approaches,  Joseph’s and mine, should bring the same results as <u></u><u></u></p><p class="MsoNormal">they calculate the intersection  length of a ray in a voxel.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">However I encountered a problem with these raybased approaches. Because we use conebeam<u></u><u></u></p><p class="MsoNormal">geometry there will be divergent rays. That means, the higher the volume resolution gets the more<u></u><u></u></p><p class="MsoNormal">voxels will be missed during forward projection because some of them are between two adjacent ray. <u></u><u></u></p><p class="MsoNormal">Also if the volume resolution gets higher the voxels get smaller and the intersection lengths (our weights)<u></u><u></u></p><p class="MsoNormal">will get very small. I think this will also be a problem with Joseph’s method.<u></u><u></u></p><p class="MsoNormal">Did you find a way to handle this ?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">For the backprojection there is  the same problem. I use a voxelbased backprojector where I project all 8 vertices<u></u><u></u></p><p class="MsoNormal">of a voxel on the detector plane, then calculate the minimum bounding rect of the 8 intersection points in the detector plane<u></u><u></u></p><p class="MsoNormal">and finally I send all rays through the voxel, that are within this bounding rect. The problem here is, as the volume resolution<u></u><u></u></p><p class="MsoNormal">gets higher the voxels get smaller and the 8 vertices that are projected on the detector plane will produce a very small bounding rect<u></u><u></u></p><p class="MsoNormal">that finally will contain only 1 or 2 rays.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The only „workaround“ I found is, to virtually increase the number of rays for instance by upscaling the projection images. But this<u></u><u></u></p><p class="MsoNormal">will increase computation time.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">A little performance trick (if you are not already used it) when using FDK for<u></u><u></u></p><p class="MsoNormal">a circular conebeam geometry, you can calculate a correction transformation <u></u><u></u></p><p class="MsoNormal">to align the detector to the z-plane. Of course this has to be applied to the object and<u></u><u></u></p><p class="MsoNormal">source as well. So the whole scene-geometry is a little bit „moved“ so that the detector aligns<u></u><u></u></p><p class="MsoNormal">with the z-plane. This will speed up reconstruction because we can now use the<u></u><u></u></p><p class="MsoNormal">intercept theorem to determine where the voxel will hit the detector.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Best regards,<u></u><u></u></p><p class="MsoNormal">Robert Calließ<u></u><u></u></p></div></div></blockquote></div><br></div>