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

[Andy Shieh]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20141024/7260a51d/attachment-0009.html>