[Rtk-users] Geometry import and detector displacement

[Chao Wu]

see below

2014-12-04 19:17 GMT+01:00 Notargiacomo Thibault <gnthibault at gmail.com>:
>
> Hi Chao, and thank you for this detailed answer,
> If I understand well this sentence:
> "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”."
> The projection offset correspond exactly to the scaled U0,V0 parameters of the intrinsic matrix of the pinhole model, and in my understanding, they should be close to half detector size if all the out of plane rotations are negligible.
> But...
> When I generate a perfect geometry, without out of plane angles, with rtksimulatedgeometry, it appear that projection offsets are set to zero, so I think I have not understood this sentence:
> "the projection offset is just the distance from the corner to D"

The projection offset is the offset of the image origin from the
detector origin (the orthogonal projection of the isocenter on the
detector). For a perfect geometry, rtksimulatedgeometry assumes that
both image origin and detector origin are at the center so the
projection offset is zero. But as I said, in many normal 2D image
format like .png, .tif, and .bmp, the image origin is not defined, and
ITK/RTK uses the first pixel as the image origin. In this case the
size of the projection offset is then the distance between the first
pixel and the detector origin. If the latter is at the detector
centre, the projection offset will be half detector size. The sign
depends on which quadrant of the detector coordinate system the first
pixel sits in.

>
> An other aspect that puzzled my, is that I can't find documentation about what is the orientation of the u axis and v axis of the detector coordinate system (assuming a a 0 gantry angle) regarding the world coordinate system.
> This information could help me to determine if my projectionOffset should be negative or positive.

Without any rotation (gantry and detector), the detector coordinate
system is perfectly aligned with the object coordinate system:
detector_x // object_x, detector_y // object_y, and the detector
origin is the orthogonal projection of the object origin on the
detector plane.

Then, there is another mapping from the image coordinate system to the
detector coordinate system. I have already explained the relationship
between the image origin and the detector origin above. How the image
axis (u and v) orientated with regard to the detector axis (x and y)
depends on the direction cosines of the image. Again, this information
does not exist in many 2D image format and the default value in
ITK/RTK is an identity matrix, so u/v and x/y are also aligned.

>
> About the images geometric data,  I tried to use rtkprojectgeometricphantom with my geometry in order to see what origin, spacing and direction are attributed to the output image, and whithout surprise I experienced the following behaviour:
>
> Origin point:
> ( - half_detector_size_in_mm/2, -half_detector_size_in_mm/2, -half_detector_size_in_mm/2 )
> the coordinates in Z is a bit odd but why not ?
> Spacing
> (detector_pixel_size_in_mm, detector_pixel_size_in_mm, 1 )
> Direction:
> a classic 3*3 identity matrix
>
> This is exactly the kind of value I use when importing my images in rtk.
>
> Thank you for your time, and help
>
> Simon: finding the position of the origin of the detector, and directions, etc... would require to perform the exact same steps of geometric matrix decomposition I already use for the classic RTK geometric parameters plus some more, so I think it would only add complexity and probably useless steps to the process.
>
> Kind regards
>
> Thibault Notargiacomo
>
>
> 2014-12-04 11:57 GMT+01:00 Chao Wu <wuchao04 at gmail.com>:
>>
>> 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 as stated in rtkReg23Geometry.cxx.
>>> The pinhole camera model I used could be find here 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 .
>>>
>>> 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
>>>
>>
>