[Rtk-users] Result from SART is worse than from FDK

[Simon Rit]

Hi Andreas,
I apologize for never getting back to you despite the clear
description of the problem. Cyril Mory has done many developments in
iterative reconstruction since your email, including some improvement
of SART. See for example
http://wiki.openrtk.org/index.php/RTK/Examples/ADMMTVReconstruction.

I have launched the three cases you suggested with the "new" SART
- SART reconstruction of middle plane: this cannot work because our
forward projector assumes that the volume goes from the middle of the
first voxel to the middle of the last voxel. Therefore, one plane is
not enough, you need at least two.
- SART reconstruction of 10 planes around middle plane: there is a
truncation problem here and I don't see how it could be solved in this
manner. In general, one needs to use a reconstruction support that is
large enough for the problem at hand (see for example
http://www.ncbi.nlm.nih.gov/pubmed/17441239).
The situation is different if you reduce the data to the
reconstruction of a single plane (with --dimension 256,1 in
rtkprojectgeometricphantom). Then, your 10 slices are sufficient but
the default unmatched forward/back-projector (see
http://www.ncbi.nlm.nih.gov/pubmed/11021698 for a description of this)
give bad results. You can now solve this if you match them with the
option --bp NormalizedJoseph that Cyril has implemented.

So even a better of implementation of SART (the current one) does not
solve the problems that you have pointed out. You need a large enough
CT image given input data to solve the problem. I hope this will be
helpful, maybe not to you if it's too late but to some others.
Simon

On Fri, Dec 20, 2013 at 3:10 PM, Staude, Andreas <andreas.staude at bam.de> wrote:
> Hi Simon,
>
> I believe it really is a problem with the sum of the weights.
>
> I first tried with the Shepp-Logan-phantom and afterwards with my data.
> The geometry is that of a standard cone-beam micro-CT.
>
> The data I posted before were the reconstruction of just the middle
> plane. As I did the same with the Shepp-Logan-phantom data, similar
> effects were seen. As soon as one reconstructs a larger region around
> the middle plane, the artefacts vanish in the inner parts of the
> reconstructed volume, while in the top and bottom parts artefacts remain.
>
> The program calls were:
>
> create geometry:
> ----------------
> rtksimulatedgeometry --nproj="1200" --output="geometry.xml"
> --sdd="1169.59" --sid="451.645" --arc="-360" --first_angle="360"
>
> project the phantom:
> --------------------
> rtkprojectgeometricphantom -g geometry.xml -o projections3.mha --spacing
> 2.5 --dimension 256 --phantomfile SheppLogan.txt
>
> do a reference FDK reconstruction:
> ----------------------------------
> rtkfdk -p . -r projections3.mha -o shepp-logan_fdk3_3D.mha -g
> geometry.xml --spacing 1 --dimension 256
>
> SART reconstruction of middle plane:
> ------------------------------------
> rtksart -p . -r projections3.mha -o shepp-logan_sart3_2D.mha -g
> geometry.xml --spacing 1 --dimension 256,1,256
>
> SART reconstruction of 10 planes around middle plane:
> -------------------------------------------------------
> rtksart -p . -r projections3.mha -o shepp-logan_sart3_2.5D.mha -g
> geometry.xml --spacing 1 --dimension 256,10,256
>
> SART reconstruction of whole object:
> ------------------------------------
> rtksart -p . -r projections3.mha -o shepp-logan_sart3_3D.mha -g
> geometry.xml --spacing 1 --dimension 256
>
>
> Reconstruction of more slices of the real data-set also gave a good
> result. Only the slices near bottom and top are not reconstructed correctly.
>
> So it seems that the normalisation does not only take the values inside
> the reconstructed volume into account, but also (wrong) values outside.
>
> What do you think?
>
> Cheers,
>
> Andreas
>
>
>
> On 11/05/2013 07:11 PM, Simon Rit wrote:
>> Hi Andreas,
>> Thanks for the report. We know that the implementation of SART is
>> imperfect, we haven't been working a lot on it... It seems that you
>> haven't reached convergence. One potential cause is that we use a
>> heuristic for the sum of the weights (denominator in the SART formula)
>> instead of the exact sum. The weight is constant and equals the
>> diagonal of your volume (see line 165 in
>> rtkSARTConeBeamReconstructionFilter.txx). Maybe this is completely
>> wrong in your case. Could you try to increase lambda to see if that
>> helps?
>> To help us do some tests, I would advise you do reproduce your
>> geometry with simulations of the Shepp Logan phantom (see
>> wiki.openrtk.org).
>> Simon
>>
>> On Tue, Nov 5, 2013 at 5:11 PM, Staude, Andreas <andreas.staude at bam.de> wrote:
>>> Hello RTk-users,
>>>
>>> I try to use the SART algorithm, but the results are worse than those
>>> obtained with FDK (see attached images).
>>>
>>> The FDK result looks like expected, so I assume that I have the data
>>> format and the reconstruction geometry set properly. For SART I used the
>>> same parameters and already tried with different values of lambda and
>>> niterations.
>>>
>>> Does anyone have an idea what went wrong? Is there some kind of
>>> smoothing or regularisation applied in the SART implementation?
>>>
>>> Many thanks in advance!
>>>
>>> Cheers,
>>>
>>> Andreas
>>>
>>>
>>> --
>>>
>>> ===============================================================
>>> Dr. Andreas Staude
>>> Fachbereich 8.5 "Mikro-ZfP", Computertomographie
>>> BAM Bundesanstalt für Materialforschung und -prüfung
>>> Unter den Eichen 87
>>> D-12205 Berlin
>>> Germany
>>>
>>> Tel.: ++49 30 8104 4140
>>> Fax:  ++49 30 8104 1837
>>> ===============================================================
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at openrtk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>>>
>
> --
>
> ===============================================================
> Dr. Andreas Staude
> Fachbereich 8.5 "Mikro-ZfP", Computertomographie
> BAM Bundesanstalt für Materialforschung und -prüfung
> Unter den Eichen 87
> D-12205 Berlin
> Germany
>
> Tel.: ++49 30 8104 4140
> Fax:  ++49 30 8104 1837
> ===============================================================