STIR projector ignores the xy-offset

[ludovicabrusaferri]

There seems to be no difference in the sinogram obtained by forward projecting an image when "first pixel offset (mm) [1]" and "first pixel offset (mm) [2]" are set to different values in the image header file.
Only first pixel offset (mm) [3] seems to affect the result.

[KrisThielemans]

tested with ProjMatrixByBinUsingRayTracing.

main offending code is

STIR/src/recon_buildblock/ProjMatrixByBinUsingRayTracing.cxx

Lines 461 to 466 in 46625f7

	start_point.x() = (s_in_mm*cphi + max_a*sphi)/voxel_size.x();
	start_point.y() = (s_in_mm*sphi - max_a*cphi)/voxel_size.y();
	start_point.z() = (t_in_mm/costheta+offset_in_z - max_a*tantheta)/voxel_size.z();
	stop_point.x() = (s_in_mm*cphi + min_a*sphi)/voxel_size.x();
	stop_point.y() = (s_in_mm*sphi - min_a*cphi)/voxel_size.y();
	stop_point.z() = (t_in_mm/costheta+offset_in_z - min_a*tantheta)/voxel_size.z();

.

This might be fixed in #260, see

STIR/src/recon_buildblock/ProjMatrixByBinUsingRayTracing.cxx

Lines 485 to 488 in 04a2357

	CartesianCoordinate3D<float> start_point
	= get_point_on_lor_in_index_coordinates
	(s_in_mm, m_in_mm+offset_in_z, max_a, cphi, sphi, tantheta,
	density_info, proj_data_info);

and

STIR/src/recon_buildblock/ProjMatrixByBinUsingRayTracing.cxx

Lines 391 to 402 in 04a2357

	CartesianCoordinate3D<float>
	get_point_on_lor_in_index_coordinates
	(const float s_in_mm, const float m_in_mm, const float a_in_mm,
	const float cphi, const float sphi, const float tantheta,
	const DiscretisedDensity<3, float>& density_info,
	const ProjDataInfo& proj_data_info)
	{
	return density_info.get_index_coordinates_for_relative_coordinates
	(proj_data_info.get_relative_coordinates_for_gantry_coordinates
	(proj_data_info.get_point_on_lor_in_gantry_coordinates
	(s_in_mm, m_in_mm, a_in_mm, cphi, sphi, tantheta)));
	}

.
However, the use of relative_coordinates there seems to ignore origin as well. In any case, I cannot remember what the status of that PR is. @ashgillman, do you?

Also, the lines above where min_a and max_a are determined look also wrong (i.e. if you shift the origin, it will still use an effective FOV ignoring the origin shift).

This is not going to be an easy fix I suppose. Other projectors would need to be checked as well.

If #260 isn't ready, we should add a temporary safeguard to throw an error if get_origin().x() and y() are non-zero.

[KrisThielemans]

9ce9940 introduced the safety checks. Now we just need to fix this...