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

Creating a 4-D STEM Feedstock Package #933

Open
CSSFrancis opened this issue May 25, 2023 · 4 comments
Open

Creating a 4-D STEM Feedstock Package #933

CSSFrancis opened this issue May 25, 2023 · 4 comments
Labels
won't fix yet Issues that will be dealt with post 1.0.0

Comments

@CSSFrancis
Copy link
Member

Idea

This has been floated a couple of different times but I think that we should try to develop a 4D STEM feedstock package to handle the numerous methods for operating on each 2-D dataset. Because these operations are embarrassingly parallel the implementations should be uniform across multiple different packages.

Each of these methods can be easily defined as:

def center_of_mass(X, **kwargs):
    """ Finds the center of mass for the 2D array-like object X. Returns X as an array-like object of the 
    same time as X
    """"
    # find the center of mass for X
    return center

From there any package (or user) can use the center_of_mass function to process their code. This directly interfaces with libertems UDF function as well as the hyperspys map function https://github.com/hyperspy/hyperspy/blob/70ca0762a332a7239a4c1eb75001062ab6c7495d/hyperspy/signal.py#L4714C10-L4721

For py4DSTEM a new method would have to be written or it could use either the UDF or map functions to operate.

Before I go to far with this idea I'd love any thoughts or input. I can start creating an outline of how it should be organized and maybe we can go from there?

@bsavitzky @cophus @pc494 @sk1p @uellue @magnunor

@CSSFrancis
Copy link
Member Author

Within pyxem we could easily pull out almost the entirety of the utils folder https://github.com/pyxem/pyxem/tree/main/pyxem/utils and that would be pretty good start. We would have to reorganize some the functions into a more cohesive structure but I was meaning to do that anyways.

It would be good to think about the scope of this. Many things in electron diffraction could fairly easily be applied to x-ray diffraction as well.

@CSSFrancis
Copy link
Member Author

It would be worth thinking about how to handle different array types/ meta-array types as well.

For example: array types would be something like numpy, cupy, and sparse and meta-array's are things like dask, or xarray.

Unfortunately things that depend on scipy or skimage etc. don't have the best support for this kind of context management. This was supposed to be solved by NEP18 and later by NEP35. Additionally uarray is used in certain cases to close the gap.

There are a couple of different ways to do that I think but I'm really not sure if there is a proper way unless we remove scipy and skimage as dependencies. That might be the proper way to go even if it is painful. Already I think that it would be worth it to write a masked cross-correlation function based on https://ieeexplore.ieee.org/document/6111478 which is fast and gpu enabled. This is something that could be extended to an n-dimensional case and used across the board. That would go along way to removing skimage.

There are a bunch of different threads on this:

See:

scipy/scipy#10204
scikit-image/scikit-image#5272

@magnunor
Copy link
Collaborator

So essentially this would be a package which has functions relevant for processing 4D-STEM data. Specifically more of the "back end" functions, for processing individual 4D-STEM (STEM-diffraction) patterns? Ergo, that single "diffraction image" goes in, some output data comes out.

Essentially to avoid duplication between the different packages. On paper, this would be pretty nice, as currently there is quite a lot of unnecessary duplication.

It shouldn't be very difficult to get an alpha version of this up and running, for example by taking the "easy" functions from pyxem/utils and spinning them off into their own package. Maybe initially within https://github.com/pyxem, for the 1.0.0 pyxem release.

@CSSFrancis
Copy link
Member Author

That sounds like a good first step. I might try to take a crack at this next week. I was intending to do some package organization before

So essentially this would be a package which has functions relevant for processing 4D-STEM data. Specifically more of the "back end" functions, for processing individual 4D-STEM (STEM-diffraction) patterns? Ergo, that single "diffraction image" goes in, some output data comes out.

Yea I think there are a couple of different inputs that might be interesting and worth looking at:

I was going to organize it like

  1. SinglePatternUtils
    a. CalibrationUtils
    - Background subtraction and de-noising
    - Direct Beam Finding
    - Direct Beam Centering
    - Determining Elliptical distortions from diffraction patterns
    b. TransformationUtils
    - Azimuthal Integration
    - Angular Correlations (and code for doing masked correlations)
    - Symmetry STEM
    - Center of Mass
    - Diffraction Spot Finding
    c. OrientationUtils
    - Orientation Mapping
  2. SignalAndVectorUtils:
    a. Subpixel_refinement
    b. Virtual_image_creation
  3. 2DVectorUtils:
    a. Filter_from_basis
    b. apply_calibration

I would also like to include things like:
4. 4D VectorUtils (In memory Vector Operations)
a. Clustering vectors in 4 dimensions
b. Strain_Mapping
c. DPC
d. Beam Shift Normalization

And potentially things like:
5. 4-D Methods for data processing
a. Tensor de-noising
b. 4-D Peak and Edge finding etc.

Essentially to avoid duplication between the different packages. On paper, this would be pretty nice, as currently there is quite a lot of unnecessary duplication.

Yea it is kind of one of those things that would be very nice but only as long as people buy in.

It shouldn't be very difficult to get an alpha version of this up and running, for example by taking the "easy" functions from pyxem/utils and spinning them off into their own package. Maybe initially within https://github.com/pyxem, for the 1.0.0 pyxem release.

I was thinking that might be a nice thing to do. My goal is to better define some goals for that next week and push for that relatively soon but it is kind of waiting on the hyperspy 2.0.0 release.

@pc494 pc494 added the won't fix yet Issues that will be dealt with post 1.0.0 label Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
won't fix yet Issues that will be dealt with post 1.0.0
Projects
None yet
Development

No branches or pull requests

3 participants