[Rtk-users] Conjugate Gradient Artefact

Thu Jun 4 05:26:22 EDT 2015

Hi Jonathan,

Thank you for your reply. All these reconstruction results seem normal 
to me.
CG is well known to converge slower, but steadier, than SART. In SART, 
there is a command line option to set the number of projections per 
subset, ie the number of forward projections that are compared to the 
measured ones (and averaged together) between two updates of the volume. 
The default SART behavior is nprojspersubset=1, which results in very 
fast initial convergence, but sometimes leads to erratic behavior after 
a few iterations. Setting nprojspersubset to the total number of 
projections will get you a so-called SIRT reconstruction, which should 
have the same convergence properties as CG (because CG uses all the 
projections at each update).
You can play with this parameter and observe the results. As you 
increase it towards the maximum, you should get
slower but steadier convergence, until you reach SIRT, which looks like 
CG.

Good to know that you managed to get a PICCS implementation quite 
quickly.

Regards,
Cyril

On 2015-06-04 04:28, Jonathan Mason wrote:
> Good morning Cyril,
> 
> I have attached results of reconstructions on the same data with FDK,
> SART and CG. The details of which are as follows:
> 
> FDK --spacing 1.5 --dimension 384 --hann 0.5 --pad 1
> SART --spacing 1.5 --dimension 384 -n 20 --positivity
> CG --spacing 1.5 --dimension 384 -n 30
> 
> The disk artefact does seem to reduce somewhat after a decent amount of
> iterations with CG, but the resulting image is still rather blurry,
> especially compared to the other methods.
> 
> I hope this was insightful, and thanks for your help.
> 
> Cheers,
> 
> Jonathan
> 
> On 03/06/15 11:26, Jonathan Mason wrote:
>> 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
>>>>> 
>>> 