Creation of XRFSpectrum signal type
jat255 opened this issue · 15 comments
There's been enough talk and interest lately from people doing XRF experiments that it seems prudent to create a signal for it, rather than shoe-horning data into the EDSSEM signal type like I've been doing. As I have little experimental experience with XRF, I am not certain of the most important metadata to include, so I'm opening this issue to document the discussion.
Some metadata will overlap greatly with electron-based EDS (WD, TOA, detector time constant etc...) along with some others to add:
x-ray source (e.g. Rh, Mo, Ag);
x-ray source energy (e.g. 10-50 KeV);
x-ray source current (e.g. 100-1000 microA);
filter type/thickness (e.g. Al 12.5 um or compound filters Al 100um-Ti25 um);
Dwell time, or could be expressed as a stage scan speed (e.g. 500 um/s);
NB: These hyperspectral datasets often come with a color image, or frequently a montage, taken of the region of interest analyzed. Which will have scale information different from the x-ray data set.
In term of post-processing how different is it from EDS? In particular, signal measurement (peak fitting or background subtraction) and quantification methods?
Peak fitting is identical, but the nature of the background is modified given the substantially different behavior of electron versus photon scattering in solids.
Here's an example taken from the Wash U micro-XRF website for Poly(methyl methacrylate) that displays the continuum shape for a 45 KeV Rh beam:
Quantification is also different and is performed by the so-called x-ray fundamental parameter method not Phi-Ro-Z, alpha factors, or Cliff-Lorimer analysis. For example:
https://www.rigaku.com/downloads/journal/Vol15.1.1998/sherman.pdf
I am all for such new signal. I want to point out that Bruker system uses same eds and hyperspectral technology saving such data, so it is basically EDS spectra without background. The only difference is that acquisition conditions such as electron beam acceleration, beam current are irrelevant, and should be replaced with X-ray gun parameters.
The Quantification issue is not an outstanding issue here, it is on the same level as TEM vs SEM.
I think, XRF should come as third instrument type: resulting in [EDS_TEM, EDS_SEM, EDS_XRF].
The dwell time and such things are acquisition parameters, and are already dealt with in EDS signal.
NB: These hyperspectral datasets often come with a color image, or frequently a montage, taken of the region of interest analyzed. Which will have scale information different from the x-ray data set.
@EdVice , what do you mean?
I think @EdVice refers to selected XRF lines and specified colors for each line in the mapping inside the Bruker software. These are also stored in BCF files. Selection of multiple lines leads to overlayed colors in the µXRF mapping.
Yes indeed, one can false color image each characteristic (elemental) signal in the x-ray hyperspectral dataset. However, I was referring to the true color CCD camera image mosaic collected by the Bruker M4 before the x-ray data is taken.
Hi,
For synchrotron data and to enable a full set of corrections in future I think you need:
- Additional metadata to define the detector
for attenuation corrections (I have an example of what I use for the detector below) - Additional sample descriptions to define sample matrix or multilayer composition.
- X-ray utils ( escape peaks, pileup peaks, attenuation profiles, material attenuations ) -
create hyperspy.misc.xray to handle this ?)
I've written quite a few XRF bits around hyperspy so it would be useful to put some of it
into this.
Flux and energy are defined so additionally for the detector we need
│ │ ├── gain (keV/ch)
│ │ ├── offset (keV)
│ │ ├── incident_angle (º)
│ │ ├── exit_angle (º)
│ │ ├── detector_distance (mm)
│ │ ├── detector_area (mm)
│ │ ├── detector_type (Si or Ge)
│ │ ├── attenuators ( a dict or materials with thickness,composition)
│ │ │ ├── window
│ │ │ │ ├─ thickness
│ │ │ │ ├─ composition
│ │ │ ├── sensor
│ │ │ │ ├─ thickness
│ │ │ │ ├─ composition
│ │ │ ├── deadlayer
│ │ │ │ ├─ thickness
│ │ │ │ ├─ composition
│ │ │ ├── contacts
│ │ │ │ ├─ thickness
│ │ │ │ ├─ composition
For the sample there can be a matrix or multilayer description
│ ├── matrix
│ └── multilayer *For XRF calculations with thick samples - absorption effects *
@pquinn-dls, the best way to incorporate your efforts into HyperSpy (in case that that's what you want to do) is to split your work into multiple parts and send individual pull requests for each of them (reviewing huge pull requests takes very long...). Even if the code is not yet ready, sending a pull request early on is good to start the discussion on how to best integrate the feature.
@francisco-dlp - I was thinking of progressing this but given the move to split off signals with 2.0 is it worth doing in hyperspy or as a separate package ?
There would basically be 3-4 stages or pull requests
- x-ray physics - calculation of attenuation, compton energies, escape peaks, cross-sections - likely using xraylib
- XRF signal - model build - like EDS but with x-ray physics corrections for peak areas, pileup, escape peaks
3)linear fitting model - calibrations
I think that the best way to go is to create a separate package. The only drawback is that it will be harder to address the hyperspy community from a separate repository. To counteract this you could continue discussing development issues in the hyperspy gitter and hyperspy issues and directly address hyperspy developers individually (or collectively through @hyperspy/developers) in your package's issues.
Although not strictly required, I think that it is good for users to stick to hyperspy conventions when creating a package so that the API is as familiar as possible to users a different packages.
Would it make sense to have this library covering XRF and EDS?
3)linear fitting model
Regarding linear fitting, there is hyperspy/hyperspy#1462, which is stale unfortunately.
Good point, I've just asked @thomasaarholt if he'll have time to finish hyperspy/hyperspy#1462 for v1.6. I'll add it to the check list of v1.6 and to the milestone.
Quick question on what is the status of this? we have a pile of XRF data that we are working with, and while we can import to hyperspy, what signal class should we be using? this is a real question as we can not keep it as a simple signal1D if we want to have peak labels etc