Regarding 'A new EPMA method for fast trace element analysis in simple matrices'
''The precision errors of the MAN background calibration are smaller than direct background measurement'
Is this implemented in the calculation of the counting time errors (analytical sensitivity) for the maps when using MAN?
Thanks
Ben
Hi Ben,
Great question.
So do we apply the improved MAN statistics to the analytical sensitivity calculation? Assuming you are speaking of the single point/single pixel calculations, the simple answer is no, we only apply the MAN statistics to the detection limit calculation. For the benefit of others, I'm going to detail these considerations, though I'm sure you already know most of this since you've read the paper, which is here for others if interested:
https://pubs.geoscienceworld.org/msa/ammin/article-abstract/101/8/1839/264218/A-new-EPMA-method-for-fast-trace-element-analysis
The reason for this decision (and we are willing to discuss the pros and cons), is that the analytical sensitivity calculation is dominated by the peak to background ratios, while the detection limit calculation is dominated by the variance of the background statistics. So in the analytical sensitivity calculation, as the P/B approaches 1, the square root doesn't change, so I think MAN statistics would have little effect on the analytical sensitivity calculation.
This can be seen is the single point/pixel expressions for both calculations:
(https://smf.probesoftware.com/gallery/1_15_05_19_11_32_50.png)
In fact we don't even display analytical sensitivity calculations for concentrations under 1 wt%. When estimating sensitivity, the detection limit is a more accurate description of trace element sensitivity.
The improved statistics for the MAN background method, results in approximately the same (average) background intensity, but the variance is much lower. So the actual background intensity is roughly the same. What the Scott and Love analytical sensitivity calculation assumes is Gaussian statistics for the background measurement, by taking the square root of the background. The same assumption is made for the detection limit calculation.
And this assumption is correct when the background is measured using the off-peak method, because it is a direct measurement of the continuum intensities. However, the MAN background is instead a regression of the average of many continuum intensities, in standards where the element is not present. So the variance is dependent on two things, first the variance of the *major* elements. Because that variance in the average Z affects the variance of the MAN intensity. And second the magnitude of the average Z, because the intensity of the background usually increases with increasing average Z.
But remember, the MAN regression is not re-measured for each point or pixel. Instead it is generally acquired once per run, and calculated for each point/pixel based on the iterated average Z. If the average Z does not change, then the MAN background intensity does not change for all points/pixels.
In fact the background variance is zero if the average Z is exactly the same. Imagine an MAN calibration curve where the major elements are either specified or by difference, so for example trace Ti in quartz, where Ti is measured and SiO2 is specified or by difference. Whether the SiO2 is specified or by difference, the average atomic number of this material is dominated by the SiO2 concentrations, while the variation of trace Ti will only affect the average Z in the 4th or 5th decimal place.
In other words the MAN background variance is often very close to zero, but depends on whether the matrix (major) elements are measured, or specified by composition or by difference. Since the variances of the peak and background are added in quadrature, the limiting factor of the background variance is the variance of the on-peak measurement. This basically results in an improvement in the MAN detection limit of around 30 to 40%.
So, as mentioned above, we only apply the improved MAN statistics to the detection limit calculation. If you have any ideas on why it would be useful to apply the MAN statistics to the analytical sensitivity calculation I would like to hear them, but remember, we don't display analytical sensitivity for concentrations less than 1 wt%.
Figure 13 in the MAN paper shows the detection limit improvement for MAN backgrounds on a homogeneous synthetic zircon, but a better example might have been using a natural zircon as seen in these images below. As with figure 13, off-peak maps were acquired for the zircon, and utilized in the off-peak quantification, but not utilized in the MAN quantification (normally resulting in an acquisition time half that for off-peak quantification). Here are the off-peak per pixel detection limits:
(https://smf.probesoftware.com/gallery/395_21_04_22_12_01_25.png)
And here are the MAN per pixel detection limits:
(https://smf.probesoftware.com/gallery/395_21_04_22_12_01_09.png)
If you can read the Z labels (just click on the images to make them full size), you can see the off-peak detection limit statistics are significantly worse than the MAN statistics, and the MAN detection limits actually show slightly higher detection limits as the concentration of Hf (a high Z element) increases in the core of the zircon. This is as mentioned above due to the slope of the MAN curve (usually) increasing with increasing average atomic number. Here ZrSiO4 was specified by difference from 100%, so the MAN background variance was very close to zero.
Hope that helps.
Hi John,
Thank you for that detailed explanation of what you do and why.
A further clarification for 'extract polygon areas and/or perform pixel filtering', for the map or a box or a polygon you can extract average composition and std devs or std errs.
Here is this the standard deviation of the average compostion within the box. And for std err this is the standard error on the std dev.
Sorry that doesn't make much sense - what I'm saying is these values are based on the measurements in question and do not use the counting statistic formulas.
Why I'm interested is frequently we do trace element mapping, filter out bad data in calcimage and then extract wide lines using imagej, the question is then on that line profile what is the error bar?
Just come across an interesting plugin for imagej https://imagej.nih.gov/ij/macros/PlotProfileWithSD.txt
Ben
Hi Ben,
I'm not sure I understand exactly what you are getting at.
But let me start by saying that the standard deviation is not the ideal statistic for averaging pixels because it doesn't improve with the number of pixels being averaged. In fact I think it was you (wasn't it?) that asked for the standard error calculation since that improves with the number of pixels being averaged.
QuoteWhy I'm interested is frequently we do trace element mapping, filter out bad data in calcimage and then extract wide lines using imagej, the question is then on that line profile what is the error bar?
If you are modifying the number of pixels in an external program then of course the standard error will change and would need to be re-calculated.
What I do to "filter out bad data" is to use the polygon feature to avoid pits and cracks as described here:
https://smf.probesoftware.com/index.php?topic=877.msg5584#msg5584
Quote from: John Donovan on April 22, 2022, 09:00:16 AM
But let me start by saying that the standard deviation is not the ideal statistic for averaging pixels because it doesn't improve with the number of pixels being averaged.
From what I understand this is because the standard deviation is the variance for each single data point (or pixel), while the standard error is the variance for the average of all points (or pixels).
Therefore when we plot a single point (or pixel), we should utilize the standard deviation, but when we plot the average of the points (or pixels) we should utilize the standard error. Tip: look up standard deviation and standard error in the Probe for EPMA reference manual glossary and this will make sense.
As to why we usually see the average and the standard deviation quoted together, I once asked a statistician this question and they responded: good question, no idea...
Thanks and sorry,
Was just thinking aloud, about the best why to determine the error for a group of pixels in an x-ray map at trace element concentration.
Either put it through the counting statistics formula
Or determine standard deviation and from it calculate standard error.
Then its which is easiest to do for the presented results - in this case a wide line
So modifying
https://imagej.nih.gov/ij/macros/PlotProfileWithSD.txt (https://imagej.nih.gov/ij/macros/PlotProfileWithSD.txt)
and
https://imagej.nih.gov/ij/macros/StackProfilePlot.txt (https://imagej.nih.gov/ij/macros/StackProfilePlot.txt) which I'd previously modified to work with multiple channels rather than slices
Gives a macro that plots a line with an error bar which signifies either the standard deviation or the standard error, of the range of data constituting the line
i.e. its a wide line (data averaged either side of the central line) - with standard deviation or standard error shown
Great :)
So trace element quant maps with holes excluded through filtering in calcimage, then into imagej, plot width averaged line profile, and assign error :)
Hi Ben,
This looks interesting. Thanks for showing us these macros. Also, please feel free to show us an example of the output from this macro.
These line profiles with statistics can also (sort of) be accomplished using the line profile feature in CalcImage, if one selects the standard error output option, and selects the export to file checkbox as shown here:
(https://smf.probesoftware.com/gallery/1_25_04_22_9_27_32.png)
But it outputs a separate file for each area, which looks like this in Excel:
(https://smf.probesoftware.com/gallery/1_25_04_22_9_27_50.png)
This all reminds me of this conversation from three years ago:
https://smf.probesoftware.com/index.php?topic=1144.msg8000#msg8000
In the case of these traces in zircon, it would look like this:
(https://smf.probesoftware.com/gallery/1_25_04_22_9_34_44.png)
And of course now, I realize that one can then export the data from this plot using the Export Data button...
OK, but I just looked at this output file and the concentrations are there but the deviations are all zero, so let me take a look and see if I can fix that today.
Ha! I thought we had a bug but I was wrong! 8)
I had just quickly glanced at the last few columns of data which was for the O, Si and Zr columns, but since I specified ZrSiO4 by difference, and didn't map them, those columns *would* be zero!
Doh!
In fact, the averages and standard deviations or standard errors are correctly exported as shown here:
(https://smf.probesoftware.com/gallery/1_25_04_22_11_27_03.png)
So if one would like to get a wide "strip" of averages for trace elements from a quant map simply use the Export Data button as seen here:
(https://smf.probesoftware.com/gallery/1_25_04_22_11_28_12.png)
That will create a tab delimited ASCII (text) file which can be easily opened in Excel or any graphing program.
The size of the extraction square can be adjusted to get a nice fit of averaging versus spatial resolution as seen here:
(https://smf.probesoftware.com/gallery/1_25_04_22_11_38_17.png)
Remember, these calculated error bars are 1 sigma statistics, so you might want to multiply them by 3 to get 99% statistics...
I've been telling our users to do the line profiles the same way Ben suggests.
My rationale is that in ImageJ, I think the "wide" line profile averages pixels perpendicular to the orientation of the profile line, whereas CalcImage averages pixels in a square around the pixel selected.
For CalcImage, this results in the exported dataset being averaged along the direction of the profile line, causing what would be a sharp boundary to become sigmoidal.
This is a gut feeling though - I've not actually got round to testing ImageJ to make sure it is doing what I think it is!
So here's an example. Data can be filtered in calcimage first to remove holes etc.
1. Create stack of multiple channels - as posted elsewhere https://smf.probesoftware.com/index.php?topic=799.msg9557#msg9557 (https://smf.probesoftware.com/index.php?topic=799.msg9557#msg9557).
(https://smf.probesoftware.com/gallery/453_27_04_22_3_37_39.png)
2. Rotate stack so wide line is horizontal.
(https://smf.probesoftware.com/gallery/453_27_04_22_3_37_59.png)
3. Draw profile box
(https://smf.probesoftware.com/gallery/453_27_04_22_3_38_17.png)
4. Run macro to plot profile with error bars of standard deviation
(https://smf.probesoftware.com/gallery/453_27_04_22_3_38_38.png)
5. Run macro to plot profile with error bars of standard error
(https://smf.probesoftware.com/gallery/453_27_04_22_3_38_56.png)
Left to right is plot. Scale currently in pixels not microns ???
Updated macro scaled
(https://smf.probesoftware.com/gallery/453_27_04_22_4_28_07.png)
Here's the script for standard error
// modified from https://imagej.nih.gov/ij/macros/StackProfilePlot.txt
// StackProfilePlot
// This macro generates profile plots of all the images
// in a stack and stores then in another stack.
macro "Stack profile Plot" {
ymin = 0;
ymax = 255;
saveSettings();
Stack.getDimensions(width,height,channels,slices,frames);
getVoxelSize(vwidth,vheight,vdepth,vunit);
if (channels==1)
exit("Channel Stack required");
// remove comments if wish to fix min and max y scale for all channels
// run("Profile Plot Options...",
// "width=400 height=200 minimum="+ymin+" maximum="+ymax+" fixed");
setBatchMode(true);
stack1 = getImageID;
stack2 = 0;
c = channels+1;
for (l=1; l<c; l++) {
showProgress(l, c);
selectImage(stack1);
Stack.setChannel(l);
errorBarScale = 1;
if (selectionType!=0)
exit("Rectangular selection required");
getSelectionBounds(xbase, ybase, width, height);
profile = newArray(width);
sd = newArray(width);
xprofile = newArray(width);
areaprofile = newArray(width);
n = height;
// print(n);
// print(width);
// print(width*vwidth);
for (x=xbase; x<xbase+width; x++) {
makeRectangle(x, ybase, 1, height);
getStatistics(area, mean, min, max, std);
profile[x-xbase] = mean;
xprofile[x-xbase] = x-xbase;
sd[x-xbase] = std;
areaprofile[x-xbase] = area/vwidth/vwidth;
}
makeRectangle(xbase, ybase, width, height);
run("Clear Results");
for (i=0; i<width; i++) {
setResult("Mean", i, profile[i]);
setResult("Distance", i, xprofile[i]);
setResult("SD", i, sd[i]);
setResult("NumberOfPixels", i, areaprofile[i]);
sd[i] /= sqrt(areaprofile[i]);
xprofile[i] *=vwidth;
}
updateResults;
if (l==1) {
Plot.create("Profile Plot"+l, "X"+vunit, "Wt. %", xprofile, profile);
Plot.add("error bars", xprofile, sd);
} else {
Plot.add("line", xprofile, profile);
Plot.add("error bars", xprofile, sd);
}
// Table.rename("Results", "Results-"+l);
}
Stack.setChannel(1);
setBatchMode(false);
restoreSettings();
}
Rather than rotating the image and drawing a box, could you use the straight line tool to draw a profile line, then double click on the straight line tool icon and specify the line width?
I don't know if drawing the box was a specific requirement of the macro, but could save you some time being able to arbitrarily draw lines rather than rotating the image stack.
(https://smf.probesoftware.com/gallery/796_27_04_22_4_38_30.jpeg)
Hi Jon,
Yes that's what I've previously done to create stack plots, see attached marcos in post https://smf.probesoftware.com/index.php?topic=799.msg9557#msg9557 (https://smf.probesoftware.com/index.php?topic=799.msg9557#msg9557) however no error bar
The difference here is to create the error bar - and adapting someone's macro (https://imagej.nih.gov/ij/macros/PlotProfileWithSD.txt (https://imagej.nih.gov/ij/macros/PlotProfileWithSD.txt)) - the line is then made up of rectangles for which the standard deviation can be returned, from which the standard error can be calculated
Ben
I see what you mean. It's quite annoying that the Profile Plot knows enough to average the data, but not to save all the pixels that it uses in the averaging...
The code for ProfilePlot is on github: https://github.com/imagej/ImageJ/blob/master/ij/gui/ProfilePlot.java
I suspect the information you would need would be in the getWideLineProfile() function.
Confusingly, it looks like "height" might be what we're calling line "width", with the "width" actually being the line length. Argh.
I think it's drawing a series of parallel lines, starting at y=0 and adding all the pixel values along the profile length to profile(i). It then goes to y=1 and adds the new pixel values to the already collected values for each position along the profile line, and so on until y = height ("line width?"). It then divides profile(i) by the height and then spits out the array "profile".
What we need to do is add another array in there to store all the individual pixels in profile(y,i) and then get that spat out, too. Or calculate the SD as part of the script and dump that instead.
From discussion with John:
With regard to standard error of the mean, it may be useful to clarify an underlying implicit assumption: homogeneity.
By taking an average of some data set, the underlying assumption is that the data all belong together (represent a single composition). That is, they are implicitly homogeneous.
And by taking the standard error of the mean, further replication reduces the perceived uncertainty. (Further replication continues to reduce random error, but not systematic error - which will eventually set a limit on such replication).
However, in a natural sample of wide compositional variation, the data are clearly heterogeneous (and should not be averaged together). In this case, the standard deviation of the entire data set is a proxy for the range of the data. And the standard deviation of an individual point represents the X-ray counting statistics that generated that point.
Cheers, Andrew
Quote from: AndrewLocock on March 14, 2024, 09:52:52 AM
And by taking the standard error of the mean, further replication reduces the perceived uncertainty. (Further replication continues to reduce random error, but not systematic error - which will eventually set a limit on such replication).
Andrew brings up a good point here. Clearly one should restrict pixel averaging statistics to single phase domains which appear (at least visually) to be homogeneous.
Unless of course one is attempting to calculate the average composition of a heterogeneous material. In that case one should most definitely average pixels that are already quantified! See here for more on this topic on why "defocused beam" analysis yields inaccurate results:
https://smf.probesoftware.com/index.php?topic=44.0
Meanwhile to see the averaging effects for heterogeneous samples on the standard error statistics I extracted pixels a heterogeneous sample and trying to select the (roughly) same area while increasing the number of pixels in the pixel extraction as seen here:
(https://smf.probesoftware.com/gallery/395_14_03_24_11_14_29.png)
Here are the averaging results using standard error statistics:
Shape extraction number: 1
Pixels shape extracted/filtered: 100
Fe WT%, 79.3341 +/- .706792
Mo WT%, 13.2246 +/- .669886
Cr WT%, 8.86299 +/- .062921
Ni WT%, .021593 +/- .012833
O WT%, -.30588 +/- .027846
Total, 101.137 +/- .275705
Shape extraction number: 2
Pixels shape extracted/filtered: 225
Fe WT%, 78.5930 +/- .476070
Mo WT%, 13.9332 +/- .453728
Cr WT%, 8.86584 +/- .037695
Ni WT%, -.00166 +/- .009303
O WT%, -.31037 +/- .022373
Total, 101.080 +/- .168631
Shape extraction number: 3
Pixels shape extracted/filtered: 400
Fe WT%, 78.5473 +/- .376199
Mo WT%, 14.0504 +/- .358766
Cr WT%, 8.87389 +/- .029576
Ni WT%, .016975 +/- .007130
O WT%, -.30123 +/- .015141
Total, 101.187 +/- .131458
Shape extraction number: 4
Pixels shape extracted/filtered: 625
Fe WT%, 81.5242 +/- .282746
Mo WT%, 10.9013 +/- .267420
Cr WT%, 8.80694 +/- .023563
Ni WT%, .000539 +/- .005664
O WT%, -.28093 +/- .011598
Total, 100.952 +/- .106799
Shape extraction number: 5
Pixels shape extracted/filtered: 900
Fe WT%, 80.3186 +/- .234372
Mo WT%, 12.3108 +/- .224741
Cr WT%, 8.76934 +/- .019332
Ni WT%, .000602 +/- .004625
O WT%, -.28657 +/- .010154
Total, 101.113 +/- .090955
Shape extraction number: 6
Pixels shape extracted/filtered: 1225
Fe WT%, 80.2674 +/- .207730
Mo WT%, 12.1888 +/- .198964
Cr WT%, 8.83089 +/- .016758
Ni WT%, .007073 +/- .003975
O WT%, -.30282 +/- .008717
Total, 100.991 +/- .076728
Seems like this might be worth taking a closer look at? Any comments?