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

Add a method to get the detector centre with sub-pixel accuracy #201

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JamesWrigley
Copy link
Member

Before it was only possible to get the 'snapped' center from geom.position_modules().

BTW I tried testing this with the GenericGeometry class, but it didn't really work because methods like .offset() create a new geometry object that don't include non-class attributes like .pixel_size. Not sure if that's a bug worth fixing.

@JamesWrigley JamesWrigley self-assigned this Jan 24, 2023
@JamesWrigley
Copy link
Member Author

I realized that the function would give beam centers below the bottom left corner the wrong sign, fixed in e32eb7a.

@takluyver
Copy link
Member

We'd need to define where we're giving the centre from.

If it's the centre on a 'snapped' assembled image, then I think the best estimate of the centre depends on the rounding, even if you want a sub-pixel estimate. If the corner you start from snaps with rounding +0.5 but most other modules get rounded -0.5, you'll get a bad estimate of the centre for most of the detector. Maybe we want to find the centre position relative to each snapped module and then average them. 🤔

If it's not related to snapped assembly, then picking another origin is kind of arbitrary. Is it from the first pixel of the data? From the bottom left of the detector? Which left? From the bottom-left-most module corner, or find bottom-most and left-most separately? And so on.

@JamesWrigley
Copy link
Member Author

JamesWrigley commented Jan 24, 2023

Yeah, it's the same as the centre on a assembled image. It's useful is for a function I have from MID to find the beam center, to which the user can give an initial estimate of the center in pixel coordinates (which is easy to make by eye). The code then optimizes the beam center by shifting the geometry around and doing azimuthal integration to check how good the geometry is, and the azimuthal integration geometry is set by using .to_distortion_array(); so it's not that we're losing any accuracy by using pixel coordinates (as long as they have sub-pixel accuracy, hence this PR), that's just the most convenient parameter to optimize.

If it's the centre on a 'snapped' assembled image, then I think the best estimate of the centre depends on the rounding, even if you want a sub-pixel estimate. If the corner you start from snaps with rounding +0.5 but most other modules get rounded -0.5, you'll get a bad estimate of the centre for most of the detector. Maybe we want to find the centre position relative to each snapped module and then average them.

Hmm, sorry I don't really understand this. My understanding is that the detector center is a single point in space from which all other pixel positions are relative to. So, how would geom.centre() give you a bad estimate? Where is the rounding coming from?

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

Successfully merging this pull request may close these issues.

2 participants