<div dir="ltr"><div>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.<br></div><div>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.<br></div><div>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: <span class="">rtk::Reg23ProjectionGeometry.txx</span>.<br>Again, would you be able to provide a dataset to get some help, that would be much easier for us to help you.<br></div><div>Good luck,<br></div><div>Simon<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 7:17 PM, Notargiacomo Thibault <span dir="ltr"><<a href="mailto:gnthibault@gmail.com" target="_blank">gnthibault@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Chao, and thank you for this detailed answer,<div>If I understand well this sentence:</div><span class=""><div><i><span style="font-size:12.7272720336914px">"</span><span style="font-size:12.7272720336914px">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”."</span></i><br></div></span><div>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.</div><div>But...</div><div>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:</div><span class=""><div><b><i>"<span style="font-size:12.7272720336914px">the projection offset is just the distance from the corner to D"</span></i></b></div><div><br></div></span><div>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.</div><div>This information could help me to determine if my projectionOffset should be negative or positive.</div><div><br></div><div><span style="font-size:12.7272720336914px">About the images geometric data, I tried to use </span>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:</div><div><br></div><div><b>Origin point:</b></div><div><div style="font-size:12.7272720336914px"><span style="font-size:12.7272720336914px">( - half_detector_size_in_mm/2, -half_detector_size_in_mm/2, </span><span style="font-size:12.7272720336914px">-half_detector_size_in_mm/2</span><span style="font-size:12.7272720336914px"> )</span><br></div><div style="font-size:12.7272720336914px"><span style="font-size:12.7272720336914px">the coordinates in Z is a bit odd but why not ?</span></div><div style="font-size:12.7272720336914px"><b>Spacing</b></div><div style="font-size:12.7272720336914px">(detector_pixel_size_in_mm, detector_pixel_size_in_mm, 1 )</div></div><div style="font-size:12.7272720336914px">Direction:</div><div style="font-size:12.7272720336914px">a classic 3*3 identity matrix</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">This is exactly the kind of value I use when importing my images in rtk.</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">Thank you for your time, and help</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">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.</div><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">Kind regards</div><span class="HOEnZb"><font color="#888888"><div style="font-size:12.7272720336914px"><br></div><div style="font-size:12.7272720336914px">Thibault Notargiacomo</div><div style="font-size:12.7272720336914px"><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-12-04 11:57 GMT+01:00 Chao Wu <span dir="ltr"><<a href="mailto:wuchao04@gmail.com" target="_blank">wuchao04@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hoi Thibault,<div><br></div><div><div>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.</div><div><br></div><div>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”.</div><div><br></div><div>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.</div><div><br></div><div>I hope I did not make any mistake in this long description…</div><div><br></div><div>Regards,</div><div>Chao</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2014-12-03 15:27 GMT+01:00 Notargiacomo Thibault <span dir="ltr"><<a href="mailto:gnthibault@gmail.com" target="_blank">gnthibault@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Dear all,<div><br></div><div>I am currently trying to import data generated with a custom tomographic system into RTK, and I am facing issues whith this task.</div><div><br></div><div>The system projection matrix is transparently calibrated, and the calibration process give a 3*4 projection matrix for each acquisition position.</div><div>Each calibration matrix is a direct 3D world to 2D buffer index matrix.</div><div><br></div><div>Using the pinhole model, I tried to factorize this matrix as the product of various submatrix, including a 3D centered Euler transform, using <a href="http://staff.city.ac.uk/~sbbh653/publications/euler.pdf" target="_blank">this note</a> as stated in rtkReg23Geometry.cxx.</div><div>The pinhole camera model I used could be find <a href="http://cauchois.iut-amiens.fr/Recherche/Publi/DEA.pdf" target="_blank">here</a> at p18 of the pdf.</div><div>I think that the way I factorized the matrix is correct, and match the GantryAngle/InPlanAngle/OutOfPlanAngle model described <a href="http://www.openrtk.org/Doxygen/geometry.pdf" target="_blank">here</a> .</div><div><br></div><div>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:</div><div> - a world coordinate system to source centered system matrix (modeling euler 3D rotation and also translation from isocenter to source)</div><div> - a source centered system to 2D buffer index matrix modeling source to detector and pixel size scaling and then detector translation (U0,V0) </div><div><br></div><div>As I understand, the pinhole model should allow a perfect fit with the RTK geometry model in the following sense:</div><div>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.</div><div>So I think it is easy to find all the rotation angle, and the sid distance as well</div><div><br></div><div>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.</div><div><br></div><div>What I do not understand is:</div><div>-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.</div><div>-Why reconstruction aren't working at all</div><div><br></div><div>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).</div><div><br></div><div>Thank you in advance for you help, and sorry for the long mail<img src="cid:ii_i38sgelz0_14a108c1aab5efa5" height="256" width="256"><br></div><div><br></div><div><br></div></div>
<br></div></div><span>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank">Rtk-users@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/rtk-users" target="_blank">http://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com">Rtk-users@public.kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/rtk-users" target="_blank">http://public.kitware.com/mailman/listinfo/rtk-users</a><br>
<br></blockquote></div><br></div>