[Rtk-users] Reconstruction from two eccentric short scans

[Simon Rit]

Hi Gabriele,
I ran your line codes. You're projections are not truncated so you can just
work on one acquisition at a time. For the first simulation, I think that
there is not enough data. That's unfortunate that RTK does not issue a
warning, I have opened an issue <https://github.com/SimonRit/RTK/issues/393>.
For the second one, I think that the problem is that RTK detects both a
short scan and a displaced detector. The second weighting can be disabled
with ---nodisplaced and you obtain then an accurate fdk2.mha.
I think it's difficult to combine the two acquisitions because the two
fan-beam are from different source positions... I think your best chance is
to reconstruct each acquisition separately.
Simon

On Fri, Nov 20, 2020 at 10:32 AM <gabriele.belotti.bergamo at gmail.com> wrote:

> Dear Simon & RTK users,
>
> I’m picking up again the two complementary short scan reconstructions as
> this time I’m interested in investigating source offset with panel
> (proj_iso) offsets.
> Early this year, Simon suggested me a clever solution to deal with my
> issue of a complex scan and after that I was able to properly reconstruct
> (see end notes from previous email).
> However, by applying the same logic I get strange results:
>
> rtksimulatedgeometry -v -o geometry_sx_220_600.xml -a 220 -f -110 -n 300
> --sid 1172.2 --sdd 1672.2 --proj_iso_x 60 --source_x 60
>
> rtksimulatedgeometry -v -o geometry_dx_220_600.xml -a -220 -f 110 -n 300
> --sid 1172.2 --sdd 1672.2 --proj_iso_x -60 --source_x -60
>
> rtkprojectshepploganphantom -g geometry_sx_220_600.xml -o proj1.mha
> --dimension 512,3
>
> rtkprojectshepploganphantom -g geometry_dx_220_600.xml -o proj2.mha
> --dimension 512,3
>
> rtkfdk --dimension 256,1,256 -p . -r proj1.mha -o fdk1.mha -g
> geometry_sx_220_600.xml
>
> rtkfdk --dimension 256,1,256 -p . -r proj2.mha -o fdk2.mha -g
> geometry_dx_220_600.xml
>
> plastimatch add --average fdk1.mha fdk2.mha --output fdk.mha
>
>
>
> I used a SheppLogan to recreate my complex acquisition:
> - First rotation (-110 to 110) with a positive shift in source and detector
>
> - Second rotation (110 to -110) with a negative shift in source and
> detector
>
> I tried this with several different images and small changes, but the
> result is pretty much summed up in the attached picture. By comparing a
> standard image with the one I’m reconstructing we can see how the values in
> the top part of the image are lower and those at the bottom are greater
> than the expected values.
> PS: Maybe the shepplogan isn’t the best way to show this, but this way you
> can recreate the issue directly. Using a CT to project and recontruct I’m
> looking up to ±200HU differences
>
> What do you think about this? I was thinking that the PSSF weighting may
> not be suited for this specific condition, but I’m really up looking
> forward for your opinion.
> Extra: To support my instance, I tried to make a comparison between a 360°
> (positive shift in source and detector) reconstruction and one which is a
> sum of two 220° (-110to110to330) reconstructions with the same positive
> offset parameters and I got weird shadowing in the final image.
>
> Thank you in advance!
>
> Best regards,
> Gabriele
>
>
>
>
>
> Thanks. Why not just split the projection stack in two and apply the
> displaced detector filter without modifications on each substack
> separately? Doesn't this work? Here is a sample code with command lines
>
> head -2705 geometry_hf_dual_220_300.xml >rot1.xml
>
> tail -1 geometry_hf_dual_220_300.xml >>rot1.xml
>
>
>
> head -5 geometry_hf_dual_220_300.xml >rot2.xml
>
> tail -2701 geometry_hf_dual_220_300.xml >>rot2.xml
>
>
>
> rtkprojectshepploganphantom -g rot1.xml -o proj1.mha --dimension 512,3
>
> rtkprojectshepploganphantom -g rot2.xml -o proj2.mha --dimension 512,3
>
> rtkfdk --dimension 256,1,256 -p . -r proj1.mha -o fdk1.mha -g rot1.xml
>
> rtkfdk --dimension 256,1,256 -p . -r proj2.mha -o fdk2.mha -g rot2.xml
>
> clitkImageArithm -i fdk1.mha -j fdk2.mha -o fdk.mha
>
> This works perfectly without 1a20fb4
> <https://github.com/SimonRit/RTK/commit/1a20fb42acd640d4c1f7e00fdac226174eb3884e>
> so it seems that this patch is not required. There must be something wrong
> in your input data?
>
> —
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20201204/8591bbe5/attachment-0001.htm>