Support for laboratory X-ray sources with dual-wavelength (Kα1/Kα2) emission?

[khsacc]

Hi Jérôme and contributors,

pyFAI currently assumes a monochromatic X-ray source and accepts a single wavelength parameter. Laboratory X-ray sources, however, emit characteristic radiation dominated by two closely spaced lines, Kα1 and Kα2, with an intensity ratio of approximately 2:1. When these two wavelengths are integrated assuming a single effective wavelength, peaks at high 2θ become asymmetric and broadened, degrading the quality of downstream analysis (peak fitting, Rietveld refinement, PDF extraction).

Thus, I propose a lightweight, backward-compatible mechanism for pyFAI to handle dual-wavelength lab-source data natively, either as a new integrator class or as an extension of the existing MultiGeometry workflow.

Motivation

While pyFAI is primarily designed for synchrotron use, its fast azimuthal integration is increasingly attractive for laboratory 2D detectors (e.g., Eiger, Pilatus, Dectris HPC detectors used on Rigaku, Bruker, or custom high-pressure DAC setups). In these settings:

• A Kβ filter or multilayer monochromator may suppress Kβ but leaves both Kα lines present.
• The Kα2 contribution is non-negligible and causes peak splitting visible at high angles.
• Users currently must choose between (a) using a weighted mean wavelength (inaccurate at high angles), (b) running two separate integrations and summing (cumbersome), or (c) stripping Kα2 post-integration using external tools.
• It is desired to implement dual-wavelength calibration at the stage of making a poni file.

A native, first-class solution in pyFAI would remove this friction and make pyFAI the natural choice for lab-source 2D diffraction data reduction.

This need arises in our high-pressure X-ray diffraction experiments using laboratory sources. I routinely collect powder diffraction data with Mo Kα radiation on an R-AXIS IV++ imaging plate detector, where pyFAI's integration speed and calibration tools are attractive but Kα2 handling is missing. cf. I also use IPAnalyzer, where we find the same issue.

Proposed approach

I briefly summarise my ideas on how to implement this feature.

We should extend AzimuthalIntegrator (or introduce a thin subclass) to accept a list of (wavelength, weight) pairs. The integration would be performed independently for each wavelength component and the results summed onto a common radial grid with the supplied weights. This is conceptually identical to what MultiGeometry already does across detector positions — the same logic applies to multiple wavelengths on a single detector.

from pyFAI import load

ai = load("calibration.poni")

# proposed API (strawman)
result = ai.integrate1d(
    img, 2000,
    unit="2th_deg",
    wavelengths=[(1.5406e-10, 2.0),   # Kα1, weight 2
                 (1.5444e-10, 1.0)],  # Kα2, weight 1
)

We can also make something like:

from pyFAI.lab_source import integrate1d_lab

result = integrate1d_lab(img, ai, target="Cu", npt=2000, unit="2th_deg")

Also, it is useful to have some common targets, such as:

TARGET_WAVELENGTHS = {
    "Cu": {"Ka1": 1.5406e-10, "Ka2": 1.5444e-10}, 
    "Mo": {"Ka1": 0.7093e-10, "Ka2": 0.7136e-10},
    "Co": {"Ka1": 1.7890e-10, "Ka2": 1.7929e-10},
    "Ag": {"Ka1": 0.5594e-10, "Ka2": 0.5638e-10}
}

Backward compatibility

It is possible to make this update with the existing wavelength scalar parameter / current APIs unchanged. The new wavelengths keyword would be optional and ignored when not supplied. No changes to the .poni file format are required for the initial implementation (the dominant Kα1 wavelength continues to be stored in the poni file; the Kα2 component is supplied at integration time).

Discussion

MultiGeometry already handles multiple geometries with a shared output space — the proposed dual-wavelength integration is a special case of this where geometry is identical but wavelength differs. A lightweight wrapper around MultiGeometry may be sufficient for a first implementation. The unit="q_A^-1" case requires interpolation to a common q grid and is slightly more complex; a first implementation could target 2th_deg only.

Hiroki Kobayashi
The University of Tokyo, hiroki@eqchem.s.u-tokyo.ac.jp

[kif]

Dear Hiroki,

The idea looks great. I did not use a lab source for a couple of decades but I understand the appeal for it.

Technically, the place is ready for hosting a lab-integrator, I don't know yet its name but let's assume it will be something like this.
Recently, Edgar & I implemented many modification to host different integrators (fiber integrator in addition to azimuthal ones). Similarly, the result combination has greatly been enhanced (i.e. result1.union(result2)). Those two features are now readily available.

I helped Tilman Grünwald during his PhD thesis to setup a MultiGeometry to be used with pink-beam with an energy resolved pixilated detector, typically 128x128 pixel each having an energy resolution. It did work (limited by the resolution of the detector).
If your detector is energy resolved, there is no problem, it would just be a 2-energy implemented of what already worked, just a bit better polished. Working in q-space is easier than in angular space, because it has a wavelength dependency on the formula.

But if your detector is not energy resolved, then you need to split your input image, let's call it I = I1 + I2 where I1 and I2 are the signal of the different wavelength. I fear this not a simple deconvolution problem. If you are able to do this, then everything else is (virtually) done.
@pierrepaleo @lesaintjerome Do you know if there are mathematical tools to perform this kind of split ?

• Ratio integrate(I1)/integrate(I2) is known and constant in time & space
• I1 and I2 are homothetic from each other by very little

As you noticed, this issue is usually addressed in Rietveld programs because it is easier to tackle it there ... because it is not trivial to address it directly. Implementing such feature in the 2D image would be much more rewarding. I believe this is a nice subject for a master thesis in Mathematics. Maybe one could even train a convolutional neural network to do it, maybe in an unsupervised manner.

Cheers,

Jérôme