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

signal_type "EDS" not understood #19

Open
jlaehne opened this issue Jan 4, 2024 · 2 comments
Open

signal_type "EDS" not understood #19

jlaehne opened this issue Jan 4, 2024 · 2 comments

Comments

@jlaehne
Copy link
Member

jlaehne commented Jan 4, 2024

Loading an MSA file (from EDAX), the signal type is set to EDS, which is not a known signal type as only EDS_SEM and EDS_TEM are available. The MSA files do not contain any information on the type of instrument, but as far as I remember some other readers decide on the basis of the acceleration voltage (>30 kV = TEM, otherwise SEM), which signal_type to use.

Easiest might be to implement the correct signal_type setting in the rsciio reader? Alternatively, we could could try to implement the decision on the exspy side, because it should affect various types of file formats and does not make too much sense to repetitively have that code in different rsciio readers.

Here is the error message:

>>> s2 = hs.load("InGaN_nanowires_spectra.MSA")
WARNING | Hyperspy | `signal_type='EDS'` not understood. See `hs.print_known_signal_types()` for a list of installed signal types or https://github.com/hyperspy/hyperspy-extensions-list for the list of all hyperspy extensions providing signals. (hyperspy.io:707)
@ericpre
Copy link
Member

ericpre commented Jan 4, 2024

Adding a workaround setting signal_type in rosettasciio would be the easiest by adding a shared function (based on the bruker approach) that parse the metadata in the relevant readers.

There are situation where setting the signal_type will be incorrect, because assigning the correct signal class will never be always correct, even the instrument type is known (SEM versus TEM): you can have a thin specimen in a SEM and a thick specimen in a TEM! For the few corner cases, where it doesn't play, the user should set the suitable signal_type manually. Basically, there is not way to get it always right.

xref hyperspy/rosettasciio#37

@sem-geologist
Copy link
Contributor

sem-geologist commented Dec 9, 2024

While I am absolutely against on subdivision of EDS into EDS_SEM and EDS_TEM which brings pain dealing with XRF datasets... (I guess this SEM/TEM subdivision had creeped-in by copying Oxford EDS system options where authors of first Hyperspy iterations were most familiar with...)... however, following their article: https://www.oxinst.com/blogs/what-makes-tem-eds-different-from-sem-eds
I got convinced that maybe guessing the signal types could be achieved much better by checking the elevation angle of detector. SEM will have at least standard 35 degrees and more (actually some EDS can change angle by 5 degrees thus 30 should be the minimum) (some EPMA has 40 (Jeol, Cameca) and even 52.5 degrees (Shimadzu)), where TEM has around 0 degrees. That seems to me much more proper way to deal with it than what I had initially tried to implement by checking primary energy. As for XRF and other methods (i.e. PIXE), probably temporary EDS_SEM should be used....

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

3 participants