[Rtk-users] deriving from rtk::ProjectionGeometry ...

[Lars Friedrich Lars]

Hi Simon,

we consistently use the projection geometry from reg23 (plastimatch) which is defined by the source position and the detector origin as well as its orientation. In order to become compatible with RTK, I thought that it would be most efficient to define a new projection geometry class by deriving from rtk::ProjectionGeometry<3>; the class should then compute the internal 3x4 matrix using a DLT approach or so and take the reg23 projection geometry. I now recognized that, for example, rtk::FDKConeBeamReconstructionFilter relies on an rtk::ThreeDCircularProjectionGeometry object. Is this by intention? Does the filter essentially require specific props/methods which exclusively defined in rtk::ThreeDCircularProjectionGeometry and which are not available in rtk::ProjectionGeometry<3>? Do I have to compute/imitate more than just the 3x4-matrix?

Thank you.

p