[Rtk-users] Geometry import and detector displacement

Thu Dec 4 15:37:16 EST 2014

rtksimulatedgeometry assumes a centered projection so in this case, the
source, center-of-rotation and projection (0,0) points are aligned and
offsets are 0.
The Z coordinate of the origin of the projection stack is not used and
irrelevant. Your observation that it is odd is correct but it's harmless.
I still think that using Reg23 is much simpler than decomposing the matrix
but it's up to you. For example, the directions of the vector of the
projection axes are the lines of your projection matrix if I'm not
mistaking. If you still want to decompose, I think you should have a look
at how Phil did it: rtk::Reg23ProjectionGeometry.txx.
Again, would you be able to provide a dataset to get some help, that would
be much easier for us to help you.
Good luck,
Simon

On Thu, Dec 4, 2014 at 7:17 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> 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"*
>
> 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.
>
> 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 <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
>>>
>>>
>>
>
> _______________________________________________
> 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://public.kitware.com/pipermail/rtk-users/attachments/20141204/78ff44c3/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recons_attempt.jpg
Type: image/jpeg
Size: 7162 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20141204/78ff44c3/attachment-0009.jpg>