EstimateScatter forces the use of ForwardProjectorByBinUsingProjMatrixByBin for mask computation

[robbietuk]

Attempting to estimate scatter from a CT attenuation map, many small voxels.

This leads to an issue with the ForwardProjectorByBinUsingProjMatrixByBin as

STIR/src/recon_buildblock/DataSymmetriesForBins_PET_CartesianGrid.cxx

Lines 74 to 79 in 454be92

	if (fabs(num_planes_per_scanner_ring_float - num_planes_per_scanner_ring) > 1.E-2)
	error(boost::format("DataSymmetriesForBins_PET_CartesianGrid can currently only support z-grid spacing "
	"equal to the ring spacing of the scanner divided by an integer. Sorry. "
	"(Image z-spacing is %1% and ring spacing is %2%)")
	% image_plane_spacing % proj_data_info_cyl_ptr->get_ring_spacing());
	}

I am generally using parallelproj that avoids this issue elsewhere in the code base (no symmetries) but estimate_scatter forces the use of ForwardProjectorByBinUsingProjMatrixByBin when computing the mask projection data.

STIR/src/scatter_buildblock/ScatterEstimation.cxx

Lines 1238 to 1240 in 454be92

	shared_ptr<ForwardProjectorByBin> forw_projector_sptr;
	shared_ptr<ProjMatrixByBin> PM(new ProjMatrixByBinUsingRayTracing());
	forw_projector_sptr.reset(new ForwardProjectorByBinUsingProjMatrixByBin(PM));

---

Two options

1. Pre-compute and set the mask projdata before setup is called.
2. Add a settable member forward projector shared pointer to the EstimateScatter class.

@KrisThielemans thoughts? Estimate scatter is already complex and convoluted, the second option adds more but simplifies. It can default to the current behavior.

[KrisThielemans]

sure, adding a settable member, also parsable, would be good. It doesn't really increase complexity of the code, so I'd be happy to consider a PR :-)

[KrisThielemans]

Of course, the scatter simulation itself would very much benefit from using parallelproj as well, but that's quite a lot of work. (need to "batch all line integrals up", while currently we do them one by one).