News:

:) Remember, you need to be logged in to see posted attachments!

Main Menu

JEOL EDS data cube

Started by Ben Buse, March 31, 2026, 04:54:00 AM

Previous topic - Next topic

JonF

Is this a beam scan map and the other maps are stage scan maps? The data cube isn't exactly the same between the two formats.

Ben Buse

Hi Yuji, with the live time code, how do I access the live time map, I ran it, but it just gave me the EDS data as before.

yuji

Hi Ben,

I can open your new data without any errors.
Extra 1 column (position 60 from 0-index, or 61 from 1-index) is included in the dataset.
I think this extra column represents spectrum of beam or stage scanning from one side to the another.
You can see some non-zero signals (a few counts) on the black strip.

I have embedded the real and live time maps into the first 2 energy channels of the spectrum cube.
If you set cursor on the spectrum at channel 1 (0-indexed), you will see the live-time map.
Or you can access these maps directly using the following script.
realtimemap = si[:,:,0]
livetimemap = si[:,:,1]
You cannot view this attachment.

Ben Buse

#18
Thanks Yuji - I'll have another look.

In case it's of interest here's the end product - the calcimage quantification for the EDS, using hyperspy to generate the net intensity, Yuji original code, the bulk map live time, and python to generate the grid files






John Donovan

Quote from: JonF on April 22, 2026, 02:37:09 AMIs this a beam scan map and the other maps are stage scan maps? The data cube isn't exactly the same between the two formats.

Yes.

Beam scan maps are fast scanned in X and slow scanned in Y starting in the upper left corner (like a CRT is displayed).

Stage scan maps are fast scanned in Y and slow scanned in X starting in the upper right corner (like a Japanese newspaper is read).

So the pixel order is different...
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Ben Buse

Hi Yuji,

So looking at the real time and live time data. Real time 10 for all, live time 10 with occasional 0. Is the real and live time stored as a millisecs as integer so decimal is lost? The live and real time for the entire map in the map emsa was 36.59secs and 33.29secs which if we divide by the number of pixels gives 0.01 secs and 0.009secs so 10.16ms and 9.25ms or 9.09ms. And how do you understand the 0 pixels?

yuji

Hi Ben,

I have to explain the .pts file format, which might be a boring topic.
The Hyperspy community has already decrypted this binary format.
https://github.com/hyperspy/hyperspy/pull/2488#issuecomment-756369588
The raw EDS data in a .pts file follows this structure;
P, E00, E01, ..., E0m, Tr, E0m+1, ..., E0n, Tl, E0n+1, ..., E0k, P, E10, E11, E12, ..., E1m', Tr, E1m'+1, ..., Tl, ...
where P denotes the position flag. If the stage or beam moves to the next position, flag P is set.
E is the energy channel of EDS. In your dataset, these values range from 0 to 2048. By calculating the histogram of all E values between two consecutive P flags, we can obtain spectrum for the specific pixel.
Tr and Tl are real and live time stamp. The system inserts these stamps at every 10 msec intervals. By counting the number of these stamps between two P flags, we can determine the total real and live time spent at that pixel.
The time resolution seems to be fixed at 10 msec. I don't think this time resolution can be arbitrarily set by the user.
A live time of 0 indicates that no Tl flags were recorded for that particular pixel. The stage moved to the next position before the live time stamp was inserted.

Ben Buse

#22
Hi Yuji

Sorry I'm still confused, so what do
realtimemap = si[:,:,0]and
livetimemap = si[:,:,1]record?

And how can I get the millisec time from them?

Are they the time in millisec's in which case why does live = real? Is it simply because the counting strategy isn't sensitive enough to distinguish between 9 and 10 millisecs?

If they are not the time in millisecs, how do I find the flag, and count the time?

Thanks


JonF

Hi Ben,

  The confusing thing about the JEOL EDS hypercube is that it is not a hypercube, but a record of events that happen over time e.g. an X-ray arrived, the stage moved in X, a 10msec time interval has passed, an X-ray arrived and so on.

What si[:,:,0] and si[:,:,1] record are the number of 10msec intervals (real and live, respectively) that have occurred at each stage position (i.e. an integer value of 1 is 10msec, 2 is 20msec etc), in other words how many times the 10 msec counter has been recorded before a new stage position counter has been recorded.

What you need to do is create a new float/double array (si in Yuji's script is set as a 16bit unsigned integer) of the same dimensions as the map and set each pixel to 100-(100*(livetime/realtime)) i.e. something like
100-(100*(si[:,:,1]/si[:,:,0]))
which will return the deadtime as a percentage of the realtime (i.e. what you see in the JEOL PC-SEM software).

Regarding the earlier comment that time resolution is too poor, whilst it isn't ideal that it is a 10msec interval, on an EPMA that is actually ok as quant maps are typically running in 100s if not 1000s of msec per pixel. This is particularly advantageous when you've got an SXES detector sat there measuring for 1000s of msec per pixel too...





Ben Buse

Hi Jon,

Thanks for further explanation. I see Yuji in his code has tscale=10, so in the arrays each pixel is recording 1 event or 0 event, because the map was run at 10msec per pixel. Therefore the live/real doesn't make sense. But if the map had been run for a longer dwell time per pixel the number of events for live and real would start to be meaningful.


yuji

Hi,

Thank you for your comment, JonF!
Please note that the time counter does not start or reset when stage/beam moves. If the first pixel takes 9 msec and the second pixel does 12 msec, then the number of the time flags should be 0 and 2 (0 and 20 msec). The second pixel is acquired from 9 to 21 msec, and the time flag is inserted at the time 10 and 20 msec. The actual time of the second pixel is off course 12 msec.

Ben Buse

#26
Ok here's the eds & wds combined.



And input files


Although need to check the quant...

Also need to figure out how to load files into calcimage best.

At moment I'm creating a new blank project in calcimage and then loading each of the files as grd files. Is there a better way of doing this.

I tried loading the wds elements through the create project wizzard. But when I added eds grd files at the end, it said must be added before off peak maps.

JonF

Quote from: Ben Buse on April 27, 2026, 07:10:03 AMOk here's the eds & wds combined.

Although need to check the quant...

Also need to figure out how to load files into calcimage best.

At moment I'm creating a new blank project in calcimage and then loading each of the files as grd files. Is there a better way of doing this.

I tried loading the wds elements through the create project wizzard. But when I added eds grd files at the end, it said must be added before off peak maps.

The totals look quite high at the minute. How are you background correcting the EDS intensities?

For CalcImage, are you doing WDS background maps or MAN backgrounds? I usually use MAN background intensities for WDS maps and load them in using the wizard, then add EDS maps via "Add Images Files to Project (*.GRD)"

John Donovan

#28
Quote from: Ben Buse on April 27, 2026, 07:10:03 AMAlso need to figure out how to load files into calcimage best.

At moment I'm creating a new blank project in calcimage and then loading each of the files as grd files. Is there a better way of doing this.

I can work with you on this, but for now can you use MAN WDS maps as Jon suggests?

Quote from: Ben Buse on April 27, 2026, 07:10:03 AMI tried loading the wds elements through the create project wizzard. But when I added eds grd files at the end, it said must be added before off peak maps.

Yes, that is because the Wizard is looking for PrbImg files to convert to GRD files.  You could possibly create/modify the CalcImage .CIP file to contain all the WDS and EDS GRD files in the proper order.

You've seen this button?

https://smf.probesoftware.com/index.php?topic=1544.msg11942#msg11942

The idea was to query the EDS vendor software to extract net intensity/live time maps for each EDS element. We almost got it all working in Thermo as we needed Thermo to add an API function to obtain the EDS live times per pixel because one needed to extract those manually using the PathFinder application.  Then Thermo bought FEI and dropped all development for EPMA EDS systems...

If you contact me off-line I can share the read/write code for the CalcImage .CIP format with you.
John J. Donovan, Pres. 
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

Ben Buse

#29
Quote from: JonF on April 27, 2026, 08:32:51 AMThe totals look quite high at the minute. How are you background correcting the EDS intensities?


Yes this was using hyperspy integration region and background windows, same windows as used for St John's Olivine, which gave total ~100%. Mainly Si high, Mn perfect, same net intensity as measured on point in PFE. I will need to see about changing regions or using hyperspy model function.

Alternatively I just been playing with the JEOL Test EDS program, generating spectra and requesting net intensity. It uses a asw and sp3 file, does anyone know how to read and write the JEOL asw and sp3 files. Or know the JEOL net intensity alogorithm? Example files attached