Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leeds TOR incorrectly Phantom Angle When Phantom ~0deg #325

Closed
randlet opened this issue Nov 20, 2020 · 4 comments
Closed

Leeds TOR incorrectly Phantom Angle When Phantom ~0deg #325

randlet opened this issue Nov 20, 2020 · 4 comments

Comments

@randlet
Copy link
Contributor

randlet commented Nov 20, 2020

Describe the bug
When a Leeds phantom is imaged at roughly 0 deg Pylinac incorrectly determines the phantom angle to be ~350deg.

To Reproduce
Run Leeds Tor analysis (with invert=True) on attached image.

Expected behavior

Angle should be detected as 0deg.

Screenshots

The issue is due to the way the circular profile looks when the phantom is at ~0deg. In this case the peak from the lead square gets split between the left and right half of the profile like this:

leeds-at-zero

A second problem is that the LeedsTOR._is_counterclockwise() function doesn't always work correctly if the roll here produces detected peaks like this:

leeds-peak-roll

A more robust method is to roll by the FWXM idx.

PR Incoming!

randlet added a commit to qatrackplus/pylinac that referenced this issue Nov 20, 2020
Improve phantom orientation determination when phantom is
aligned at 0deg.

Resolves issue jrkerns#325
@randlet
Copy link
Contributor Author

randlet commented Nov 20, 2020

Example file. (txt added to file name so GitHub lets me upload it).
kv-tor18fg-dynrange.dcm.txt

@jrkerns
Copy link
Owner

jrkerns commented Nov 20, 2020

Thanks. Looks like this phantom also must be force-inverted due to the closed blades. I guess I never added an open-blade restriction in the docs. I should add that.

@randlet
Copy link
Contributor Author

randlet commented Nov 20, 2020

Yes, needs to be inverted (as mentioned in the OP!).

@jrkerns jrkerns closed this as completed Nov 20, 2020
@jrkerns
Copy link
Owner

jrkerns commented Nov 20, 2020

Yes, needs to be inverted (as mentioned in the OP!).

You know I don't read issues 🤨

jrkerns added a commit that referenced this issue Jan 9, 2024
RAM-3194 Add nuclear module

Approved-by: Randy Taylor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants