[Rtk-users] Correction for detector in-plane rotation?

[Simon Rit]

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!
Simon


On Fri, Feb 14, 2014 at 4:32 PM, Chao Wu <wuchao04 at gmail.com> wrote:

> Hi Simon,
>
> Thanks for the confirmation.
> 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.
>
> 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.
> 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).
>
> So now I am thinking how to solve the problem.
> 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).
> Or modify the DisplacedDetectorImageFilter to account for IPR while leave
> the FFTRampImageFilter as it is.
> Do you have any other comments and suggestions? Thank you.
>
> Best regards,
> Chao
>
>
>
> 2014-02-14 15:10 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
> Hi,
>> 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.
>> How large are your rotations?
>> Simon
>>
>>
>>
>> On Fri, Feb 14, 2014 at 2:26 PM, Chao Wu <wuchao04 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> First thanks for the hard work on this nice toolkit.
>>>
>>> I am working on FDK reconstruction.
>>> 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.
>>> 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.
>>> Did I miss anything around here? In which steps and to which extent the
>>> in-plane rotation has been taken into account?
>>>
>>> Best regards,
>>> Chao
>>>
>>> TUDelft, NL
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at openrtk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20140214/3758cb7a/attachment-0009.html>