[Rtk-users] Rtk-users Digest, Vol 26, Issue 5

Andy Shieh hsieandy at gmail.com
Sat Oct 25 09:41:26 EDT 2014


Hi Jan,

Thanks for sharing.
This does seem useful to me, but I'm not sure if I understand your method
correctly.

For your lower and upper integration limit, do you mean the limit values
for the angular range that you are "expecting"?
For example if you are expecting a 0-180 deg scan (although the first and
last angles might not be 0 and 180 due to sampling), lower/upper
integration limit would be 0 and 180 deg?

And why is the division 2 needed there?
I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the
weighting is "nextAngle - previousAngle" for a certain projection.
In this case I would expect Gap_first to be

Gap_first = second_angle - lower_integration_limit
(As the lower integration limit is kind of like the "virtual angle" preceding
the first angle?)

Thanks for your help :)

Cheers,
Andy



> Date: Fri, 24 Oct 2014 17:21:27 +0200
> From: Jan Hoskovec <jean.hoskovec at gmail.com>
> To: Andy Shieh <hsieandy at gmail.com>
> Cc: "rtk-users at public.kitware.com" <rtk-users at public.kitware.com>
> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in
>         rtkParkerShortScanImageFilter.txt
> Message-ID:
>         <CANtP0QSnh70uETrdyTjg=u3HaUth4kRwDVfhMmKL=
> DhwrwzNLg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Andy,
>
> I was recently dealing with a similar problem in a different context
> (180? backprojection with irregular sampling and how to handle the
> first and last gaps) and what worked for me was
>
> Gap_first = (second angle - first angle) / 2 - lower integration limit
>
> and, analogically,
>
> Gap_last = upper integration limit - (last angle - second last angle) / 2
>
> with the integration limits being arbitrary set where I wanted them.
> The idea behind this was that a continuous projection value we are
> miming in the discrete integral should always be represented by the
> closest projection we have, with a known angular segment to cover.
>
> However, that was a DBP-type algorithm, for which the exact
> integration limits are extremely important, it may be different in the
> context of a short scan. But just in case you might find this
> useful...
>
> Cheers,
>
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20141026/b655434e/attachment-0008.html>


More information about the Rtk-users mailing list