Rotational symmetry tests

[robbietuk]

No rotational symmetry tests

As mentioned in #999 (comment), 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 #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:

STIR/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx

Lines 227 to 230 in 77ec423

	// The biggest a? value gives the start of the a-row
	// Note that we should use a=0 if we want to start from start_point
	// (and not from the 'left' edge of the voxel containing start_point)
	float a = max(ax, max(ay,az));

STIR/src/recon_buildblock/RayTraceVoxelsOnCartesianGrid.cxx

Lines 158 to 162 in 77ec423

	// intersection points with intra-voxel planes :
	// find voxel which contains the end_point, and go to its 'right' edge
	const float xmax = round(stop_point.x()) + sign_x*0.5F;
	const float ymax = round(stop_point.y()) + sign_y*0.5F;
	const float zmax = round(stop_point.z()) + sign_z*0.5F;

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.