New Features in CalcImage

[John Donovan]

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://probesoftware.com/smf/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://probesoftware.com/smf/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.

[John Donovan]

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:



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!

 

[John Donovan]

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:



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://probesoftware.com/smf/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:

[John Donovan]

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:



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:



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.

[John Donovan]

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:



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:



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:



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.

[John Donovan]

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:



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.

[John Donovan]

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:



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:



and also here in the pixel extraction window:



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:



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:



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:

[John Donovan]

Some of you have probably noticed this output option in CalcImage for quantitative X-ray mapping output:



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://probesoftware.com/smf/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:



However, as we all know, measuring oxygen in the microprobe is not a trivial endeavor as described here:

https://probesoftware.com/smf/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://probesoftware.com/smf/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:



Update to Probe for EPMA 13.08 using the Help menu as usual, and try it out!

[Probeman]

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:



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:



More discussion on this halogen-oxygen correction is here:

https://probesoftware.com/smf/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:



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://probesoftware.com/smf/index.php?topic=912.0

As soon as I get this standard mount repolished, I'll try a TDI quant mapping on it.

[John Donovan]

We added a new quantitative output option for matrix correction maps and a couple new output menus in CalcImage. Here is the new checkbox:



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:



Here are the maps after output to the Surfer application for presentation output (note the Z axis values are matrix correction factors):



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.

[John Donovan]

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://probesoftware.com/smf/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:



After calculating all the pixels we obtain these maps:



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):



Now we calculate all pixels and obtain our output:



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.