Probe Pixel Size

[Joe Boesenberg]

Hi All

A question or two about Probe Image. I just started using Probe Image with my JEOL iSP-100. There are many options for pixel size (beam size) from 0.02 to 1000 microns. The microprobe under typical analytical conditions realistically has a beam size around 1-2 microns in diameter. If I choose 0.02 microns for the mapping beam size (pixel size) am I getting any advantage over choosing 1 micron? Is there really a resolution increase?

Final question is how do I update Probe Image to get the incremental updates?

Thanks

Joe

[John Donovan]

A question or two about Probe Image. I just started using Probe Image with my JEOL iSP-100. There are many options for pixel size (beam size) from 0.02 to 1000 microns. The microprobe under typical analytical conditions realistically has a beam size around 1-2 microns in diameter. If I choose 0.02 microns for the mapping beam size (pixel size) am I getting any advantage over choosing 1 micron? Is there really a resolution increase?

Final question is how do I update Probe Image to get the incremental updates?

Short answer is that pixel size has nothing to do with beam size.  Though I can see why one might think they do.

Beam size is defined by the beam focus and the interaction volume physics. Pixel size is basically how much you want to over or under sample the beam size volume.

If you choose a pixel size smaller than your beam you are over sampling, if you choose a pixel size larger than your beam size you are under sampling.

Typically you want to choose a pixel size similar to your beam size, but obviously the emission volume varies with the beam energy and x-ray emission depth.

But sometime one will want to over sample and use a smaller pixel size for small phase statistics for example. There might even be a good reason to under sample, but I can't think of one off hand.

Final question is how do I update Probe Image to get the incremental updates?

Go here:

https://www.probesoftware.com/resources/

Note that we have a new JEOL driver that now allows for x-ray maps larger than 1536 pixels.  Contact us by email directly for the new JEOL driver.

[Les Moore]

Hi guys,
There's another issue here...
The stage scan software takes a time based selection to represent a pixel.
This means that it takes a bit of the previous pixel and a bit of the next pixel depending on the spot size within the pixel.
If you choose the spot size the same as the pixel you will get contribution of about 50% from the pixels in either side.
If you choose a spot spot then you get almost nothing of the adjacent pixels but undersample the pixel.
"What is the truth"
Just one of many choices.
Speaking statistically, the map will be increasingly autocorrelated in the drive direction (X in Cameca) (Y in Jeol).
The good part is the inherent variability in a real sample will stomp out and autocorrelation factors but they could still be there in (in)homogeneous materials.
By this I mean that the variance in the acquisition direction is going to be lower than in the orthogonal direction. If you imagine mapping a sample that looks like graph paper - the variance between pixels on different lines will be greater than the variance between pixels on the same line as these are autocorrelated. 

Have a play in Excel - setup a matrix of 1's and 0's and calculate variances of pseudo spots moved along your sample.
Mercifully unless you are looking at fine compositional issues that have X-Y correlation, the variance due to sample variation will swamp this autocorrelation effect - all things being equal such as S/N   
 

[sem-geologist]

...
The stage scan software takes a time based selection to represent a pixel.
If you choose the spot size the same as the pixel you will get contribution of about 50% from the pixels in either side.
If you choose a spot spot then you get almost nothing of the adjacent pixels but undersample the pixel.
...

What is "the stage scan software"? and how do you know it is a time based selection (what does it mean in your jargon?) Whole EPMA is time based as it runs and is orchestrated by hardware (not software) run by clocks.
Is it some JEOL hardware specific "yet another cutting corners (and costs) case"? Is it in your understanding that motors just run at some continuous speed with continuous rotation, and pixels are interpolated by time-triggered intervals independently from motors? at Cameca EPMA everything is synchronous with clocks, stage moves in (micro-) steps even in "continous" mode (run by clock) and pixel acquisition is triggered practically by exactly same clocks (to be more precise by same clocks which run FPGA - field programmable gate arrays with gateware (which is kind a code describing virtual hardware, it is neither software, neither hardware strictly speeking) which orchestrate all the stage movement and signaling).

Speaking statistically, the map will be increasingly autocorrelated in the drive direction (X in Cameca) (Y in Jeol).

On Cameca EPMA it depends from selected options, if you check "continous mode" or uncheck "continous mode", at least there are these options in OEM Peaksight. In not continous mode acquisition of pixel will start only after stage moved totally fully to the pixel position, thus pixel acquired with spot size similar to pixel size will be dominated with information from that particular pixel. Of course there is secondary fluorescence effects - but these overlap all adjacent (or more precise nearby) pixels in all directions independently from stage moving direction - minus direction of Bragg defocusing of WDS. And then there is "Continous" mode - I have no idea who would and for what reasons would enable and use that...

But Wait, do you mean that counting hardware triggers only start of counting for counter, and does not interrupt counter before stage is moved to the next pixel and sends the next pixel trigger? However, I see no issue with setting particular counter with timeout value - which would be equal to dwell time (just to note: acquisition time is not same to dwell time), so counter would be stopped automatically after equivalent (to the set dwell time) amount of clock cycles passed? So to describe in sequence: counter (for one pixel) would re-start (to 0 counts) by a trigger with rising edge of pixel (X) pulse sent from stage board, and stop counting by timeout internally. Well, at least I would implement the FPGA gateware counter that way as it is most logical, cleanest and easiest way... Acquisition board FPGA clearly has that kind of gateware as it works the same in normal manner when doing normal analytical measurements.

You could see that I completely skipped the WDS board. That is intentional as WDS board sends pulses continuously - it is acquisition board which counts it and makes sense.

It is actually easy to test out If you are right. Your proposed correlation in X direction should diminish with larger dwell times, "continous mode" option unchecked, larger than 1µm step size (it has then fixed time for pixel-to-pixel travel of 50ms, always). If You are right, then with acquisition time of 100ms - 50% of information in pixel will be information adjacent in X direction; with 55ms – only 10% of current position pixel information (90% adjacent in X direction), and with 500ms would give 10% of information of adjacent origin (weakest correlation). Also making very large area map (not high resolution, just with huge stage step) would reveal if last pixel in line keeps accumulating counts while stage goes back to first X position for the next line- that would be hard to miss.

[sem-geologist]

As I gave a bit more thought to this, it gets clear for me that this kind of problem is indeed present on EDS (at least on Bruker hardware), where at low dwell times the map is clearly shifted in X direction compared to BSE image. In that case it is not stage scan as we discuss above, but beam scan and it is on SEM, but the principle is the same. If it is similar behavior on EPMA with stage scanning, that means the calibrations used for spot analysis are not interchangable/usable for quantification of element maps then. And then also pixel information contains not adjecent information in both X direction (behind, ahead) but only behind. So basically that would mean the information in X direction would be smoothed (blured) and shifted. But I somehow doubt that would be the case for Cameca hardware, as if unchecking "continous" option - the total map time is significantly larger, with same set dwell time compared when "continous" option is checked. Also for sure that problem is present on Cameca hardware if using beam scan, and especially video mode. It also explains BSE image shift depending from the scanning speed - where at highest scan speed left edge of picture gets mirror effect from delay of information compared with pixel registration. So if stage scan is affected by this, it is also so that rather left side of mapping should have some visible artifacts, and not the right side.

[Probeman]

One way to avoid these "continuous" mapping artifacts, is mapping using discrete analysis points and then gridding them into a map. Here's some examples that I did way back in the day:

https://smf.probesoftware.com/index.php?topic=60.0

One can also perform random clusters of points in Probe for EPMA and then grid them in Surfer:

https://smf.probesoftware.com/index.php?topic=713.msg4391#msg4391

Though be aware that depending on the point density and gridding method selected (Kriging, etc), there may be artifacts imposed from the gridding process itself.

For exporting your analysis points from Probe for EPMA for subsequent gridding in Surfer or other applications, see here:

https://smf.probesoftware.com/index.php?topic=713.msg12040#msg12040

And for displaying your analysis points on the gridded map in Surfer, see this tutorial from Anette:

https://smf.probesoftware.com/index.php?topic=943.0

The point is that using discrete analysis points will avoid all acquisition artifacts and, although it can be extremely time consuming as SG mentions, it is ideal for trace element mapping. Especially when the stage move time is small compared to the analysis time.  For example, on the trace element maps of Ti in quartz quoted above, the counting time was around 200 sec per point.  I think that acquisition took about a week, but the detection limits were around 5 or 10 PPM!

To further improve sensitivity and halve your acquisition time, be sure to utilize the MAN background method for points or mapping:

https://smf.probesoftware.com/index.php?topic=425.0

https://epmalab.uoregon.edu/publ/A%20new%20EPMA%20method%20for%20fast%20trace%20element%20analysis%20in%20simple%20matrices.pdf