STIR icon indicating copy to clipboard operation
STIR copied to clipboard

Rotational symmetry tests

Open robbietuk opened this issue 3 years ago • 0 comments

No rotational symmetry tests

As mentioned in https://github.com/UCL/STIR/issues/999#issuecomment-1050071059, there are no rotational symmetry tests run right now because the two implemented scanner configurations have non-zero intrinsic_azimuthal_tilt (related to #181), which disables these symmetries for all tests (even though they are enabled in the tests).


Adding an additional test scanner with 0 intrinsic_azimuthal_tilt

During development of https://github.com/UCL/STIR/pull/1001 I tried adding a new scanner geometry with 0 intrinisic tilt:

      {
        cerr << "Testing scanner with no-tilt\n";
        shared_ptr<Scanner> scanner_sptr(new Scanner(Scanner::Advance));
        proj_data_info_sptr.reset(ProjDataInfo::ProjDataInfoCTI(scanner_sptr,
                /*span=*/2,
                /*max_delta=*/3,
                /*num_views=*/scanner_sptr->get_max_num_views(), // Cannot use view mashing
                /*num_tang_poss=*/5,
                /*arc_corrected*/false));

        check(proj_data_info_sptr->get_scanner_ptr()->get_intrinsic_azimuthal_tilt() < 0.01,
              "Tilt present in the 0 intrinsic_azimuthal_tilt test");
        run_tests_for_1_projdata(proj_data_info_sptr);

      }

This is a scanner with 336 views. This resulted in the following errors. These errors only occured at 112 and 280 views when rotational symmetry was applied.

Error. comparing lors
Current bin: 	segment = 1, 	axial pos 29, 	view = 280, 	tangential_pos_num = 0
Symm bin: 	segment = 1, 	axial pos 29, 	view = 280, 	tangential_pos_num = 0

No Symmetries Iterator || Symmetries Iterator 
                       ||   {61, 3, 2}:0.520858
                       ||   {62, -3, -2}:0.520858
                       ||   {62, 3, 2}:0.520858
                       ||   {63, -3, -2}:0.520858

There are additional coordinates/elements in the in the ProjMatrixElemsForOneBin that used symmetries than the ProjMatrixElemsForOneBin that didn't. In summary, there are small discrepancies between projector matricies when using symmetries and not, but it is partially expected that this is a minor issue.


Investigation

These errors occured at the extemities of the LOR, see above. This is likely due to the start and end positions of the ray trace: https://github.com/UCL/STIR/blob/77ec42303521e3a84d8053d7511d929e06003084/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx#L227-L230 https://github.com/UCL/STIR/blob/77ec42303521e3a84d8053d7511d929e06003084/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx#L158-L162

The suggestion was to set float a = 0; and

const float xmax = stop_point.x();
const float ymax =  stop_point.y();
const float zmax =  stop_point.z();

but we found that this can still introduce issues with the values assigned to the end voxels when symmetries are applied. There is no obvious solution to this issue right now.

robbietuk avatar Feb 25 '22 22:02 robbietuk