[Rtk-users] Conjugate Gradient Artefact

Thu Jun 4 04:28:25 EDT 2015

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
>>>>
>>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cg_coronal.png
Type: image/png
Size: 15979 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cg_axial.png
Type: image/png
Size: 23555 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdk_coronal.png
Type: image/png
Size: 24088 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdk_axial.png
Type: image/png
Size: 48245 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sart_coronal.png
Type: image/png
Size: 32715 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sart_axial.png
Type: image/png
Size: 60626 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150604/0bc6e88e/attachment-0017.png>