[Rtk-users] Conjugate Gradient Artefact

Wed Jun 3 06:26:12 EDT 2015

Hi Cyril,

Many thanks for your reply.

I will run a SART and corresponding CG reconstruction tonight for the
artefact. I now have an "empirical implementation" of PICCS using the
SART as you mentioned, and I will attempt to submit it to the toolbox if
I find it successful.

I was pointed towards your paper a while ago and was also surprised by
the performance of PICCS methods for 4D. I will let you know if I find
anything working stronger.

Cheers,

Jonathan
On 02/06/15 19:21, Cyril Mory wrote:
> Hi Jonathan,
>
> Please try to keep the discussions on RTK on the mailing list, so that
> everyone can benefit from the questions and answers.
> About the disk artifact you observe, could you try another iterative
> algorithm, like for example SART (same parameters, only less
> iterations, 4 is sufficient), and let us know whether the same
> artifact is present in your results ? If the artifact is only present
> in the CG result, then I'll have to take a deep dive into the CG code
> and the way the weighting is performed.
>
> Regarding PICCS, many things come to my mind:
> - it mostly depends on the algorithm you would like to use to minimize
> the PICCS cost function. If you want to maximize re-use of available
> RTK code, I recommend you adopt an alternating scheme : minimize the
> data attachment term, then the TV of the volume, then the TV of the
> difference between volume and prior, and repeat. You can do that with
> the SART filter and a TotalVariationDenoisingBPDQ filter. If, on the
> other hand, you want a more theoretically solid minimization
> algorithm, you will need more implementation work
> - that being said, my personal experience with PICCS, on 4D C-arm CT
> of the human heart, was disappointing. If you intend to use PICCS to
> reconstruct either beating heart or free-breathing thorax data, I
> would recommend you try rtkfourdrooster (and maybe read the paper that
> compares ROOSTER with PICCS, called "Cardiac C-arm computed tomography
> using a 3D + time ROI reconstruction method with spatial and temporal
> regularization", http://www.ncbi.nlm.nih.gov/pubmed/24506624)
> - if you do implement PICCS, it would be a valuable addition to RTK,
> so I encourage you to submit it :)
>
> All the best,
> Cyril
>
> On 2015-06-02 09:04, Jonathan Mason wrote:
>> Hi Cyril,
>>
>> Thank you for your response. It indeed seems as though the artefact is
>> due to the geometry mismatch, and I believe it originates from a
>> calibration issue with the machine, so when I get access again I will
>> try to fix this. You are also correct about my blurry reconstruction,
>> and running for a decent number of iterations generates an image more
>> comparable to FDK, though still with the disk present. In the mean time,
>> I have been exploring more of the software package on some synthetic
>> data.
>>
>> I would like to implement a PICCS like reconstruction by incorporating
>> prior image regularisation. What would you recommend the best approach
>> to this task. Would it be possible to realise it with an application
>> calling RTK functions, or would I need to construct new templates for
>> it?
>>
>> Many thanks,
>>
>> Jonathan
>> On 07/05/15 15:25, mory wrote:
>>> Hi Jonathan,
>>>
>>> Welcome to RTK !
>>> The artefact you see is indeed caused by the offset detector, but from
>>> the documentation and the code, it seems that the "displaced detector
>>> filter" should do its job in rtkconjugategradient, so I'm kind of
>>> puzzled.
>>> Your conjugate gradient reconstruction is very blurry. I guess you
>>> used a very small number of iterations. Can you re-run it with 30
>>> iterations and see what happens ?
>>>
>>> Best regards,
>>> Cyril
>>>
>>> On 2015-05-07 14:38, Simon Rit wrote:
>>>> Hi,
>>>> Probably an offset detector artefact. Look at this conversation:
>>>> http://public.kitware.com/pipermail/rtk-users/2015-March/000713.html
>>>> [2]
>>>> Maybe try one of the algorithms that properly uses the offset detector
>>>> filter? For the FOV, the option --displaced will provide the full FOV.
>>>> I hope this helps,
>>>> Simon
>>>>
>>>> On Thu, May 7, 2015 at 1:40 PM, Jonathan Mason <j.mason at ed.ac.uk>
>>>> wrote:
>>>>
>>>>> Hello RTK users,
>>>>>
>>>>> I have been using RTK for a couple of weeks now, and really like
>>>>> the
>>>>> software. The extensive number of tools available is really
>>>>> impressive
>>>>> and helpful, so thanks!
>>>>>
>>>>> I have been experiencing an cylindrical artefact in using conjugate
>>>>> gradient reconstruction — illustrated in the attached images
>>>>> along with
>>>>> FDK with no artefact — of which I am unsure of its origin. The
>>>>> data is a
>>>>> scan of a thorax phantom from a Varian on-board imager. At first I
>>>>> suspected it was due to the specimen extending beyond the
>>>>> reconstruction
>>>>> volume, but extending this unfortunately did not help. Something
>>>>> else I
>>>>> have noticed is that the FOV filter isolates just this pale
>>>>> cylindrical
>>>>> artefact around the centre of rotation.
>>>>>
>>>>> Do you know of the cause of this effect, or how it could be
>>>>> remedied?
>>>>>
>>>>> Best wishes,
>>>>>
>>>>> Jonathan
>>>>>
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>> _______________________________________________
>>>>> Rtk-users mailing list
>>>>> Rtk-users at public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/rtk-users [1]
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://public.kitware.com/mailman/listinfo/rtk-users
>>>> [2]
>>>> http://public.kitware.com/pipermail/rtk-users/2015-March/000713.html
>>>>
>>>> _______________________________________________
>>>> Rtk-users mailing list
>>>> Rtk-users at public.kitware.com
>>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>>
>
>

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.