Probe Software Users Forum

Software => CalcImage => Topic started by: John Donovan on November 20, 2025, 09:10:03 AM

Title: "Crazy" pixels
Post by: John Donovan on November 20, 2025, 09:10:03 AM
Recently we've been working with Probe Image developer Aurelien Moy and beta testers Glenn Poirier and Radek Michallik testing pixel dimension limits for acquisition (and subsequent quantifcation) of very large x-ray maps.

The main issues we are confronting were memory and instrument limitations, but one seemingly unrelated issue is that with so many pixels, we had to limit the pixel dwell times, so these very large maps didn't take too much time to test. And with so many pixels with relatively poor x-ray statistics, the chances of "bad" pixels increases exponentially with x/y dimensions.

Now typically, when performing quantification of x-ray maps, one attempts to acquire decent x-ray statistics in order to obtain good quality maps. Personally I've used pixel dwell times of 100 to 200 millisec or more per pixel with relatively high beam currents for major elements and even longer dwell times and higher currents for minor/trace element mapping:

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

But for these tests we have so many pixels that we didn't want to spend that much acquisition time, so we ran them fast. Which results in many "bad" pixels with poor statistics especially in cracks, voids, etc.  Normally this merely means a few pixels with low totals, which is fine of course, but occasionally the statistics are so bad that the matrix iteration math goes a little "crazy", resulting in a few pixels with very high concentrations, and very rarely even very negative concentrations.

As a reminder, the quantification methods in CalcImage perform all the data correction methods that we utilize for spot analyses, including dead time, background, beam drift, standard intensity drift, matrix effects, spectral interferences, and even TDI (time dependent intensity) corrections when multiple map frames are acquired:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_42_21.png)

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

See also the quant mapping paper attached to this post...

Anyway, when we attempt to quantify these very low sensitivity maps, we can sometimes get what we are now calling "crazy" pixels. Here we can see some low sensitivity x-ray maps after being imported into CalcImage:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_45_45.png)

They don't look too bad, do they? But with 1.6 million pixels what are the chances that a few of them are "crazy"?  :D

Now here after the x-ray map quantification is completed (which takes a while with 1.6 million pixels!):

(https://smf.probesoftware.com/gallery/1_20_11_25_8_46_24.png)

So where is the concentration data?  It's there as one can see from the cursor tracking Z values, but something is wrong. Let's open these maps in the Surfer (or Classify Image Exporter) application:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_51_54.png)

What we see is that the min and max Z data range is way too large. This is caused by these few "crazy" pixels with very poor counting statistics. But by editing the min and max we quickly discover the actual Z range, in this case from around 0 to 3 wt%:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_52_12.png)

The very same applies to using the Classify Image Exporter app, here the raw quantified maps:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_52_30.png)

and here after the Z scale is adjusted:

(https://smf.probesoftware.com/gallery/1_20_11_25_8_52_47.png)

Bottom line: always attempt to acquire decent statistics on your x-ray maps if you intend to quantify them!
Title: Re: "Crazy" pixels
Post by: John Donovan on November 25, 2025, 08:38:39 AM
After further testing of the maximum pixel dimensions as described in the previous post by Radek Michallik and myself, we have some additional observations on the limits of large quant maps.

Currently Probe Image is limited to 2048 x 2048 pixels (~4 million pixels), which we have found CalcImage can perform quantification on such large maps even when 5, 10 or more elements are being quantified.  But we wanted to explore the limits of CalcImage on larger maps (just for fun!).

So Radek acquired a set of 5 maps of 4096 x 4096 pixel dimensions with off-peaks (total of 15 maps), using the JEOL software. Then we were able to convert them into PrbImg files using the conversion app in Probe Image:

https://smf.probesoftware.com/index.php?topic=838.msg13742#msg13742

In CalcImage we were then able to import the 15 PrbImg files, but when we attempted to start the quantification of these 16 million pixels (times 15 maps), we got an "Out of memory" error... even when we converted the analysis to use MAN backgrounds (only 5 maps) it was too much.

So then we decided to cut these maps down a little smaller using the Surfer Grid Extract menu to 3072 x 3072 pixels, so 9 million pixels each, using MAN backgrounds, and that worked:

(https://smf.probesoftware.com/gallery/1_25_11_25_8_03_39.jpeg)

Note that the pixel totals of the large (olivine) phase are very close to 100%, (the multiphase material has some elements missing apparently).

This was using 15 keV, 100nA and 15 millisec per pixel. These 4096 x 4096 maps took about 75 hours to acquire, while the 3072 x 3072 maps took about 17 hours to quant using MAN backgrounds.

But nice that 15 millisec at 100 nA (or no serious cracks or voids?) was enough to eliminate any "crazy pixels"!
Title: Re: "Crazy" pixels
Post by: Les Moore on December 17, 2025, 02:50:21 PM
Harry Buskes once coined the term spurion for a pixel that resets the maximum counts for no real reason.
Also beware if you are ratioing elements as this can generate crazy pixels; as within the analysis pixel, the bkg may be low on one, the counts high in one and low in the other and the result is an incredibly skewed distribution.  Bumping up the total counts helps but you will still have a skewed distribution in a ratio'd or corrected pixel. Note: this is one of the fundamental concerns I have over rapid automated analysis techniques such as ASPEX and its clones.
 
Remember that these are all random variates and any interaction between data sets will only increase the variance in the end map.