[Rtk-users] Issues using PhaseGatingImageFilter

Thu Jan 15 15:52:35 CET 2015

Hi Chao,

It can be confusing indeed, and I should have added documentation. It is 
a quite common way to perform gating in the cardiac tomography 
community, but not in IGRT.
PhaseGatingImageFilter computes gating weights that depend on the 
distance between a projection's phase and the target phase (both 
expressed as floats in [0; 1[ ), and a window shape. The window's shape 
describes how the gating weight decreases when the distance between a 
projection's phase and the target phase increases.

If the window is rectangular, then the weights are binary. If it is 
triangular, they decrease linearly with distance. You can imagine all 
sorts of window shapes (cosine-squared, bump, ...)

The gating method you describe in

To reconstruction phase N, shouldn't only projections acquired within window N be used?

corresponds to a rectangular window. If you are reconstructing 10 
frames, each one covers 10% of the cycle, and you should use a gating 
window of width 0.1 centered on 0.05 for the first frame, 0.15 for the 
second frame, etc...

Now, about the three centers: if you are reconstructing either the very 
beginning or the very end of the cycle, with a wide window, you end up 
needing to wrap around the cycle. For example, if you reconstruct phase 
0.9 with window width 0.3, the non-zero weights span [0.75; 1.05]. And 
you want them to span [0; 0.05] U [0.75; 1[ instead. Again, this is 
never used in IGRT, but happens in cardiac.

Finally, about the Parker weighting: there doesn't seem to be a "good" 
way to combine gating and Parker weighting. I have used 
PhaseGatingImageFilter only in SART and ADMM_TV, for which Parker 
weighting is unnecessary. If you want to perform gated FDK 
reconstructions with RTK, you could:
- use PhaseGatingImageFilter with a rectangular window and extract the 
weights to get a list of projections to keep
- use rtksubselect to construct a subset of projections, with only the 
ones you want to keep. It will extract the corresponding subgeometry for you
- feed rtkfdk this subset of projections and subgeometry. It will apply 
Parker weights, assuming that gating hasn't removed too many projections 
at the beginning and at the end of your projection stack (because each 
projection removed reduces the total angular range of your 
"acquisition", and it may end up violating the "angularRange >= 180° + 
halfFanAngle" condition)

If you can afford a SART reconstruction, then just use SART with the 
correct gating options. Note that if your gating window is tight, it 
should be much faster than a SART from the whole dataset. You can even 
do better, and initialize a gated SART with an ungated FDK, if you 
prefer some blur and no streaks to some streaks and no blur.

I hope it helps, but do not hesitate to ask if you have more questions.
Cyril

On 01/15/2015 01:30 PM, Chao Wu wrote:
> Dear all,
>
> I am also looking at the PhaseGatingImageFilter. I think I am confused
> by how the weights are computed in ComputeWeights().
>
> At line 83 and 84 the distance is calculated by
> distance = vnl_math_min(fabs(m_GatingWindowCenter - 1 -
> m_Phases[proj]), fabs(m_GatingWindowCenter - m_Phases[proj]));
> distance = vnl_math_min(distance, vnl_math_abs(m_GatingWindowCenter +
> 1.f - m_Phases[proj]));
>
> Then this distance seems to be the smallest distance between the phase
> number and any of the three adjacent gating window centers.
> Afterwards this distance is used for computing the weight based on the
> window width and shape.
> Why are three window centers used here? To reconstruction phase N,
> shouldn't only projections acquired within window N be used?
>
> Another question is about using this filter in FDK. I was wondering
> where's the best place to insert it. Before the
> ParkerShortScanImageFilter or after?
>
> Thanks.
>
> Regards,
> Chao
>
>
> 2014-11-03 18:15 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>> Great, it's been pushed.
>> Simon
>>
>> On Mon, Nov 3, 2014 at 4:15 PM, Geoff Hugo <gdhugo at vcu.edu> wrote:
>>> Hi Simon,
>>>
>>> Yes, this was what I was thinking as well.  Thanks for implementing it, it
>>> worked fine.
>>>
>>> Geoff
>>>
>>> ------------------------------------
>>> Geoffrey D. Hugo, Ph.D.
>>> Associate Professor, Radiation Oncology
>>> Director, Medical Physics Graduate Program
>>> Virginia Commonwealth University
>>> (804) 628 3457
>>>
>>>
>>> On Nov 1, 2014, at 7:22 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
>>> wrote:
>>>
>>>> Hi Geoff,
>>>> I agree with your analysis, PhaseGatingImageFilter is not adequate for
>>>> streaming, which is not surprising since Cyril uses it for iterative
>>>> reconstruction and he typically works with the full stack of
>>>> projections in RAM. I think there is a simple solution: move the
>>>> update of the geometry from the GenerateData to the
>>>> GenerateOutputInformation. That should solve the issue for you.
>>>> Enclosed is a change suggestion, can you give it a try in the
>>>> application you have built?
>>>> I'll commit it if it helps,
>>>> Simon
>>>>
>>>> On Fri, Oct 31, 2014 at 9:29 PM, Geoff Hugo <gdhugo at vcu.edu> wrote:
>>>>> I’m trying to use the PhaseGatingImageFilter class to reconstruct a
>>>>> single
>>>>> breathing phase volume and am running into some problems.  I’ve
>>>>> incorporated
>>>>> this class into an application similar to rtkfdk, putting it in the
>>>>> pipeline
>>>>> between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter.
>>>>> If
>>>>> I run the application trying to select a subset of projections using
>>>>> the
>>>>> method SetGatingWindowCenter, I get a segmentation fault.  The fault is
>>>>> occurring due to allocation errors in
>>>>> rtk::BackProjectionImageFilter::GenerateInputRequestedRegion.  It
>>>>> appears
>>>>> that since the geometry specific to the selected projections is
>>>>> selected in
>>>>> PhaseGatingImageFilter::GenerateData, there is a disconnect between the
>>>>> geometry size and projection stack size during
>>>>> GenerateInputRequestedRegion
>>>>> in the pipeline (pipeline OutputInformation shows the projection stack
>>>>> size
>>>>> is equal to the size of the selected breathing phase projections, but
>>>>> the
>>>>> geometry size is still the total number of (unsorted) projections).
>>>>>
>>>>> I can workaround this problem by calling
>>>>> PhaseGatingImageFilter->Update(),
>>>>> but I think this will break the streaming functionality?  Any easy
>>>>> solutions
>>>>> to this problem that will preserve streaming and let me run the full
>>>>> pipeline with only one Update call?  My guess is I will need to move
>>>>> the
>>>>> geometry subselection to
>>>>> PhaseGatingImageFilter::GenerateOutputInformation()
>>>>> then call UpdateOutputInformation in the main application?
>>>>>
>>>>> Thanks,
>>>>> Geoff
>>>>>
>>>>> ------------------------------------
>>>>> Geoffrey D. Hugo, Ph.D.
>>>>> Associate Professor, Radiation Oncology
>>>>> Director, Medical Physics Graduate Program
>>>>> Virginia Commonwealth University
>>>>> (804) 628 3457
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rtk-users mailing list
>>>>> Rtk-users at public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>>>
>>>> <rtkPhaseGatingImageFilter.txx>
>>>
>>
>> _______________________________________________
>> 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
>
>

-- 
--
Cyril Mory, Post-doc
CREATIS
Leon Berard cancer treatment center
28 rue Laënnec
69373 Lyon cedex 08 FRANCE

Mobile: +33 6 69 46 73 79