Hi Brandon,
Thanks for the detailed report and sorry for the late answer. To be honest,
I'm not sure what is the appropriate fix here and I still haven't found the
time to look into it. Could you please open an issue on github to keep
track of this? You can just copy paste your email in it. Hopefully, someone
will be able to look into it soon...
Cheers,
Simon
On Thu, Apr 28, 2022 at 12:26 AM Brandon LaCava via Rtk-users <
rtk-users@public.kitware.com> wrote:
> 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* <978-540-1680>
> *blac...@mevion.com* <blac...@mevion.com>
> *www.mevion.com* <http://www.mevion.com/>
> 300 Foster Street, Littleton MA 01460
>
>
>
> [image: Facebook] <https://www.facebook.com/MevionMedical>
> [image: Twitter] <https://twitter.com/MevionMedical>
> [image: LinkedIn]
> <https://www.linkedin.com/company/mevion-medical-systems/>
> <https://www.instagram.com/mevionmedicalsystems/>
> 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
>
_______________________________________________
Rtk-users mailing list
Rtk-users@public.kitware.com
https://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
