<div dir="ltr"><div>The simplest is indeed to resample to a non-rotated detector. One reason I did not go into the in plane rotation stuff is that I
wanted to keep the ramp filter independent of the geometry. But this
could be changed if you find it useful, e.g., by adding a filtering
direction. The best would be to avoid a resampling and to account for the rotation in each step. If you want to go in this direction, since it is a rather unusual geometry, I would suggest to check that you obtain relevant results for each step. There are command line tools that split rtkfdk in the 3 steps: rtkfdktwodweights, rtkrampfilter and rtkbackprojections. Let me know if I can help. If you develop something, your contribution will be welcomed!<br>
Simon<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu <span dir="ltr"><<a href="mailto:wuchao04@gmail.com" target="_blank">wuchao04@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">Hi Simon,<div><br></div><div>Thanks for the confirmation.</div><div>The rotation in my projections are less than 0.2 degrees, so the ramp filter along image line or along true horizontal direction may leads to almost identical reconstructions.</div>
<div><br></div><div>I got into this subject because I was working with a displaced detector and found dark and bright regions along the axis of rotation at two side of the mid plane when the IPR is set to non-zero. </div>
<div>After reading the document I realized that this would be due to that the IPR is not accounted when the weighting [G Wang] is performed, then later it is accounted during the FDK, so that Wang's weight function applied to opposite projections does not sum to 1. Before I make any changes to the DisplacedDetectorImageFilter I would like to see how you dealt with IPR in FDK, and suddenly I found IPR is not accounted for either in the ramp filter which is not 'mathematically correct' (but may be sufficient and efficient in practice).</div>
<div><br></div><div>So now I am thinking how to solve the problem. </div><div>The most straightforward way could be that I perform a pre-correction for IPR in all my displaced-detector projections, and send them to rtkfdk with an IPR=0 geometry, since this can make the behaviour of both DisplacedDetectorImageFilter and FFTRampImageFilter ideal (and less workload in coding, of course).</div>
<div>Or modify the DisplacedDetectorImageFilter to account for IPR while leave the FFTRampImageFilter as it is.</div><div>Do you have any other comments and suggestions? Thank you.</div><div><br></div><div>Best regards,</div>
<div>Chao</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-14 15:10 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>:<div>
<div class="h5"><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>Hi,<br></div>Yes, this is correct. In plane rotations are accounted for during backprojection but not in the FFT ramp filter which is done along lines. It should be modifiable if you want to. The weighting in the projection image should not sensitive to in plane rotation since it uses the distance to the center.<br>
</div><div>How large are your rotations?<br></div><div>Simon<br></div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu <span dir="ltr"><<a href="mailto:wuchao04@gmail.com" target="_blank">wuchao04@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">Hi,<div><br></div><div>First thanks for the hard work on this nice toolkit.</div>
<div><br></div><div>I am working on FDK reconstruction.</div>
<div>I noticed that the InPlaneRotation seems not to be handled in some situations, such as in the DisplacedDetectorImageFilter, which is explicitly stated in the document.</div>
<div>Furthermore, when I went through the FDKConeBeamReconstructionFilter, there seems to be no correction for the in-plane rotation to the projection images before they are send to the FFTRampImageFilter. Thus the filtering seems to be performed along the rows of the projection image but not the true horizontal direction of the projection. </div>
<div>Did I miss anything around here? In which steps and to which extent the in-plane rotation has been taken into account?</div><div><br></div><div>Best regards,</div><div>Chao</div><div><br></div><div>TUDelft, NL</div>
</div>
<br></div></div>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@openrtk.org" target="_blank">Rtk-users@openrtk.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>