<div dir="ltr"><div>Hi Simon,</div><div><br></div>Thanks so much. That answered my question. <div><br></div><div>Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>My first thought would be to use something like this:<br></div><div><br></div><div> Gap_first = (second angle - first angle) * 2 (Just use the gap on one side)</div><div><br></div><div>or</div><div><br></div><div> 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)</div><div><br></div><div><br></div><div>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.<br></div><div><br></div><div>I would love to know if you have any thought on this. Thanks :)</div><div><br></div><div>Cheers,</div><div>Andy</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-24 19:24 GMT+11:00 Simon Rit <span dir="ltr"><<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Andy,<br></div>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.<br></div>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.<br></div>Regards,<br></div></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh <span dir="ltr"><<a href="mailto:hsieandy@gmail.com" target="_blank">hsieandy@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi Simon & RTK developers & the RTK community,<div><br></div><div>I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt.</div><div><br></div><div>The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta.</div><div><br></div><div>However I noticed that at line 93 itFirstAngle is acquired by:</div><div><br></div><div><div> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]);</div><div> itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle;</div><div> itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle;</div></div><div><br></div><div>Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead?</div><div><br></div><div>And also for itLastAngle at line 99:</div><div><br></div><div><div> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]);</div><div> itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle;</div></div><div><br></div><div>Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext).</div><div><br></div><div>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.</div><div>Is there any reason for this implementation?</div><div><br></div><div>Thank you.</div><div><br></div><div>Cheers,</div><div>Andy</div></div>
<br></div></div>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank">Rtk-users@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/rtk-users" target="_blank">http://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>