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
blac...@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.
_______________________________________________
Rtk-users mailing list
Rtk-users@public.kitware.com
https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
