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

[Simon Rit]

Hi Andy,
I don't have a strong opinion. For the design, letting ProjectionGeometry
tell if it's a short scan is one option. The other is to cancel out the
angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and
create a new weighting. The advantage of the latter option is to keep
things compartimented while the other shares the definition of a short scan
accross filters.
I don't think there is a good answer to what is the best weighting. I think
that using the angular gap of the two projections adjacent to the large gap
is good enough, you just have to make sure then that the start of the scan
is half this gap before this first angle (and idem on the opposite side).
My gut feeling is that it won't make a big difference for Parker weighting.
Simon

On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh <hsieandy at gmail.com> wrote:

> 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/20141027/5d55ab2d/attachment-0009.html>