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

Dealing with SEM/HAADF complementary data with their respective luminescence #73

Open
jordiferrero opened this issue Apr 14, 2021 · 4 comments
Labels
type: feature request Asking for additional functionality

Comments

@jordiferrero
Copy link
Contributor

I have recently been wondering on what the best strategy would be to do the following:

All of my CL-SEM data always comes with SE images with it (I suppose for CL-TEM the equivalent would be a HAADF image). These SE images are acquired at the same time as the luminescence. However, they are not integrated with hyperspy at all.
While it is true that you can load the SE image separately (as s) and the use this s object as navigation_axis for the cl object, this all needs to be done manually.
What's worse is that when I do some processing on the cl object (e.g. crop or subindex some of the navigation axes) the s SE image does not link with the cl object in anyway.
Ideally, i would like to link these 2 datasets together.

I have an idea to do that, but I wanted too quickly discuss the approach before I get into the coding.
One way would be to keep the SE image array in the metadata and, every time you apply a certain operation that modifies the navigation axis, then those changes are also applied to the SE metadata (e.g. crop pixels). Moreover, I would like to have an option when plotting where we can specify to use the SE image as navigation axis instead of the default "panchromatic".

Can you think of any better ways to implement such feature?

@ericpre
Copy link
Contributor

ericpre commented Apr 14, 2021

The management of the different signals is taken care by the workflow: the python script or the notebook.

In the case of the navigator, it would be worth considering improving support signal navigator if this is thought in a generic fashion and in a way that it doesn't too much burden to other functions. Maybe it is worth continuing this part of the discussion at hyperspy/hyperspy#2639?

@jordiferrero
Copy link
Contributor Author

So you mean I should stick to keeping track of the changes in the navigation axis of the cl signal and manually applying the same changes to the s SE image file?
That's what I am doing, but I still think there must be a better way...

@jlaehne
Copy link
Contributor

jlaehne commented Apr 14, 2021

@jordiferrero - I understand your point. In principle it applies also for EELS and EDX data and might be of more general interest. Though in many cases the spectral maps will have a lower resolution than proper HAADF or SE images of the same region, and a direct linking of this data is of limited value.

For example, our CL system does not record the SE signal in parallel. I usually have a corresponding SE image taken beforehand and the spectral image corresponds to only a ROI on that image. That SE image usually has a better resolution than the spectral image as I hardly ever use step sizes below 20 nm.

The main issue I see with your approach is that quite a number of functions would need to be adapted directly in hyperspy (e.g. crop, inav, rebin). What you want to do is basically stacking of signals. But I am not sure if stacking two signals with the same navigation dimensions, but different signal dimensions (e.g. 1024 and 1) is possible @ericpre, I do not have enough experience with that function. It might be worth thinking along the lines of adding such a functionality instead of adding an additional signal to the metadata.

@ericpre
Copy link
Contributor

ericpre commented Apr 14, 2021

Indeed, there is room for improvement for the navigator and it would good to discuss how to improve it with others who are interested in this and this is why I put the link to the other issue!

@jordiferrero jordiferrero mentioned this issue Sep 19, 2022
6 tasks
@jordiferrero jordiferrero added the type: feature request Asking for additional functionality label Sep 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request Asking for additional functionality
Projects
None yet
Development

No branches or pull requests

3 participants