Did you know that you can classify your quant maps in CalcImage using any of the available output types (elemental or quant, oxide, atomic, k-ratio, net intensities, and formula basis)?
Here's an example of calculating excess oxygen in magnetite as oxide formulas...
Here's a cool feature that I implemented recently in CalcImage. It's called correlated pixel quantification (CPQ) and the idea is that instead of using the point intensities of standards acquired in the PFE MDB file, one instead acquires standard intensities as x-ray maps, exactly the same as the unknown maps.
Of course one can acquire the standard x-ray maps with different beam currents or pixel dwell times since the program will normalize for those parameters, but depending on what one is trying to correct for this may or may not be desired.
This method was developed for Philippe Pinard and Silvia Richter at Aachen for beam line scans of carbon in steel where the buildup of carbon around the point of acquisition causes the "baseline" of carbon to vary considerably over the length of a beam line scan as seen here:
http://smf.probesoftware.com/index.php?topic=48.msg160#msg160
The idea is that if one acquires the carbon background as an x-ray map with the same acquisition parameters as the unknown x-ray map, the carbon "baseline" variation will be normalized out. Of course there are many other parameters that will affect the rate of carbon buildup such as thermal conductivity and specimen vacuum, but it seems worth trying.
In fact, one can use a mix of MDB standard intensities and simply replace selected standard intensities as required with x-ray maps on standards for on-peak, background or interference standard intensities.
I decided to test this method by acquiring a low mag beam scan map on a pyrite grain and also x-ray maps with the same parameters on the standard to "normalize" out the effects of Bragg defocusing. As one can see from the attached maps it works quite well although the imprecision in areas where the Bragg defocusing is severe, shows slightly greater errors.
Here's a new feature "hot off the press" in CalcImage which now allows one to specify the calculation of detection limit and analytical sensitivity maps from quant x-ray maps.
See attached for an example. Pretty cool! (if I do say so myself!). ;D
Pretty cool indeed! Can you give us the analytical conditions?
Quote from: Julien Allaz on September 06, 2013, 07:51:00 PM
Pretty cool indeed! Can you give us the analytical conditions?
Julien is correct- I accidently used the std count times instead of the x-ray map pixel dwell times for the detection limit and analytical sensitivity calculation. All fixed now! Thanks, Julien!
The conditions were pretty normal: 15 keV, 30 nA, 0.2 seconds per pixel.
And here's an example of the 1 sigma analytical sensitivity output from CalcImage. Note that output is skipped (pixel value set to blanking value) if the concentration is less than 1 wt%. This threshold could be adjusted if necessary (user specified?), but this seems a reasonable default.
The blanked values are shown as "gray" to distinguish them from high precision pixels (idea from Julie Barkman).
OK, here is the mineral end-member quant mapping as requested.
By the way, I doubt that this mineral grain is actually a pyroxene, instead it is very probably an amphibole, but it suffices to demonstrate the method.
Note that pixels which cannot be calculated are "blanked" and appear gray. Please let me know how this works for your lab.
OK, here's a honest to goodness igneous feldspar grain with some interesting zoning, both oxide and end-member basis.
Here is where one can specify all calculation output options in CalcImage (note that elemental quant data is *always* output automatically):
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/11ry7ab.jpg)
Oh, almost forgot, here's the formula maps which of course can be calculated on the basis of any element including the sum of cations.
I should also mention that one can also calculate the stoichiometric oxygen image and the total (sum) image.
This is another output option in CalcImage that I wasn't sure would be useful, but if one is interested in a wide range of concentrations, the log wt% option seems to be useful as seen in these attachments comparing the wt% to log wt% for a banded quartz samples (with nice CL correlation but not from Ti).
But because of a number of higher concentration trace element mineral phases in the sample, the beautiful banding is not visible except in the log wt% output.
Note: I output these originally using the 4 plots per page CalcImage generated script and then combined them into a 5 plot per page by opening the automatically saved SRF files in Surfer and mulching the plot and titles around. To make the second plot I simply saved it to a different name and then just loaded the log wt% GRD files.
Easy!
I have used the log plot capability in CalcImage for looking at poisons in catalyst samples, they show up really well.
This is a fantastic addition that saves adjusting low concentration maps by hand in surfer. :)
Did you know that you can also perform phase classification in CalcImage using lists of quantitative analysis points from Probe for EPMA using this menu?
(https://smf.probesoftware.com/oldpics/i40.tinypic.com/2eo8h8w.jpg)
Then simply import the export file into CalcImage using this menu:
(https://smf.probesoftware.com/oldpics/i40.tinypic.com/2jb40nd.jpg)
The resulting phase numbers are listed in the NK column. Furthermore you can "pre-process" quantitative image data from CalcImage in this window to extract ranges based on the sum of each pixel (to remove pixels of epoxy, etc) as seen here:
(https://smf.probesoftware.com/oldpics/i43.tinypic.com/2qa39lh.jpg)
These are three small but nice features recently added to CalcImage:
1. If you hover the mouse cursor over an image loaded into CalcImage, it will popup a text field that displays the file name, x/y min/max and the image width/height in stage units.
(https://smf.probesoftware.com/oldpics/i43.tinypic.com/24e86xz.jpg)
2. If you load a quant dataset into the Classify Image window, the image size is displayed in microns at the top of the classified image.
(https://smf.probesoftware.com/oldpics/i41.tinypic.com/11j6gx5.jpg)
3. In addition, the image width and height (in microns) are now output to the Surfer plots in the axis labels.
(https://smf.probesoftware.com/oldpics/i44.tinypic.com/x5cm12.jpg)
The CalcImage "Hyper-Cursor" feature now works better than ever- on-line or off-line! It's available from this menu
(https://smf.probesoftware.com/oldpics/i42.tinypic.com/xndoq0.jpg)
You can now correlate all your images and maps based on stage coordinates of, for example, your x-ray maps, phase classification and BSE images as your move the mouse!
(https://smf.probesoftware.com/oldpics/i44.tinypic.com/2my8eu8.jpg)
What is really fancy about this "Hyper-Cursor" feature is that it is *not* dependent on the image stage extents or magnification, because the cursor position is tied to the actual stage position of every pixel in every image.
So as long as the images were all acquired in the same sample exchange, they can all be correlated by actual stage position.
The latest version of CalcImage (v. 10.1.8, 12/15/2013), nicely now handles oxides and excess oxygen output to Surfer.
See attached example of Magnetite analysis using polygon extraction to avoid an inclusion.
And also an example of an oxide element by difference, although the Ce2O3 in this monazite composition is just there for the general matrix correction and assumes no Nd, Sm, etc in the composition. This assumption has been tested and surprisingly, does work well for the U, Th, Pb, Y and La matrix corrections as seen here in some point analyses:
Un 8 Allaz-3
TakeOff = 40.0 KiloVolt = 15.0 Beam Current = 50.0 Beam Size = 5
(Magnification (analytical) = 40000), Beam Mode = Analog Spot
(Magnification (default) = 400, Magnification (imaging) = 800)
Image Shift (X,Y): .00, .00
Number of Data Lines: 9 Number of 'Good' Data Lines: 9
First/Last Date-Time: 10/30/2013 12:04:35 PM to 10/30/2013 01:02:35 PM
WARNING- Using Exponential Off-Peak correction for th ma
Average Total Oxygen: 27.194 Average Total Weight%: 100.000
Average Calculated Oxygen: 27.194 Average Atomic Number: 39.773
Average Excess Oxygen: .000 Average Atomic Weight: 39.299
Average ZAF Iteration: 11.00 Average Quant Iterate: 3.00
Oxygen Calculated by Cation Stoichiometry and Included in the Matrix Correction
Element Ce is Calculated by Difference from 100%
Element P is Calculated .25 Atoms Relative To 1.0 Atom of Oxygen
Un 8 Allaz-3, Results in Elemental Weight Percents
ELEM: U Th Pb Y La Ce P O
TYPE: ANAL ANAL ANAL ANAL ANAL DIFF STOI CALC
BGDS: LIN EXP LIN LIN LIN
TIME: 200.00 200.00 200.00 120.00 120.00
BEAM: 49.82 49.82 49.82 49.82 49.82
ELEM: U Th Pb Y La Ce P O SUM
219 .472 3.341 .567 1.826 9.508 43.870 13.179 27.237 100.000
220 .446 3.334 .524 1.638 9.721 43.952 13.169 27.216 100.000
221 .237 3.150 .424 1.054 9.937 44.893 13.142 27.162 100.000
222 .510 3.582 .581 1.695 9.716 43.555 13.161 27.200 100.000
223 .445 3.923 .599 1.587 9.413 43.725 13.144 27.165 100.000
224 .512 3.290 .558 1.789 9.884 43.557 13.177 27.234 100.000
225 .515 3.329 .573 1.865 9.354 43.944 13.180 27.240 100.000
226 .125 4.790 .400 1.349 8.802 44.278 13.126 27.129 100.000
227 .446 3.816 .595 1.555 9.514 43.764 13.145 27.167 100.000
AVER: .412 3.617 .536 1.595 9.539 43.949 13.158 27.194 100.000
SDEV: .137 .509 .074 .257 .342 .418 .019 .040 .000
SERR: .046 .170 .025 .086 .114 .139 .006 .013
%RSD: 33.28 14.08 13.75 16.13 3.59 .95 .15 .15
STDS: 15 18 386 1016 836 0 0 0
STKF: .8725 .8707 .6861 .4480 .6591 .0000 .0000 .0000
STCT: 137.33 44.30 140.31 38.76 33.08 .00 .00 .00
UNKF: .0035 .0302 .0041 .0116 .0829 .0000 .0000 .0000
UNCT: .55 1.54 .84 1.00 4.16 .00 .00 .00
UNBG: .77 .26 .54 .13 .19 .00 .00 .00
ZCOR: 1.1794 1.1961 1.3069 1.3748 1.1510 .0000 .0000 .0000
KRAW: .0040 .0347 .0060 .0259 .1257 .0000 .0000 .0000
PKBG: 1.71 6.87 2.56 8.82 23.27 .00 .00 .00
INT%: -14.77 ---- -2.38 ---- ---- ---- ---- ----
Un 8 Allaz-3, Results in Oxide Weight Percents
ELEM: UO2 ThO2 PbO Y2O3 La2O3 Ce2O3 P2O5 O SUM
219 .536 3.802 .611 2.319 11.151 51.384 30.198 .000 100.000
220 .506 3.794 .564 2.080 11.401 51.480 30.175 .000 100.000
221 .268 3.585 .457 1.339 11.654 52.582 30.115 .000 100.000
222 .578 4.076 .626 2.153 11.395 51.015 30.157 .000 100.000
223 .504 4.464 .645 2.015 11.040 51.214 30.118 .000 100.000
224 .580 3.744 .601 2.272 11.591 51.018 30.194 .000 100.000
225 .584 3.788 .617 2.368 10.970 51.471 30.201 .000 100.000
226 .142 5.451 .431 1.713 10.323 51.863 30.078 .000 100.000
227 .505 4.342 .641 1.974 11.157 51.260 30.120 .000 100.000
AVER: .467 4.116 .577 2.026 11.187 51.476 30.151 .000 100.000
SDEV: .156 .580 .079 .327 .401 .490 .045 .000 .000
SERR: .052 .193 .026 .109 .134 .163 .015 .000
%RSD: 33.28 14.08 13.75 16.13 3.59 .95 .15 375.00
STDS: 15 18 386 1016 836 0 0 0
Un 8 Allaz-3, Results in Millions of Years Ago, EPMA Age (from U, Th, Pb)
U WT% Th WT% Pb WT% U PPM Th PPM Pb PPM Age[My] Calc Pb %Pb(Th) %Pb(U)
219 .472289 3.34109 .567045 4722.89 33410.9 5670.45 2323.00 5670.27 64.3415 35.6635
220 .446398 3.33429 .523589 4463.98 33342.9 5235.90 2208.20 5236.10 65.9074 34.0874
221 .236642 3.15039 .424494 2366.42 31503.9 4244.94 2226.00 4245.02 77.4650 22.5299
222 .509558 3.58221 .581436 5095.58 35822.1 5814.36 2231.20 5814.52 64.4655 35.5293
223 .444676 3.92270 .598909 4446.76 39227.0 5989.09 2258.10 5989.38 69.4054 30.5896
224 .511685 3.28988 .557768 5116.85 32898.8 5577.68 2252.20 5577.78 62.3314 37.6634
225 .515049 3.32893 .572963 5150.49 33289.3 5729.63 2285.30 5729.68 62.3537 37.6412
226 .124814 4.79049 .399875 1248.14 47904.9 3998.75 1650.30 3998.89 91.3724 8.62120
227 .445556 3.81612 .594983 4455.56 38161.2 5949.83 2281.40 5949.84 68.7099 31.2850
AVER: .411852 3.61734 .535674 4118.52 36173.4 5356.74 2190.63 5356.83 69.5947 30.4012
SDEV: .137073 .509306 .073673 1370.73 5093.06 736.728 205.618 736.721 9.41884 9.41990
CalcImage now supports output for all quant types (detection limits, analytical sensitivity, log wt.%, mineral end members and U-Th-Pb chem age calculations), for polygon, slice and strip operations.
(https://smf.probesoftware.com/oldpics/i39.tinypic.com/n5kaqu.jpg)
See attached for examples.
Here's another example (attached) using the U-Th-U age with a polygon extraction to get a more accurate average and variance.
Note that the inclusion was not included in the calculation, just the area inside the polygon!
Also the output was generated completely automatically, no manual modifications to the graphical objects!
A new feature if your match database (e.g., DHZ.MDB) contains accurate densities for each composition (available in v. 10.1.9 of PFE), is the Mass% for each phase as shown here in this output from CalcImage of a field of view of Mt St. Helens basalt.
See attached.
I think I forgot to describe our CalcImage "strip averaging" of intensity or quant maps using horizontal or vertical strips in um units.
This means the user can take an x-ray map and specify the application average the pixel rows or pixel columns to obtain an average of the sample either vertically or horizontally as seen here:
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/othfnt.jpg)
One can now calculate and output statistics for all raw and/or quant x-ray maps with a couple of mouse clicks using this new menu:
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/oa83z6.jpg)
Note the Project | Output Image Statistics For menu names have now been modified slightly from what you see above...
Here is an example of elemental results for a magnetite standard x-ray map. Note that the average measured and excess oxygen are both properly output:
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/wl9e1w.jpg)
And here is an example of calculating the average detection limit for an alloy x-ray map using a short (200 msec, 30 nA) dwell time per pixel:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/2w7qr5x.jpg)
I should also mention that at this point it would be *very easy* to add additional image statistics calculations if there are any that you all think would be useful!
See this post on how to edit the sample title output to your presentation images:
http://smf.probesoftware.com/index.php?topic=40.msg1419#msg1419
Another example attached below.
We've managed to implement the "aggregate" photon method into CalcImage for all quant operations.
This is response to Aoife McFadden's report here:
http://smf.probesoftware.com/index.php?topic=393.0
and Anette von der Handt's report here:
http://smf.probesoftware.com/index.php?topic=383.0
that this feature seemed to be missing and indeed it was (previously one could only apply the "aggregate" photon method to point analyses in Probe for EPMA, but now one can apply this "aggregate" method for improving sensitivity in CalcImage for x-ray maps! 8)
Using Aoife's data as an example here is a comparison of the S and Sr background intensity maps with and without the aggregate option applied to the same data (please note that I'm only showing the single spectro 1 for the "normal" quant as that is the channel everything gets "aggregated" to when the aggregate method is applied). This is simply to demonstrate that the aggregated background intensity pixels are higher in intensity because they are summed at the photon level).
For Sr la:
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/20rlklc.jpg)
For S Ka:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/2w3q32e.jpg)
I think you will also agree that the "aggregated" background intensity maps (on the right side) appear to be less noisy (and of course they should!).
And here are the calculated 3 sigma detection limits (for just the Sr La) to show that the detection limits really are better for the "aggregated" intensities:
(https://smf.probesoftware.com/oldpics/i58.tinypic.com/mhwmjk.jpg)
Finally here is a page from the presentation output for the normal quant:
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/260pcph.jpg)
and here is the single page output for the "aggregated" photon intensities quantified:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/mjwlm0.jpg)
I think everyone will agree that the "aggregated" quant maps for Sr and S are better sensitivity both visually and numerically (as seen by comparing the range of z values in the color scale bar).
Quote from: John Donovan on December 25, 2014, 04:35:02 PM
I've managed to implement the "aggregate" photon method into CalcImage for all quant operations.
I just realized that the above post "starts in the middle", so I should explain a little first. Here is Aoife's elemental setup in PFE for her probe run:
Last (Current) On and Off Peak Count Times:
ELEM: S ka S ka S ka S ka S ka Ca ka Sr la Sr la Sr la Sr la
BGD: MAN MAN MAN MAN MAN MAN MAN MAN MAN MAN
BGDS: MAN MAN MAN MAN MAN MAN MAN MAN MAN MAN
SPEC: 1 2 3 4 5 3 1 2 4 5
CRYST: LPET PET LPET LPET LPET LPET LPET PET LPET LPET
ORDER: 1 1 1 1 1 2 2 2 2 2
ONTIM: 15.00 15.00 15.00 15.00 15.00 15.00 15.00 15.00 15.00 15.00
So there are 5 spectrometers tuned to S Ka, one for Ca Ka and 4 for Sr La. Now here is her data calculated for each spectrometer (normal analysis with totals image not shown):
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/2mpbsrk.jpg)
Now we simply turn on the "aggregate intensity" feature as seen here:
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/2zdni88.jpg)
And now, here is her same data, but this time re-calculated with the "aggregate" intensity feature (again without the totals image):
(https://smf.probesoftware.com/oldpics/i58.tinypic.com/2h55r1c.jpg)
8)
This is a nice new feature in CalcImage that allows one to output all of the currently open images to Grapher for presentation output. Start by opening only the images you want to export using the Project | Open Images For Current Project or File | Open GRD File menus.
Then click the new Window | Output The Currently Displayed Images menu as seen here:
(https://smf.probesoftware.com/oldpics/i62.tinypic.com/28cd6xc.jpg)
This nice thing is one can display all sorts of data types all at once, for example this one of Mo atomic%, weight%, analytical sensitivity and detections limits:
(https://smf.probesoftware.com/oldpics/i61.tinypic.com/23vns02.jpg)
Note this works for any number of images displayed, as the Surfer script will auto-generate the additional pages as necessary.
When we get Thermo and Bruker on board with this:
http://smf.probesoftware.com/index.php?topic=400.msg2174#msg2174
Then I will enable these controls in CalcImage for true, full featured EDS-Si and WDS quant integration:
(https://smf.probesoftware.com/oldpics/i59.tinypic.com/zkn4mw.jpg)
Cool!
The Copy To Clipboard and Save as BMP (24 bit RGB) buttons are now working:
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/2ajz950.jpg)
Download ver. 10.7.8 of PFE when ready.
Quote from: John Donovan on October 04, 2013, 07:00:11 PM
Did you know that you can also perform phase classification in CalcImage using lists of quantitative analysis points from Probe for EPMA using this menu?
(https://smf.probesoftware.com/oldpics/i40.tinypic.com/2eo8h8w.jpg)
Then simply import the export file into CalcImage using this menu:
(https://smf.probesoftware.com/oldpics/i40.tinypic.com/2jb40nd.jpg)
The resulting phase numbers are listed in the NK column. Furthermore you can "pre-process" quantitative image data from CalcImage in this window to extract ranges based on the sum of each pixel (to remove pixels of epoxy, etc) as seen here:
(https://smf.probesoftware.com/oldpics/i43.tinypic.com/2qa39lh.jpg)
I'm bumping this forward to remind you all that you can perform kmeans clustering on random points exported from PFE for both WDS *and* EDS elements now. All data types too- raw, net intensities, elemental wt%, atomic, oxide, detection limits, log wt%, etc. etc.
john
Here's a useful new feature in CalcImage...
Open some images in CalcImage and open the Log Window from the Window menu and click the Calculate Currently Displayed Image Statistics menu and you will get the average and standard deviation of all images as see here:
(https://smf.probesoftware.com/oldpics/i57.tinypic.com/24cgu9z.jpg)
I have a data acquisition request for our JEOL ProbeImage/CalcImage colleagues... but first some background.
As many of you already know, Probe for EPMA contains a very robust drift correction not only for beam current drift, but also for standard intensity drift. This beam current drift correction is commonly performed by other softwares, but the automatic standard intensity drift correction is unique to PFE, and allows the software to correct for changes in the measured standard intensities over time, on an element by element basis. That is, assuming that you acquired your standard(s) both before *and* after your unknown point acquisitions!
Now I have fully implemented this beam current and standard intensity drift correction in CalcImage for our x-ray mapping quantification. The beam current drift correction was already implemented in CalcImage but now, the standard intensity drift correction is also implemented. This standard intensity drift correction is a totally unique feature in both PFE and now, CalcImage, and it works amazingly well.
And because the standard intensity drift correction is performed on an element by element basis, it can deal with temperature related drift issues such as the thermal sensitivity of the PET crystals.
I also implemented the new CalcImage drift correction code so it automatically handles the situation where there is more than one x-ray map acquisition set for the quantification. That is, more than one element per spectrometer were acquired in Probe Image, using multiple sample acquisitions on the same area.
Cool.
So now I would like to obtain a small test dataset (MDB and PrbImg files) from a JEOL instrument (you'll see why in a second), on a homogeneous standard sample, for both a beam scan and a stage scan. Just 3 to 5 elements, and no need to acquire off-peak maps as I would like to test the MAN drift correction as well, so please also acquire the primary standards and the MAN stds in PFE, both *before* the x-ray maps are run, and again *after* the x-ray maps are acquired.
Ideally this would be an overnight mapping run where you observe significant drift in either or both the beam current and/or the standard intensities. A lab with significant temperature variation would be ideal.
Hopefully the beam current and standard intensity drifts are linear because all we can do is interpolate linearly between standardizations...
Now, why do I want only JEOL MDB and map data? Well because I'm calculating the drift by assuming the first pixel acquired is in the upper left of the map and the last pixel acquired is in the lower right. This exactly the case for all Cameca beam and stage scans, but is only the case for the JEOL beams scans. As you may know, JEOL stage scans start in the upper right and end in the lower left. It's an interesting story:
http://smf.probesoftware.com/index.php?topic=101.0
I will need to add a case to handle beam current and standard intensity drift for JEOL stage scans, but right now I'd like to test the beam scan drift and use the stage scan for testing the next coding effort, that is once I figure a method for determining if the x-ray map was a JEOL beam or stage scan!
So here's the test acquisition protocol if you are interested:
1. Create a sample setup in Probe for EPMA with 3 to 5 elements (or more if you want to do a two pass acquisition with more than one element per spectrometer). Karsten has excellent documentation for this here:
http://smf.probesoftware.com/index.php?topic=106.0
2. Acquire your primary and MAN standards in PFE. They are automatically saved to your MDB file.
3. Acquire both a beam scan and a scan scan using this setup in Probe Image. Please name the beam scan sample "Beam scan..." and the stage scan "Stage scan...". The x-ray map PrbImg files are automatically saved.
4. Now acquire the primary and MAN standards in Probe for EPMA *again*, for the drift correction.
Hopefully even if the beam current and/or standard intensity drift was significant, we can now correct for this in CalcImage.
Feel free to play the the latest version of CalcImage yourself and test the new drift correction code, but please do send me a ZIP with the MDB and the PrbImag files acquired so I can try it myself.
Thank-you!
john
Paul Carpenter had a good idea: display the before and after beam currents in the raw intensity map output. The intensity data is therefore displayed in cps/actual beam current without any correction. Of course when these intensities are quantified, beam drift and standard intensity drift corrections are applied to the map intensity data (along with dead time, background, matrix and interference corrections as well!).
(https://smf.probesoftware.com/oldpics/i60.tinypic.com/2yjvqs6.jpg)
Quote from: John Donovan on October 13, 2015, 04:26:40 PM
I have a data acquisition request for our JEOL ProbeImage/CalcImage colleagues... but first some background.
As many of you already know, Probe for EPMA contains a very robust drift correction not only for beam current drift, but also for standard intensity drift. This beam current drift correction is commonly performed by other softwares, but the automatic standard intensity drift correction is unique to PFE, and allows the software to correct for changes in the measured standard intensities over time, on an element by element basis. That is, assuming that you acquired your standard(s) both before *and* after your unknown point acquisitions!
Now I have fully implemented this beam current and standard intensity drift correction in CalcImage for our x-ray mapping quantification. The beam current drift correction was already implemented in CalcImage but now, the standard intensity drift correction is also implemented. This standard intensity drift correction is a totally unique feature in both PFE and now, CalcImage, and it works amazingly well.
And because the standard intensity drift correction is performed on an element by element basis, it can deal with temperature related drift issues such as the thermal sensitivity of the PET crystals.
I also implemented the new CalcImage drift correction code so it automatically handles the situation where there is more than one x-ray map acquisition set for the quantification. That is, more than one element per spectrometer were acquired in Probe Image, using multiple sample acquisitions on the same area.
I should mention that so far as I know neither Cameca nor JEOL perform this standard intensity drift correction in their x-ray map quantifications, though Cameca does allow the user to re-measure the beam current at the end of N scan lines. But if your beam is stable and your spectrometer crystal is warming up and therefore your peak position is changing, this won't help you. I believe that JEOL only averages the beam current before and after the map acquisition for a crude beam drift correction.
So OK, I thought of a method to induce a crude roughly linear
intensity drift in the instrument during a x-ray map acquisition to test the above standard intensity drift correction.
In this test I acquired a standard intensity set, then ran a short x-ray map acquisition, and then re-acquired the standard intensities again to provide the drift correction. What I did was tune the Si ka peak position just to the high side of the peak. That is, still on the peak but just about to drop off down the side of the peak.
Then I opened an SX command line interpreter window and typed the "spec" command to move the spectrometer position one 10^-5 sintheta unit manually every 30 seconds or so during the x-ray map acquisition (one can use the up cursor to get the previous command in this window which is nice). This forced the Si Ka intensities to drop from around 18,000 counts to around 13,000 counts on the LTAP crystal during the map acquisition.
Note that the beam was absolutely stable during the standards and x-ray map acquisitions. Here is the raw data:
(https://smf.probesoftware.com/oldpics/i66.tinypic.com/r0xn9k.jpg)
Note the enormous change in Si ka intensities due to the spectrometer peak position changing during the map acquisition. This intensity drift corresponds to a change from about 21 wt% Si to about 10 % Si. Now here is the quantification with the drift correction:
(https://smf.probesoftware.com/oldpics/i63.tinypic.com/242uzir.jpg)
The correction isn't perfect because the x-ray map acquisition was so short (~10 minutes) and I wasn't perfect in running the standards with such a manually induced drift, but it certainly demonstrates the principle of the standard drift correction for x-ray map acquisitions.
Now I have a request. This x-ray map drift correction in CalcImage currently assumes a normal scan method for beam and stage scans. That is, the scan starts in the upper left, fast scans in X, and finishes in the lower right.
This standard drift correction method will therefore work just fine on Cameca beam and stage scans and JEOL beam scans, which are all normal scans (assuming the intensity drift in roughly linear). However, the JEOL stage scan is a completely different animal as it starts in the *upper right*, fast scans in Y, and finishes in the *lower left*. If you are interested why JEOL does this, here is a discussion:
http://smf.probesoftware.com/index.php?topic=101.0
So, to avoid over heating my brain in trying to implement a standard drift correction for JEOL stage scans it would be most helpful if someone out there in "JEOL land" would acquire a stage scan where there is significant, but linear standard intensity drift over time. The method is simply to acquire your standards in PFE, run ProbeImage to acquire a stage scan with just a few elements, and then re-acquire your standards in PFE again to "bracket" the intensity change over time.
One can do the initial standard acquisition and Probe Image map acquisition automatically from the new "Run Probe Image" option in the PFE Automate! window, as seen here:
http://smf.probesoftware.com/index.php?topic=600.msg3446#msg3446
But you'll need to run the standards again in PFE once the map finishes. I'll probably add an option for re-running the standards automatically after the Probe Image acquisition completes.
And although CalcImage performs nice beam drift correction based on the pixel acquisition order based on the before and after beam currents, I would only like to test the standard intensity drift correction, so one method might be to start the PFE/PI acquisition and turn off the room temperature control to allow the room temp to slowly change during this acquisition. Once the 2nd standard intensities are acquired you can turn the room temperature control back on and send me the data.
First person to do this gets a big wet kiss from me... ok, no. The first person to do this *won't* get a big wet kiss from me! How about that? ;D
Thanks in advance.
john
I just wanted to show some of the many data types that are automatically output in CalcImage when performing an image quantification:
(https://smf.probesoftware.com/gallery/395_04_03_16_6_32_45.png)
Just a few mouse clicks and bang, right into Surfer presentation quality output...
I just added code to automatically add elements specified as Formula By Difference elements (if not already present) in CalcImage (and CalcZAF), when indicated, as as seen here:
(https://smf.probesoftware.com/gallery/1_05_10_16_9_40_30.png)
Otherwise one would have to add the elements one at a time in the Elements/Cations dialog(!). This code was already in PFE for point analyses, but I had forgotten to add it to CalcImage! :-[
Then again- nobody had complained about it! ;D
john
I'm not sure how useful this will be but now there are options to output analog signal images along with your quant maps in CalcImage as seen here in the Quant dialog:
(https://smf.probesoftware.com/gallery/1_21_10_16_6_51_00.png)
Note that the output image controls are labeled as they are declared in your probewin.ini file in the [imaging] section. But you can edit them as necessary for however you want them labeled.
Here is an example of the output for some trace elements in zircon (at 10 keV, 100 nA) when the Surfer script is run:
(https://smf.probesoftware.com/gallery/1_21_10_16_6_51_18.jpeg)
To utilize this new analog signal output feature with old CalcImage projects that do not show the desired analog images as available, simply re-create the project using the Create (new) Project Wizard menu.
(https://smf.probesoftware.com/gallery/1_23_10_16_10_54_20.jpeg)
Quote from: John Donovan on October 21, 2016, 06:56:55 PM
Here is an example of the output for some trace elements in zircon (at 10 keV, 100 nA) when the Surfer script is run:
(https://smf.probesoftware.com/gallery/1_21_10_16_6_51_18.jpeg)
Because the x-ray map area contained a small apatite inclusion, it is difficult to see the phosphorus variation in the previous output (see P map in upper right). However, using the log weight percent output option, we can see the phosphorus concentrations much more clearly in the output below (see P map in lower left):
(https://smf.probesoftware.com/gallery/395_24_10_16_12_47_26.jpeg)
As many of you know we have long enjoyed the TDI (time dependent intensity) correction in Probe for EPMA to deal with beam sensitive samples, e.g., alkali and/or hydrous glasses as described here :
http://smf.probesoftware.com/index.php?topic=11.0
A few years ago it occurred to Philippe Pinard and Sylvia Richter that a CPQ (Correlated Pixel Quantification) method (where one acquires an x-ray map on both the unknown *and* the standard), might be applied to deal with carbon contamination when measuring trace carbon, e.g., in steel as described here:
http://smf.probesoftware.com/index.php?topic=114.msg423#msg423
Unfortunately, the CPQ method, while perhaps useful for correction of Bragg defocusing at low magnification beam scans, doesn't work well enough on the carbon contamination problem as the rate of carbon contamination isn't reproducible enough when dwelling on each pixel for the time required for reasonable precision, e.g., 10 seconds per pixel.
Then I thought perhaps we could apply the TDI method to quantitative mapping by acquiring a series of replicate scans, where instead of sitting on each pixel for the full counting time and then moving to the next pixel, we divide up the map acquisition into a series of fast replicate maps. The idea being that the carbon contamination is "smeared out" evenly over the entire analytical area. Then perhaps we could apply a TDI correction on each pixel using the replicate maps and extrapolate the carbon intensity back to zero time, before the contamination began.
Originally I performed a simple test a few years ago by acquiring a 32 pixel scan on pure Fe metal using 10 replicates at 1 second per replicate. I then plotting up the quantified replicate maps and it does appear that the carbon quant trend intersects zero as seen here:
http://smf.probesoftware.com/index.php?topic=48.msg3416#msg3416
So with that in mind, I spent the last few weeks working on implementing a TDI correction for each pixel in a replicate series of x-ray maps and I am pleased to say that we now have a full TDI correction in CalcImage for x-ray maps. This method utilizes replicate scans acquired in Probe Image and performs a full TDI correction for each pixel as seen here for carbon on pure Fe metal:
(https://smf.probesoftware.com/gallery/395_26_02_17_4_13_03.png)
and here for nitrogen (no obvious trend in the data)
(https://smf.probesoftware.com/gallery/395_26_02_17_4_13_25.png)
Here are the raw x-ray maps before quantification (a line scan of 32 pixels at 10 keV, 50 nA and 1 sec per pixel per replicate for a total of 10 seconds for the replicate series), which by the way was performed using the MAN background correction so no off-peak images were necessary:
(https://smf.probesoftware.com/gallery/395_26_02_17_4_13_55.png)
The carbon map is in the lower right quadrant. Here are the quantified maps *without* a TDI correction:
(https://smf.probesoftware.com/gallery/395_26_02_17_4_14_14.png)
And here are the quantified maps *with* a full TDI correction applied to each map pixel:
(https://smf.probesoftware.com/gallery/395_26_02_17_4_14_35.png)
It is perhaps better to see the numerical output in the CalcImage log window, here first *without* the TDI correction:
Without TDI image correction:
C N Mo Fe Si Total
Weight %: 1 (1,1) .453321 -.03180 -.03053 100.101 .002954 100.494
Weight %: 2 (2,1) .519024 .003435 -.00806 99.9945 -.00598 100.503
Weight %: 3 (3,1) .434480 -.04739 -.05933 100.038 .007308 100.373
Weight %: 4 (4,1) .464101 -.00715 -.00333 99.3005 -.00385 99.7502
Weight %: 5 (5,1) .490581 -.03396 -.01931 100.912 .005218 101.354
Weight %: 6 (6,1) .467664 -.05276 .001430 98.8739 .005178 99.2954
Weight %: 7 (7,1) .840907 -.05204 -.02373 100.159 .014814 100.938
Weight %: 8 (8,1) .855509 -.01140 -.02686 99.8534 .022579 100.693
Weight %: 9 (9,1) .363398 -.01886 -.04819 99.8299 .004917 100.131
Weight %: 10 (10,1) .354097 -.07100 -.02269 98.6863 .001746 98.9484
Weight %: 11 (11,1) .372812 -.04317 .007723 99.4145 .005505 99.7574
Weight %: 12 (12,1) .385476 -.01239 .012560 99.8808 .003351 100.270
Weight %: 13 (13,1) .427612 -.05989 -.01780 100.015 .012153 100.377
Weight %: 14 (14,1) .406739 .046412 -.01132 99.0875 .006155 99.5355
Weight %: 15 (15,1) .416387 .006948 -.02733 99.7070 .004553 100.108
Weight %: 16 (16,1) .737594 -.02365 -.02859 99.5029 .029309 100.218
Weight %: 17 (17,1) .863599 -.02339 -.05725 100.204 .028362 101.015
Weight %: 18 (18,1) .347543 -.03762 -.03225 100.589 .011480 100.879
Weight %: 19 (19,1) .328581 -.01993 -.00668 100.478 .010791 100.791
Weight %: 20 (20,1) .343103 -.06226 -.01151 101.075 .011064 101.356
Weight %: 21 (21,1) .447505 -.02560 -.04810 100.395 .018343 100.787
Weight %: 22 (22,1) .405794 .018765 -.02095 100.378 .005015 100.786
Weight %: 23 (23,1) .448499 -.04090 -.01296 99.3157 .014807 99.7252
Weight %: 24 (24,1) .451467 -.07769 .004583 100.042 .014862 100.435
Weight %: 25 (25,1) .791023 -.08682 -.04619 100.041 .036205 100.736
Weight %: 26 (26,1) .845943 -.03899 -.02848 99.5872 .045949 100.412
Weight %: 27 (27,1) .357682 -.04655 -.01307 100.110 .010420 100.419
Weight %: 28 (28,1) .384053 -.08231 -.04663 99.7039 .010831 99.9699
Weight %: 29 (29,1) .375092 -.12850 -.00195 98.4028 .006886 98.6543
Weight %: 30 (30,1) .384347 -.06711 .004524 99.4623 .017853 99.8019
Weight %: 31 (31,1) .332556 -.11764 .005993 101.817 .007518 102.045
Weight %: 32 (32,1) .509899 -.04511 -.03046 99.3339 .028529 99.7968
And here with the TDI image correction:
C N Mo Fe Si Total
Weight %: 1 (1,1) .110519 -.01585 -.06678 100.082 -.01152 100.098
Weight %: 2 (2,1) .063757 -.02377 -.01238 100.486 -.01004 100.504
Weight %: 3 (3,1) .049959 -.23617 -.04097 101.709 .005234 101.487
Weight %: 4 (4,1) .100714 -.03186 -.02337 98.6615 -.01990 98.6870
Weight %: 5 (5,1) .198686 -.12025 .000016 102.630 -.00862 102.700
Weight %: 6 (6,1) .106266 .002536 -.00652 100.026 -.00306 100.125
Weight %: 7 (7,1) .522448 .042382 -.01003 100.399 .000076 100.954
Weight %: 8 (8,1) .518256 .018884 -.02240 100.441 .012291 100.968
Weight %: 9 (9,1) .073143 .112474 -.06401 102.516 -.00340 102.634
Weight %: 10 (10,1) .111063 -.01682 -.01427 96.6596 -.00719 96.7324
Weight %: 11 (11,1) .024760 -.07442 .009346 98.7109 .005805 98.6763
Weight %: 12 (12,1) .034188 -.01473 .045469 100.241 -.00225 100.304
Weight %: 13 (13,1) .112153 -.05364 -.04499 101.245 .002164 101.261
Weight %: 14 (14,1) .052089 -.04881 -.01312 99.5550 .000969 99.5462
Weight %: 15 (15,1) .066157 -.01249 -.04216 100.298 -.01288 100.297
Weight %: 16 (16,1) .448711 -.03055 -.07451 100.850 .021595 101.215
Weight %: 17 (17,1) .611663 .004584 -.04216 101.064 .024894 101.663
Weight %: 18 (18,1) .073242 .061129 .017657 101.921 -.00767 102.066
Weight %: 19 (19,1) -.03482 -.08892 -.03202 101.861 .004212 101.710
Weight %: 20 (20,1) -.00799 -.00954 -.05652 99.9741 -.00715 99.8929
Weight %: 21 (21,1) .109334 .002265 .008306 100.201 -.00414 100.317
Weight %: 22 (22,1) .066635 -.01768 .054906 100.131 .000971 100.236
Weight %: 23 (23,1) .017554 -.06436 .123012 97.7513 -.00060 97.8269
Weight %: 24 (24,1) .132921 -.17412 -.00153 98.8648 .007539 98.8296
Weight %: 25 (25,1) .518753 -.03771 -.01474 100.421 .028878 100.916
Weight %: 26 (26,1) .434910 -.05500 -.03045 97.2691 .028320 97.6469
Weight %: 27 (27,1) .075951 -.12082 -.02824 99.2273 .008542 99.1628
Weight %: 28 (28,1) .005009 .016857 -.04798 101.226 .003904 101.204
Weight %: 29 (29,1) .041551 -.13717 -.03206 99.5807 -.00418 99.4488
Weight %: 30 (30,1) -.01026 -.12391 .017750 100.399 -.00393 100.279
Weight %: 31 (31,1) -.00543 -.09645 -.01502 101.243 .006624 101.133
Weight %: 32 (32,1) .139376 -.01928 -.04601 99.3611 .008726 99.4439
Please note that the carbon column quant values now are around zero (with no blank correction), as measured on pure Fe metal, and note that this acquisition was performed on a oil diffusion pumped system...
DataType (32): C Wt.% N Wt.% Mo Wt.% Fe Wt.% Si Wt.%
Average: 0.15 -0.04 -0.02 100.16 0.00
Std Devs: 0.18 0.07 0.04 1.39 0.01
Std Error: 0.03 0.01 0.01 0.25 0.00
Rel %: 121.48 -164.09 -248.82 1.39 579.67
Minimums: -0.03 -0.24 -0.07 96.66 -0.02
Maximums: 0.61 0.11 0.12 102.63 0.03
The scanning TDI method is applied exactly the same as one would for the point TDI correction in PFE (all the TDI options operate as before), but the only extra step is that one must first convert the replicate maps acquired in Probe Image into "TDI" maps by using a menu in the CalcImage log window as seen here:
(https://smf.probesoftware.com/gallery/395_26_02_17_4_29_16.png)
Next I'd like to try a replicate scan acquisition on a beam sensitive sample such as a alkali glass melt inclusion.
I've attached the complete CalcImage project below as a ZIP file if any of you would like to play around with it. This scanning TDI feature is now available in PFE v. 11.8.3. Please feel free to let me know if you have any questions.
john
So in looking at this scanning TDI data on some of the other elements in this pure Fe std, I was surprised to see that silicon shows a somewhat similar behavior to carbon. Here is the TDI plot for each of the 32 pixels for Si ka:
(https://smf.probesoftware.com/gallery/1_27_02_17_2_21_17.png)
This is silicon intensity as a function of time for each of the 10 replicate scans... Now what could be causing the Si to increase over time- we're using a hydro-carbon based diffusion pump oil so it can't be from the carbon deposition, right? We probably polished the sample with colloidal silica it's true, but that would all have been cleaned off I think... but in any event, why would the Si intensity increase over time?
Just for your curiosity here is the quantified silicon concentrations (background and matrix corrected) and without and with the TDI correction plotted as a function of distance:
(https://smf.probesoftware.com/gallery/1_27_02_17_2_21_31.jpeg)
I'm stumped. Any of you have any hypotheses on what's causing the increase of silicon signal over time in these replicate scans?
john
I have, on occasion, been accused of "spoiling" our users. ;) But seriously, I don't think so because one of my internal criteria for judging whether a requested feature is worth implementing is simply: would I find the requested feature in question, useful and/or fun? And this feature request is something my students and I would use in our own lab.
As you know there is an enormous number of x-ray map data types that can be output from the CalcImage quantitative mapping software. e.g, elemental wt%, oxide wt.%, atomic %, formula basis, detection limits, analytical sensitivity, net intensities, bgd intensities, k-ratios, log wt.% and many, many more quantitative x-ray map data types. A few examples are shown here in our latest brochure:
http://probesoftware.com/download/probesoftware%208-30-2016%20single%20pages_reduc.pdf
Anyway, at EMAS last month a bunch of us were brainstorming and Anette von der Handt asked (and was echoed by Paul Carpenter) if we could add a new menu to CalcImage, which would output all calculated data types (previously specified by the user), to the Surfer application for presentation quality output. So, one mouse click for everything output, instead of two mouses click for each data type...
This feature has now been implemented in the latest Probe for EPMA version, now available for download, as seen here:
(https://smf.probesoftware.com/gallery/1_03_06_17_12_56_05.png)
As many of you know, Cameca instrument stages have a "Cartesian" orientation. Because Golden Software's Surfer application was originally designed for GIS work, it always assumed a Cartesian coordinate system with the upper right being the X and Y maxima. But as we know, JEOL, for some reason:
http://smf.probesoftware.com/index.php?topic=101.0
utilizes an "anti-Cartesian" stage orientation! Originally Surfer did not handle this different stage orientation internally, and therefore I had to re-write all the JEOL stage coordinates "on the fly" to use inverted coordinates (by multiplying by -1) and then the quantitative plots would be oriented properly. However, the slice, polygon and strip scripts still displayed the mirror image in their output.
A while ago, I asked Golden Software if they could add a reverse orientation flag to their scripting and eventually, starting in version 13 of Surfer, they added this capability. So this weekend I finally got around to implementing this new flag for all scripts. I think it is backwards compatible with Surfer versions prior to 13, but let me know.
Here are some JEOL CalcImage script quant output with the new reverse axes flags. First for the slice script output:
(https://smf.probesoftware.com/gallery/1_25_11_17_4_27_01.png)
And here the polygon extraction script output:
(https://smf.probesoftware.com/gallery/1_25_11_17_4_27_25.png)
And here the strip extraction script output:
(https://smf.probesoftware.com/gallery/1_25_11_17_4_27_57.png)
Note that your existing default scripts will be updated automatically when you update PFE, but the "custom" scripts will not be automatically updated. But if you haven't manually edited your "custom" scripts, I've attached them below in a ZIP so you can extract them and overwrite your existing "custom" scripts in the ProgramData\Probe Software\Probe for EPMA folder.
If you have modified your "custom" scripts you will need to make the changes yourself manually by editing them. The key change is the addition of these lines:
' If Surfer v. 13 or higher, check for JEOL axis invert
If Val(Left$(SurferApp.Version, 2)) >= Val("13") Then
If XInvert% <> 0 then SurferAxes.Item("Bottom Axis").Reverse = True
If YInvert% <> 0 then SurferAxes.Item("Left Axis").Reverse = True
End If
But there are some additional parameters being passed (the XInvert and YInvert variables), so check the custom examples attached below and contact us if you need any help.
john
Edit by John: Updated custom scripts in ZIP attached below, for v.15 Surfer color palette location changes 06/06/2019
We decided to create a new Surfer options dialog in CalcImage for specifying various Surfer output options such as plots per page, default vs. custom plot templates and other Surfer output parameters.
This change allows us to get rid of a large number of menus in the main CalcImage window for better efficiency. The new Surfer options looks like this:
(https://smf.probesoftware.com/gallery/1_17_02_18_2_53_10.png)
Once that was done we realized that we could now implement a new menu as requested by Philipp Poeml for creating virtual standard intensities for quantification, just as we already have in Probe for EPMA. Here is the new virtual standard intensity menu:
(https://smf.probesoftware.com/gallery/1_17_02_18_2_53_39.png)
This should be useful for mapping of nuclear materials and other elements for which we do not have readily available standards, e.g., argon... see this topic for more on using virtual standard intensities. This post shows Philipp's virtual standard calculation for Am Ma using Pu Ma and Cm Ma as calibration points:
http://smf.probesoftware.com/index.php?topic=179.msg6743#msg6743
We remapped some of the menus in CalcImage to make things easier for users. Basically we moved the file conversion and help menus to the main CalcImage menu. First here is the new Convert menu in CalcImage:
(https://smf.probesoftware.com/gallery/1_24_02_18_9_01_59.png)
and here is the new Help menu in CalcImage:
(https://smf.probesoftware.com/gallery/1_24_02_18_9_02_18.png)
I also updated the CalcImage Help file to include a detailed explanation of the .CIP file format. Note that one can always get the help file by typing <ctrl> h from the main CalcImage window.
We fixed some minor issues in the strip and modal presentation output scripts. The latest version of Probe for EPMA will update your default scripts, but because the custom scripts are not automatically overwritten, if you haven't modified your custom output scripts you can grab a ZIP file of the updated custom scripts and manually overwrite the existing ones in your ProgramData\Probe Software\Probe for EPMA folder. The updated custom script zip file is attached to this post:
http://smf.probesoftware.com/index.php?topic=41.msg6488#msg6488
If you have modified your custom strip output scripts you can just compare the default strip and custom strip output scripts to see what was changed. Basically we fixed an issue with the increment value text output in the strip output scripts. A file compare of stripxy1.bas and stripxy1_Custom1.bas will reveal all.
Basically these two lines were modified to add the InStr function:
If InStr(XLabel$, "um") > 0 Then MicronUnits$ = Format$(Round(StripIncrement! ,0)) & "um"
If InStr(XLabel$, "mm") > 0 Then MicronUnits$ = Format$(Round(1000 * StripIncrement! ,0)) & "um"
There are no custom modal output scripts so we just turned off "hill shading" if v13 or higher of Surfer in the default modalxy.bas script.
Back in January starting with the release of Surfer v16 from Golden Software, we had to modify where the x-ray mapping output scripts looked for the default "rainbow.clr" file that is distributed with Surfer. Every few years it seems they change the location of this file! >:(
After this last change we edited the various default output scripts to use the following code:
' Load color spectrum depending on version number
If Val(Left$(SurferApp.Version, 2)) <= Val("8.") Then
SurferColorMap.LoadFile(SurferApp.Path & "\Samples\Rainbow2.clr")
ElseIf Val(Left$(SurferApp.Version, 2)) <= Val("15.") Then
SurferColorMap.LoadFile(SurferApp.Path & "\ColorScales\Rainbow2.clr")
Else
SurferColorMap.LoadFile(SurferApp.Path & "\Samples\Rainbow.clr")
End If
Unfortunately when we edited the default slice, polygon and strip output scripts to deal with the new location of the rainbow.clr file in Surfer v.16, we did not notice that the color map object was named differently from the default x-ray map output script. So these slice, polygon and strip output scripts have now been re-edited and are available in the current 12.6.3 version of Probe for EPMA. Just update from the Help menu.
However, the "customizable" scripts provided in Probe for EPMA are not automatically updated because that would overwrite any user customizations. If you haven't edited the custom scripts you can simply grab the latest custom scripts zip file (in case you'd like to start customizing them yourself), in the zip file attached to this post:
http://smf.probesoftware.com/index.php?topic=41.msg6488#msg6488
If you have modified your custom scripts for the slice, polygon or strip output, you'll need to edit the color map object in these scripts yourself. The point is simply that the color map object needs to match the object name it is declared with. So in the default x-ray map output scripts the object is declared like this and utilized to load the rainbow color map as seen here:
' Assigns the color spectrum properties to the variable named
Set SurferColorMap = SurferImageMap.ColorMap
' Set color scale significant digits
SurferImageMap.ColorScale.LabelFormat.NumDigits = 3
SurferImageMap.ColorScale.LabelFormat.Type = 3 ' 1 = Fixed, 2 = Exponential, 3 = Compact
Debug.Print "Surfer Version Number " & SurferApp.Version
' Load color spectrum depending on version number
If Val(Left$(SurferApp.Version, 2)) <= Val("8.") Then
SurferColorMap.LoadFile(SurferApp.Path & "\Samples\Rainbow2.clr")
ElseIf Val(Left$(SurferApp.Version, 2)) <= Val("15.") Then
SurferColorMap.LoadFile(SurferApp.Path & "\ColorScales\Rainbow2.clr")
Else
SurferColorMap.LoadFile(SurferApp.Path & "\Samples\Rainbow.clr")
End If
Note color map object name highlighted in red. What we didn't notice was that the object name in the slice, polygon and strip scripts was named ColorImageMap instead of SurferColorMap!
So the correct code in your custom slice, polygon and strip output scripts should be edited like this:
'Assigns the color spectrum properties to the variable named
Set ColorImageMap = ImageMap.ColorMap
'Set color scale significant digits
ImageMap.ColorScale.LabelFormat.NumDigits = 1
ImageMap.ColorScale.LabelFormat.Type = 1 ' 1 = Fixed, 2 = Exponential, 3 = Compact
'Format text in color scale
ImageMap.ColorScale.LabelFont.Size = 14
' Load color spectrum depending on version number
If Val(Left$(SurferApp.Version, 2)) <= Val("8.") Then
ColorImageMap.LoadFile(SurferApp.Path & "\Samples\Rainbow2.clr")
ElseIf Val(Left$(SurferApp.Version, 2)) <= Val("15.") Then
ColorImageMap.LoadFile(SurferApp.Path & "\ColorScales\Rainbow2.clr")
Else
ColorImageMap.LoadFile(SurferApp.Path & "\Samples\Rainbow.clr")
End If
Again, if you haven't edited the custom scripts for the slice, polygon or strip output methods in CalcImage, you don't need to do anything except update Probe for EPMA.
If you want the latest custom scripts and you haven't edited them yourself, you can download the attached ZIP file in the linked post above.
If you have customized these slice, polygon or strip scripts you'll need to manually make the changes above to your custom scripts as described above.
I'm sure I did not explain this very well, so if you have any questions at all, just let us know. Of course I think most users, especially students are simply utilizing the built in output in CalcImage for slice and polygon extractions of quantitative maps as described here:
https://smf.probesoftware.com/index.php?topic=1151.0
Quick note: if the in-line images in any posts don't show up as expected, just click your refresh button on your browser and they should show up properly.
This isn't really a new feature, but we changed the default error bar display mode from standard deviation to standard error, in the extract shape, profile and polygon pixels window as seen here:
(https://smf.probesoftware.com/gallery/1_30_06_19_2_27_54.png)
When averaging pixels it is more important to accurately reflect the error on the average, as opposed to the average variation of each pixel! Think of it this way: in the above example we specified a 10 pixel wide square, so that's 100 pixels averaged together. If counting only 100 msec for each pixel, that still 10 seconds of total integration time for the average, which is fairly similar to what we utilize for point analyses!
8)
Julien Allaz recently suggested that when a user selects the Output Sample Parameters menu to check that all the quantitative mapping options are properly set as seen here:
(https://smf.probesoftware.com/gallery/1_07_03_20_8_57_19.png)
That rather than analyzing the *first* pixel, that we instead analyze the "middle" pixel. The idea being that in the mapped area, the first pixel might not be within the actual material of interest. But the middle pixel probably will.
So now, the Output Sample Parameters menu will calculate the middle pixel as seen below, with one small twist: what if the middle pixel is for whatever reason (e.g., a very complex polygon acquisition), is outside the mapped area and is therefore "blanked"? Some polygon quant maps by Karsten Goemann are shown here (note the blanked pixels outside the acquisition area):
https://smf.probesoftware.com/index.php?topic=73.msg7840#msg7840
So then, after calculating the middle pixel, the program will also check that this pixel is not "blanked", and will loop towards the first pixel until it finds an unblanked pixel.
Anyway, here is an example of the middle pixel output from a quantitative x-ray map:
(https://smf.probesoftware.com/gallery/1_07_03_20_8_55_44.png)
This is a feature which has been around for a while but worth mentioning as it's not exactly obvious what is going on. Check out this image and notice the horizontal strip of gray pixels near the top of the image:
(https://smf.probesoftware.com/gallery/1_15_07_20_12_57_18.jpeg)
Now where is this gray color coming from? The Surfer color scale being utilized does not contain gray, so what does this indicate?
By viewing the same image in the CalcImage app and hovering the cursor over these pixels one can see they have values of "---"as seen here:
(https://smf.probesoftware.com/gallery/1_15_07_20_12_57_38.jpeg)
The "---" display means these pixels have no value. More specifically the values have been set to an arbitrary large number which is in fact the so called "blanking value" utilized by Golden Software's Surfer app to indicate missing data.
The actual value is defined here in our code:
Global Const BLANKINGVALUE! = 1.70141E+38 ' Surfer blanking grid value
So why are these values missing? Well sometimes we have pits, crack and other topography on our samples and when the quantitative analytical solution will not converge to a solution, the software specifies the pixel value as blanked.
In the case of this horizontal strip of gray pixels on this sample, we can confirm that there is a deep crack in this area of the sample surface.
Andrew Locock recently asked if we could have a field created in the PrbImg files (which are the mapping intensity files created by Probe Image during map acquisition), that specifies the image stage extents for the map.
Note that the PrbImg file already contains all the information but the user would need to perform a subtraction of the following fields:
[Registration]
X1Pixel=319
Y1Pixel=164
X2Pixel=0
Y2Pixel=0
X3Pixel=319
Y3Pixel=0
X1Real=-35.2848
Y1Real=-33.312
Z1Real=9.6945
X2Real=-35.0304
Y2Real=-33.4432
Z2Real=9.6945
Z3Real=9.6945
In the meantime it is worth noting that the stage extents of the map (stage scan or beam scan) can be obtained also by simply opening the PrbImg (click on the corresponding Tif file), from the Probe Image File | Open menu. Once the PrbImg file is opened, simply click on the Conditions tab to see the following information, including the horizontal and vertical field widths:
(https://smf.probesoftware.com/gallery/1_21_02_21_2_44_04.png)
In addition, one can also simply open the PrbImg file in CalcImage, and by "hovering" the mouse cursor over the image, the following information will pop up:
(https://smf.probesoftware.com/gallery/1_21_02_21_2_44_45.png)
Note however that the field width and height are displayed in stage units. In this case the stage units are in mms since the software is in a JEOL configuration.
Finally we recently added a new feature that displays additional stage extents information in the CalcImage Project | Specify Quantitative Parameters menu dialog as seen here:
(https://smf.probesoftware.com/gallery/1_21_02_21_2_45_03.png)
Remember, anyone (faculty, student, client or customer) that uses our software on your microprobe can receive a free copy of the software for reprocessing of point or map data. You can get the latest distribution files by updating both CalcZAF and Probe for EPMA from their respective Help menus. Then simply go to the C:\ProgramData\Probe Software\Probe for EPMA folder and grab these two files:
ProbeForEPMA.msi
CalcZAF.msi
Installing these two packages will allow anyone to reprocess their point or map data on any Windows computer (and Apple computers using the Parallels virtual Windows product). Of course they will also need their data files, which for Probe for EPMA are the .MDB files (and .BIM files if present).
For CalcImage they will need the PrbImg map files. However, if the PrbImg map files have already been added to a CalcImage project, they will only need the files in the UserData folder, since the PrbImg files are converted to .GRD files during that process.
Please let us know if you have any questions about this.
Quote from: John Donovan on February 21, 2021, 03:13:01 PM
Finally we recently added a new feature that displays additional stage extents information in the CalcImage Project | Specify Quantitative Parameters menu dialog as seen here:
(https://smf.probesoftware.com/gallery/1_21_02_21_2_45_03.png)
Remember, anyone (faculty, student, client or customer) that uses our software on your microprobe can receive a free copy of the software for reprocessing of point or map data. You can get the latest distribution files by updating both CalcZAF and Probe for EPMA from their respective Help menus. Then simply go to the C:\ProgramData\Probe Software\Probe for EPMA folder and grab these two files:
ProbeForEPMA.msi
CalcZAF.msi
Installing these two packages will allow anyone to reprocess their point or map data on any Windows computer (and Apple computers using the Parallels virtual Windows product). Of course they will also need their data files, which for Probe for EPMA are the .MDB files (and .BIM files if present).
For CalcImage they will need the PrbImg map files. However, if the PrbImg map files have already been added to a CalcImage project, they will only need the files in the UserData folder, since the PrbImg files are converted to .GRD files during that process.
Please let us know if you have any questions about this.
Just a quick note that we noticed that this stage extents display feature in CalcImage was not working properly when creating a new project (as opposed to opening an existing project), so we just uploaded a new PFE update today to fix that. Update from the Probe for EPMA Help menu and you will get this latest update.
Ben Buse (Bristol) recently contacted us about adding additional data and image output for unanalyzed elements in CalcImage.
As some of you are aware, we already output data and images for totals (not really an element I guess!), stoichiometric oxygen, excess oxygen (when oxygen is measured and the "Display As Oxides" options is selected), and the element by difference as shown here:
(https://smf.probesoftware.com/gallery/1_22_01_22_9_35_43.png)
However, we were only performing these additional data/images for elemental quant, atomic percents and oxide calculations and Ben said he would like to have these unanalyzed data/image also output for formula calculations. So after a few days of work we were able to add this additional output as seen here:
(https://smf.probesoftware.com/gallery/1_22_01_22_9_43_14.png)
and also here in the pixel extraction window:
(https://smf.probesoftware.com/gallery/1_22_01_22_9_43_35.png)
So now Ben can perform his pixel extractions based on say, carbon by difference in formula units. That's what he wants anyway.
It should also be pointed out that the other way to calculate the carbonate molecule is by stoichiometry to stoichiometric oxygen as shown here in the Calculation Options dialog:
(https://smf.probesoftware.com/gallery/1_22_01_22_9_45_27.png)
Using this option one obtains an actual analytical, but currently we do not produce images for the element by stoichiometry to stoichiometric oxygen as seen here:
(https://smf.probesoftware.com/gallery/1_22_01_22_9_46_21.png)
However, the element by stoichiometry to stoichiometric oxygen is calculated and output to the "Classify" .DAT files for pixel extraction and use by 3rd party software:
(https://smf.probesoftware.com/gallery/1_22_01_22_11_11_04.png)
Some of you have probably noticed this output option in CalcImage for quantitative X-ray mapping output:
(https://smf.probesoftware.com/gallery/1_25_01_22_9_22_44.png)
This feature has now been modified further.
Originally this option was for situations in which the excess oxygen obtained from measuring oxygen is compared to the oxygen calculated from cation stoichiometry. This can be useful for minerals (e.g., oxides) which may contain both FeO and Fe2O3, but especially also for glasses when considerations of stoichiometry (e.g., charge balance) are not possible for mineral glasses, as described here:
https://smf.probesoftware.com/index.php?topic=922.0
An example here on a magnetite standard shows how oxygen from the cations (assuming all Fe as FeO) is subtracted from the measured oxygen to obtain the excess oxygen from ferric Fe:
(https://smf.probesoftware.com/gallery/1_24_01_22_11_38_51.png)
However, as we all know, measuring oxygen in the microprobe is not a trivial endeavor as described here:
https://smf.probesoftware.com/index.php?topic=1061.0
The other method for obtaining excess oxygen from ferric iron in oxides and other minerals (though not for glasses), is rather than measure oxygen directly, is to instead perform a charge balance calculation of the measured cations, and run that through the matrix correction with the measured elements to obtain the oxygen from Fe2O3 (assuming Fe is the only multivalent cation) as described here:
https://smf.probesoftware.com/index.php?topic=92.msg8593#msg8593
Anyway, after examining the code we added for outputting the unanalyzed elements in formula units in CalcImage as requested by Ben Buse above, we realized that we could extend this excess oxygen from ferrous/ferric charge balance calculation to CalcImage. So here is the new output of excess oxygen from ferrous/ferric ratio using the Droop charge balance method in CalcImage:
(https://smf.probesoftware.com/gallery/1_24_01_22_11_39_09.png)
Update to Probe for EPMA 13.08 using the Help menu as usual, and try it out!
The quantitative mapping examples shown above for excess oxygen from ferric iron (or water in glass when measuring oxygen) made me think about the case of deficit oxygen when halogens are present in some minerals, for example apatite.
So I tried a quick map on our apatite standard (difficult to find an area that wasn't already chewed up by the beam!), and so here we are:
(https://smf.probesoftware.com/gallery/395_01_02_22_2_31_37.jpeg)
The thing is, because the matrix correction routines in PFE/CalcZAF subtracts the oxygen equivalent of the halogens out from the calculated stoichiometric oxygen, the stoichiometric oxygen map is already corrected for this effect. That is, if the Use Oxygen From Halogen Correction is turned on as shown here:
(https://smf.probesoftware.com/gallery/395_01_02_22_2_43_37.png)
More discussion on this halogen-oxygen correction is here:
https://smf.probesoftware.com/index.php?topic=1247.0
What is interesting to me is the apparent heterogeneity of the Cl map, but if we take a look at some point analyses using TDI acquisitions we can see that this material is probably suffering significant ion migration with a focused beam:
(https://smf.probesoftware.com/gallery/395_01_02_22_2_32_02.png)
Most likely similar to what we see for alkali migration in glass mapping, but of course in the opposite direction (towards the surface away from the subsurface charge). Ery Huges published some work on this, regarding hydroxl ion migration a while back...
https://smf.probesoftware.com/index.php?topic=912.0
As soon as I get this standard mount repolished, I'll try a TDI quant mapping on it.
We added a new quantitative output option for matrix correction maps and a couple new output menus in CalcImage. Here is the new checkbox:
(https://smf.probesoftware.com/gallery/1_14_06_22_9_52_59.png)
If this option is checked the program will calculate matrix correction maps for ZAF, Phi-Rho-Z or alpha factor methods (the checkbox will be disabled for the calibration curve method). Once the data is calculated you can open all maps or output them to Surfer as usual:
(https://smf.probesoftware.com/gallery/1_14_06_22_9_43_11.png)
Here are the maps after output to the Surfer application for presentation output (note the Z axis values are matrix correction factors):
(https://smf.probesoftware.com/gallery/1_14_06_22_9_43_34.jpeg)
If absorption dominates the pixel value will be greater than 1.0, and if fluorescence dominates the pixel value will be less than 1.0. We aren't sure exactly what this feature will be useful for, maybe research or maybe teaching.
Please let us now if you find it useful and why.
Following up on the post comparing the determination of excess oxygen from measuring oxygen to calculating ferric iron from charge balance in Probe for EPMA using the same data set as discussed here:
https://smf.probesoftware.com/index.php?topic=92.msg12572#msg12572
We now proceed to how this might also be done on quantitative x-ray maps where oxygen has been measured in CalcImage. That is, in CalcImage can we calculate excess oxygen using same x-ray maps using measured oxygen and also using the Droop charge balance method as we did for the point analyses in the post linked above?
The answer is yes and it's basically the same procedure that we did in Probe for EPMA (please note that we fixed a small bug that was disabling the ferric/ferrous options in the Calculation Options in CalcImage, so be sure to update CalcImage and Probe for EPMA using the Help menu in Probe for EPMA as usual).
Let's start by just calculating excess oxygen in a magnetite map using measured oxygen declaring FeO as the default display oxide for Fe:
(https://smf.probesoftware.com/gallery/1_19_04_24_4_02_05.png)
After calculating all the pixels we obtain these maps:
(https://smf.probesoftware.com/gallery/1_19_04_24_4_02_24.jpeg)
Note that we could also have specified a stoichiometric oxygen map if desired.
Next (probably a good idea to first copy the files to another folder so we can output our maps without overwriting the previous maps), we then disable the measured oxygen channel in the CalcImage Elements/Cations dialog, then add oxygen as an unanalyzed elements (no x-ray line) as we did in PFE, then from the Calculation Options dialog we specify stoichiometric oxygen and the ferric/ferrous formula for magnetite (3 cations to 4 oxygens):
(https://smf.probesoftware.com/gallery/1_19_04_24_4_02_37.png)
Now we calculate all pixels and obtain our output:
(https://smf.probesoftware.com/gallery/1_19_04_24_4_02_51.jpeg)
Note that the excess oxygen from ferric iron is somewhat more accurate compared to measuring excess oxygen in the cracked area, which makes sense since oxygen is so sensitive to topography.
This isn't so much a new feature as a fix for something that wasn't quite right.
Maybe some of you have noticed, but as Paul Carpenter pointed out to me recently that the "Totals" column in some of the GUI windows and the "Classify" output .DAT files was not always the last column. This sometimes occurred when unanalyzed elements were added to the project. This was an oversight and has now been fixed:
(https://smf.probesoftware.com/gallery/1_04_08_24_1_17_10.png)
In addition the "Classify" DAT file used to have a trailing tab on each line which might caused an issue when reading the DAT file in other applications. This has also been fixed.
This is a tiny change but recently a new user suggested that rather then asking each time if one wants to create a new CalcImage project from an existing project (and specifying different x-ray maps for use with the previous map quantification settings), we instead make a new menu specifically for creating a new project from an existing project.
Seems like a good idea so we did that:
(https://smf.probesoftware.com/gallery/1_17_08_24_1_24_27.png)
Update as usual from the Help | Update Probe for EPMA menu and you will get the latest version of CalcImage...
Thank-you Christian for the idea!
The latest version of CalcImage (13.9.6) now includes a new menu under the Help menu that links to a video tutorial on YouTube on how to perform quantitative mapping in CalcImage:
(https://smf.probesoftware.com/gallery/1_11_12_24_2_11_01.png)
Thanks to Scott Boroughs for the video tutorial!
The latest version of CalcImage (update Probe for EPMA) has an updated Classify Image Exporter app. See the Project | Export Images to PNG Files menu after quant images are calculated to output formatted (high resolution) quant images without the Surfer app:
(https://smf.probesoftware.com/gallery/1_27_05_25_12_46_44.png)
This latest version (1.1.1) fixes a few minor bugs and has improved speed. See here for more details:
https://smf.probesoftware.com/index.php?topic=997.msg13439#msg13439