[Rtk-users] Geometry import and detector displacement

[Chao Wu]

Hoi Thibault,

Source offset appearing several times is because of a different view of one
kind of detector rotation. A detector can have three kinds of rotations:
the in-plane rotation defined in RTK is about z axis, the out-of-plane
rotation defined in RTK is about x axis, and there should be another
out-of-plane rotation about y axis. Assuming a zero out-of-plane rotation
about x, Fig 1 gives an common example of the rotation about y together
with definitions of sid and sdd in some systems. I guess this figure may be
more familiar and straightforward to some people.

However RTK sees this differently. Since this out-of-plane rotation about y
can be in fact merged into the gantry angle, it is ignored in RTK. On the
other hand, parameters should be defined differently than that in Fig 1 to
represent this detector change, as shown in Fig 2: an “ideal” source is
positioned at B, sid is BE instead of AE, sdd is BD or AC instead of AF,
and AB is the size of the source offset. The origin of the detector is not
at the intersection F with the oblique ray AEF, but at the intersection D
with the perpendicular ray BED from the “ideal” source B. The perpendicular
ray AC from the real source A intersects the detector at C differing from D
by CD or AB, the source offset, which is the reason that you see the source
offset appears again in the projection translation matrix. If the in-plane
rotation of the detector is zero, this source offset only has x element,
otherwise it contains both x and y elements. lastly, the size of projection
offset is the distance between the origin of the projection image and the
origin of the detector (point D). For many “normal” 2D image format the
origin of the image is just at the first pixel (one corner), so the size of
the projection offset is just the distance from the corner to D and has
nothing to do with things like “detector half size”.

In fact the out-of-plane rotation about x has a similar effect in RTK
(causing shifts of source and detector origin, and changes of sid and sdd,
etc. compared with the point of view of the Fig 1 style), although this
angle itself is also needed for rotating the world coordinates.

I hope I did not make any mistake in this long description…

Regards,
Chao


2014-12-03 15:27 GMT+01:00 Notargiacomo Thibault <gnthibault at gmail.com>:

> Dear all,
>
> I am currently trying to import data generated with a custom tomographic
> system into RTK, and I am facing issues whith this task.
>
> The system projection matrix is transparently calibrated, and the
> calibration process give a 3*4 projection matrix for each acquisition
> position.
> Each calibration matrix is a direct 3D world to 2D buffer index matrix.
>
> Using the pinhole model, I tried to factorize this matrix as the product
> of various submatrix, including a 3D centered Euler transform, using this
> note <http://staff.city.ac.uk/~sbbh653/publications/euler.pdf> as stated
> in rtkReg23Geometry.cxx.
> The pinhole camera model I used could be find here
> <http://cauchois.iut-amiens.fr/Recherche/Publi/DEA.pdf> at p18 of the pdf.
> I think that the way I factorized the matrix is correct, and match the
> GantryAngle/InPlanAngle/OutOfPlanAngle model described here
> <http://www.openrtk.org/Doxygen/geometry.pdf> .
>
> My problem arise when I try to model the x/z tilt of the detector: when
> decomposing my projection matrix into different matrix, each modelling a
> system coordinate change, I have:
>     - a world coordinate system to source centered system matrix (modeling
> euler 3D rotation and also translation from isocenter to source)
>     - a source centered system to 2D buffer index matrix modeling source
> to detector and pixel size scaling and then detector translation (U0,V0)
>
> As I understand, the pinhole model should allow a perfect fit with the RTK
> geometry model in the following sense:
> Extrinsinc parameters matrix correspond to the SourceTranslationM and
> RotationM in RTK, assuming that the order of the rotation follows RTK
> reference. And the translation in z should be replaced by zero, as it
> correspond to source-isocenter distance, and is taken into accounts in the
> magnification step.
> So I think it is easy to find all the rotation angle, and the sid distance
> as well
>
> Intrinsics parameters matrix could be decomposed in order to find the
> focal (or source detector distance) and the projection offset, from the U0,
> V0 parameters, substracting the detector half size in each direction.
>
> What I do not understand is:
> -In the rtk documentation, it is stated that "The detector position is
> defined with respect to the source" but the ProjectionTranslationM in rtk
> contains a term in sourceOffsetX-projOffsetX although sourceOffset has
> already been taken into account earlier.
> -Why reconstruction aren't working at all
>
> I enclosed you a sample of geometry file I have generated that provide
> some acceptable result when used for phantom projection, but provide
> totally wrong reconstruction when reconstructing my image data with sart
> (sample image taken from a reconstructed volume).
>
> Thank you in advance for you help, and sorry for the long mail
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20141204/929af3eb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recons_attempt.jpg
Type: image/jpeg
Size: 7162 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20141204/929af3eb/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig1.png
Type: image/png
Size: 4357 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20141204/929af3eb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig2.png
Type: image/png
Size: 6105 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/rtk-users/attachments/20141204/929af3eb/attachment-0001.png>