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

[Simon Rit]

Hi,
Yes, this is intentional. FDK requires more than matrices to compute,
e.g., the angular gaps
(http://www.openrtk.org/Doxygen/classrtk_1_1ThreeDCircularProjectionGeometry.html#ae821fb8a5d01b6dd947fc5f8e54cd676).
Just search in the code for where the geometry object is used and
you'll understand.

What you describe is a rtk::ThreeDCircularProjectionGeometry so you
are going to lose more time doing a new geometry file than learning
how to use rtk::ThreeDCircularProjectionGeometry. If you give us some
details and/or an example, we can help you doing the conversion. The
parameters should be very intuitive.
Simon


On Wed, Oct 17, 2012 at 4:25 PM, Lars Friedrich Lars
<lars-friedrich at gmx.net> wrote:
> 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
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at openrtk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users