Wish List For CalcImage

[JonF]

Hi,

   Is there any way of importing the JEOL EDS maps in to CalcImage for quantification? Everything works for the point analysis, but CalcImage comes back with the following message when I try to import a spectrum image: "Only Thermo NSS and Pathfinder spectrum image files are supported for integrated WDS and EDS map quantification at this time."

It'd be really great to get the EDS working alongside everything else for quantification 

[John Donovan]

   Is there any way of importing the JEOL EDS maps in to CalcImage for quantification? Everything works for the point analysis, but CalcImage comes back with the following message when I try to import a spectrum image: "Only Thermo NSS and Pathfinder spectrum image files are supported for integrated WDS and EDS map quantification at this time."

It'd be really great to get the EDS working alongside everything else for quantification 

Hi Jon,
I wish for this also!   

Originally we've asked JEOL Japan (on the older 8230/8530 instruments) for the ability to start a synchronized WDS and EDS map, but that never happened.  And now they've moved on to their new MEC (Microscope External Control) interface with the new iSP100/iHP200F instruments.  So we could eventually implement that in the new interface, but we are currently testing the single spectrum acquisition interface for these new instruments. It's a very dense interface and minimal documentation.

But after all this time I think there are other ways forward on the spectrum map front. One way is to figure out the structure of the JEOL EDS spectrum image files, and write code to read the intensities. But that means performing the spectrum deconvolution ourselves.  And normalizing to the live time of each pixel.  That is non-trivial to say the least.

Instead, we now think the best way forward is to ask JEOL for a DLL interface call to read the JEOL acquired EDS spectrum image, and obtain the net intensity maps corrected for the live time of each pixel. There is already an MEC call to obtain spectrum map results, so we are looking at that.  It is not clear if these net intensity maps are normalized to the pixel live times. As I said, the MEC documentation is minimal.

Currently we are in communications with JEOL on this last point.  So don't hold your breath, but maybe something will happen (at least on the new iSP100/iHP200F instruments).

[sem-geologist]

But after all this time I think there are other ways forward on the spectrum map front. One way is to figure out the structure of the JEOL EDS spectrum image files, and write code to read the intensities. But that means performing the spectrum deconvolution ourselves.  And normalizing to the live time of each pixel.  That is non-trivial to say the least.

Whats so wrong in doing deconvolution ourselves (yourself)? Or converting counts to cps? I am pretty sure it is not possible to do deconvolution anyhow worse than OEM implements it or treat the raw data anyhow worse than OEM software does. That is the most bottom line where any attempt to do better will result in better. That is why we had went for such lengths in HyperSpy, where b.t.w. the reader/writter of file formats were recently split into separate python library RosettaSciIO. There are spectral map of jeol and bruker implemented (reverse engineered, but blows away the native Bruker Esprit reader in speed order of magnitude) - thus at least it can be figured out how to read those files. As for live time correction - that depends from implementation of vendor, how it tracks that. At least oxford and Bruker has this nice 0keV peak which tracks the live time, so every spectra in the map has its own encoded live time, other vendors probably contain live time raster.

[John Donovan]

But after all this time I think there are other ways forward on the spectrum map front. One way is to figure out the structure of the JEOL EDS spectrum image files, and write code to read the intensities. But that means performing the spectrum deconvolution ourselves.  And normalizing to the live time of each pixel.  That is non-trivial to say the least.

Whats so wrong in doing deconvolution ourselves (yourself)? Or converting counts to cps? I am pretty sure it is not possible to do deconvolution anyhow worse than OEM implements it or treat the raw data anyhow worse than OEM software does. That is the most bottom line where any attempt to do better will result in better. That is why we had went for such lengths in HyperSpy, where b.t.w. the reader/writter of file formats were recently split into separate python library RosettaSciIO. There are spectral map of jeol and bruker implemented (reverse engineered, but blows away the native Bruker Esprit reader in speed order of magnitude) - thus at least it can be figured out how to read those files. As for live time correction - that depends from implementation of vendor, how it tracks that. At least oxford and Bruker has this nice 0keV peak which tracks the live time, so every spectra in the map has its own encoded live time, other vendors probably contain live time raster.

Nothing is wrong with doing the deconvolution ourselves. But as I said, it's non-trivial.

There are many, many factors to take into account (e.g., detector characteristics) and it is my experience that the various EDS vendors know better than most, in how to treat their own spectra.  We actually hired a mathematical physicist several years ago, who originally claimed: "oh that should be easy", but after several months of effort, they said it was a lot harder than they thought and gave up.

That doesn't mean that it can't also be done by others, but the various EDS vendors already have much of the work done, so it makes sense to leverage that work.