[Rtk-users] rtk::ThreeDCircularProjectionGeometry:: VerifyAngles() epsilon question

Wed Apr 27 22:25:26 UTC 2022

Hi, we're having a slight issue with something in RTK 2.0.1 and are wondering about modifying the epsilon value in rtk::ThreeDCircularProjectionGeometry::VerifyAngles(). This is a bit cumbersome to describe so I'll go slow and kinda walk through it.

We have some software that iterates source/detector positions for DRR generation via the CUDA forward projector.
For certain combinations of source/detector positions/orientations, rtk::ThreeDCircularProjectionGeometry::AddProjection() fails because rtk::ThreeDCircularProjectionGeometry::VerifyAngles() fails and then subsequently rtk::ThreeDCircularProjectionGeometry::FixAngles() also fails. Ultimately, this all ends with a failure to generate our DRR. At first I thought maybe our detector vectors weren't orthonormal or something, but even after orthonormalizing them we get the same result.

Here's some sample inputs to AddProjection():

sourcePosition {-1.6395187023763129, 1756.3965917941700, -144.39815739041538}
detectorPosition {1.1837740829485037, -826.07679772360780, -144.71459973015834}
detectorRowVector {-0.99995122885867527, -0.0010919951074973716, -0.0098179685430691624}
detectorColumnVector {0.0098178296767637476, 0.00013326204342850774, -0.99995181030787128}

Detector normal vector is computed from row and column vectors, and those three vectors become the basis vectors of a 3x3 matrix. So far so good.

n = {0.0010932508471397015, -0.99999943265974056, -0.00012253452211328594}

Matrix is decomposed into angles, which all seem sane enough:

inPlaneAngleRAD = 1.4493613948895230 (83.042290916569541537 deg)
outOfPlaneAngleRAD = -1.5697311129073750 (-89.938967740189397659 deg)
gantryAngleRAD = -1.6824131994857836 (-96.395175727875965777 deg)

Then, inside VerifyAngles() we end up with the following matrices:

m = { {-0.99995124358590692, -0.0010573692766628138, -0.0098179642090855113},
      {0.0098178331830457710, 0.00012903646682954463, -0.99995179558875735},
      {0.0010585851822123655, -0.99999943265974056, -0.00011864910030298149} }

rm = { {-0.99995122885867527, -0.0010919951074973716, -0.0098179685430691624},
       {0.0098178296767637476, 0.00013326204342850774, -0.99995181030787128},
       {0.0010932508471397015, -0.99999943265974056, -0.00012253452211328594} }

But then we fail when comparing the reference matrix with the reconstructed matrix:

  for (int i = 0; i < 3; i++) // check whether matrices match
    for (int j = 0; j < 3; j++)
      if (fabs(rm[i][j] - m[i][j]) > EPSILON)
        return false;

because some of the matrix elements are just a bit unequal by more than EPSILON, which in this case is defined as 1e-5.
For instance, m[0][1] and rm[0][1] differ by 0.0000346258 in magnitude.
Bumping that epsilon up to 1e-4 gets us through the test, and the output seems good.

So finally, the question:
What are the ramifications of us bumping up the epsilon here? It seems like VerifyAngles() is there because the ThreeDCircularProjectionGeometry wants to store the angles for later use, and this is just a sanity check to make sure the extracted angles capture the original vector parameters satisfactorily. If that's true I would expect that a tiny errorin the angles (at around 0.001 to 0.0001) would have a fairly miniscule impact on the actual DRR projection. Is this a valid assumption, or are there potentially more perilous consequences of us upping the epsilon in VerifyAngles() a bit, either to 1e-4 or maybe even 1e-3?

Thanks in advance for any help/insights here.

Cheers,
Brandon

Brandon LaCava
Principal Software Engineer
Mevion Medical Systems
(He/him/his)
Tel: 978-540-1680
blacava at mevion.com
www.mevion.com
300 Foster Street, Littleton MA 01460

This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image226362.png
Type: image/png
Size: 6142 bytes
Desc: image226362.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image633057.png
Type: image/png
Size: 569 bytes
Desc: image633057.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image672602.png
Type: image/png
Size: 484 bytes
Desc: image672602.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image479369.png
Type: image/png
Size: 770 bytes
Desc: image479369.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image876264.png
Type: image/png
Size: 602 bytes
Desc: image876264.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image536526.png
Type: image/png
Size: 10676 bytes
Desc: image536526.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image510036.png
Type: image/png
Size: 838 bytes
Desc: image510036.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image954279.png
Type: image/png
Size: 858 bytes
Desc: image954279.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image134330.png
Type: image/png
Size: 815 bytes
Desc: image134330.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image438258.png
Type: image/png
Size: 1034 bytes
Desc: image438258.png
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20220427/0190f327/attachment-0019.png>