[Rtk-users] Reconstruction from two eccentric short scans

gabriele.belotti.bergamo at gmail.com gabriele.belotti.bergamo at gmail.com
Fri Nov 20 04:31:40 EST 2020


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  <https://github.com/SimonRit/RTK/commit/1a20fb42acd640d4c1f7e00fdac226174eb3884e> 1a20fb4 so it seems that this patch is not required. There must be something wrong in your input data?

—



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20201120/eecadc28/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Issue.png
Type: image/png
Size: 330463 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20201120/eecadc28/attachment-0001.png>


More information about the Rtk-users mailing list