-
Notifications
You must be signed in to change notification settings - Fork 13
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
DRAFT get_data method to Components #326
base: master
Are you sure you want to change the base?
Conversation
This pull request introduces 1 alert when merging 5f0d0de into de36732 - view on LGTM.com new alerts:
|
For similar reasons as on the EXtra-geom PR, I don't really like this handling an EXtra-geom geometry object. If you've already got a geometry object, it's easy to call I think the masking options could be added to existing methods like The only awareness of geometry that I think this module should have is inserting fixed sized gaps between tiles within a module (e.g. we know there's a 2 pixel width gap between this column and this one), for looking at single module data, as the goal was on the EXtra-geom PR. This could maybe also be an extra option on the |
Really the reason for me to add that kind of method is because people ask for it, particularly because they find working with the api hard and give up trying.
I have to disagree here. As I've mentioned it here the slight difference in the data for different detectors it can be combersome to apply properly geometry to the data.
This is true that for some detectors (AGIPD/LPD/DSSC) a default isn't really possible, so we could make it mandatory to provide a geometry object for these ones.
There are multimodules detectors with fixed layout (e.g. JUNGFRAU, PNCCD) and this would work for those. It could also handle the different geometry layout for a same detector (e.g. HED has an Epix module with an alternative geometry). |
I added PNCCD and Epix detectors as components, the possibility to mask only selected masking bits and some tests. |
This pull request introduces 2 alerts when merging db15d1a into b45c989 - view on LGTM.com new alerts:
|
I'd still rather leave proper multi-module assembly out of this, and only automatically handle things like putting fixed gaps between ASICs (without using EXtra-geom). I understand that people want a single 'give me the assembled images' function, but assembling parts that can be moved around and aren't necessarily pixel aligned involves decisions that can affect the scientific results (e.g. we're likely to add an option to assemble data with sub-pixel shifts, resulting from our work with DSSC), and I don't think it's unreasonable to expect people to make two calls (load the data and assemble images) for that. Whatever it does, I'm going to ask for a more descriptive name than |
Alternative to #164
This adds a get_data method to components, assembling modules of multimodules detectors and applying (bad pixels and edges) masks.
@takluyver ?