Make use of sensor_size in Projector explicit

[maxrohleder]

The Projector class takes the CameraIntrinsicTransform as an argument during construction, which it uses to derive the desired detector resolution.

Later, it is also implicitly used as the intrinsic component of a CameraProjection, when a C-Arm helper class is provided to describe the trajectory. If another approach of projection (without the CArm helper class) is used, then it never used again.

It would be more explicit to instantiate the Projector with a sensor_size parameter, which is used to set the output image size and then explicitly pass the intrinsic to the projection method used with the CArm.

Something like this:

Projector(..., sensor_size = (976, 976))
...
projector.project_over_carm_range(
            (min_phi, max_phi, spacing_phi),
            (min_theta, max_theta, spacing_theta)
            camera_intrinsic)

[mathiasunberath]

We need to think about this a bit because, while the behavior you mention may indeed be undesirable, we also do not want to introduce several ways to initialize/override the same parameters.

[maxrohleder]

I agree! If there shall exist multiple ways of defining the trajectory and projection (e.g. through a CArm object or via matrices in a file) the initialisation of parameters must be clearly separated.

In the latter case, the intrinsic is included in the typical 3x4 matrices that can be found in DICOM projection data, which would be a motivation to supply it as a parameter in the .project() methods and not upon construction of the Projector.

I am currently experimenting (here: https://github.com/maxrohleder/deepdrr/pull/1) on how that would look in the framework. I will let you know when I find a satisfactory solution.

[benjamindkilleen]

Closing this, as these features have since been implemented. See also deepdrr.SimpleDevice for an easily controllable virtual C-arm.