[Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt

[Jan Hoskovec]

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

2014-10-24 12:13 GMT+02:00 Andy Shieh <hsieandy at gmail.com>:
> Hi Simon,
>
> Thanks so much. That answered my question.
>
> Yes, it seems like in most cases discarding those two projections doesn't
> affect the reconstruction much.
> However, for some 4D thoracic reconstruction cases, especially when
> amplitude binning is used, the gap between the 1st and 2nd projection can
> get pretty large, in which case discarding those two projections could lead
> to an unnecessary "insufficient data for proper Parker weighting" warning as
> well as some crazy weighting values that produce massive streaks.
>
> The workaround I might try is to have the ProjectionGeometry object
> determine whether it's dealing with a short scan or not first. And in the
> case it is a short scan, let it calculate the angular gaps differently for
> the first and last angles.
>
> My first thought would be to use something like this:
>
>    Gap_first = (second angle - first angle) * 2              (Just use the
> gap on one side)
>
> or
>
>    Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle
> smaller than but closest to (first angle + 180) )  )             (find its
> closest neighbour 180-deg across)
>
>
> However, I'm not sure if those are appropriate alternative ways to calculate
> the gaps for the boundary angles in order for a reasonable FDK weighting.
>
> I would love to know if you have any thought on this. Thanks :)
>
> Cheers,
> Andy
>
> 2014-10-24 19:24 GMT+11:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>
>> Hi Andy,
>> Good question. Yes there is a reason. In another part of the code,
>> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry
>> angles is discretized by taking into account the AngularGaps so that the
>> algorithm can cope with variations in the rotation speed. Therefore, the two
>> projections around the large angular gap introduced by the short scan will
>> be overweighted because it is not aware of a short scan weighting elsewhere.
>> The solution currently implemented discards the projections around the gap,
>> as you have correctly noticed.
>> There is a better solution which would avoid throwing away these two
>> projections but this was less easy to introduce in the pipeline and in most
>> cases there is a sufficient number of projections anyway. But you could try
>> to modify this if you're dealing with a very few projections.
>> Regards,
>> Simon
>>
>> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh <hsieandy at gmail.com> wrote:
>>>
>>> Hi Simon & RTK developers & the RTK community,
>>>
>>> I have a question about how delta is calculated in
>>> rtkParkerShortScanImageFilter.txt.
>>>
>>> The itFirstAngle and the itLastAngle were used to find the first and last
>>> angular values for calculating delta.
>>>
>>> However I noticed that at line 93 itFirstAngle is acquired by:
>>>
>>>   itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]);
>>>   itFirstAngle =
>>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle;
>>>   itFirstAngle =
>>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle;
>>>
>>> Why are the second and third lines duplicated? Wouldn't this point to the
>>> "second" angle instead?
>>>
>>> And also for itLastAngle at line 99:
>>>
>>>   itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]);
>>>   itLastAngle =
>>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle;
>>>
>>> Why is the second line needed here? Wouldn't this point to the "second
>>> last" angle instead? (Since maxAngularGapPos was caluclated with
>>> GetAngularGapsWithNext).
>>>
>>> I did test this with a 0-200 deg short scan, and found that firatAngle
>>> and lastAngle weren't equal to 0 and 200, but were calculated to be the
>>> second and second last angles instead.
>>> Is there any reason for this implementation?
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Andy
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>