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.berg...@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@public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users >
_______________________________________________ Rtk-users mailing list Rtk-users@public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users