### Author Topic: Conversion from wt% to atom% without normalization  (Read 962 times)

#### Philipp Poeml

• Professor
• Posts: 222
##### Conversion from wt% to atom% without normalization
« on: June 02, 2022, 10:51:45 AM »
Hi,
so I recently run into a problem. I made some map and then selected as output atom% in calcimage, because I need to compare with another technique which delivers atom% maps.
It seems that it works fine, but on holes and pores we have a problem. Because on a pore the total can be very low this leads to very strange numbers, because the standard conversion from wt% to atom% (and vice versa) involves normalization to 100%. So I get very high atom% values where is actually a hole or pore.

Is there a way to do the conversion without normalization?
or
Is there a way to de-normalize the atom% values? For example using the wt% total? Like, if in the wt% map I get a 20% total, then I take my 100 atom% total after the conversion and calculate it down to 20%?

Any ideas?

#### Nicholas Ritchie

• Professor
• Posts: 159
##### Re: Conversion from wt% to atom% without normalization
« Reply #1 on: June 03, 2022, 06:31:59 AM »
I don't know of any way to convert from wt% to atom% without normalization.
It isn't clear that multiplying the atom% value by the analytical total (sum of wt%) gives a meaningful value.  It would seem that none of the values are meaningful in a hole (not wt% or atom%).  Junk is junk.  (A hole really is 0/0 = undefined, zero atoms normalized by zero atoms.)
In that regard, it is probably best to set the values when the analytical total is far from acceptable to "missing" or some other way to indicate that the data is junk and not worthy of consideration.
How you encode "missing" depends upon your software.  Some software has a "missing" or "nothing" or "null" value.  Sometimes all zeros works.  Sometimes, "NaN" is viable.  "NaN" in a certain sense is the best representation of 0/0. ("NaN" is a representable value in IEEE floating point arithmetic used by all computers today. It is the result produced by "0/0".)
« Last Edit: June 03, 2022, 06:34:59 AM by NicholasRitchie »
"Do what you can, with what you have, where you are"
- Teddy Roosevelt

#### Probeman

• Emeritus
• Posts: 2876
• Never sleeps...
##### Re: Conversion from wt% to atom% without normalization
« Reply #2 on: June 03, 2022, 08:42:23 AM »
In the Image Processing | Classify Image menu dialog one can generate binary and quant masks, which can be utilized for the purpose Nicholas mentions.
The only stupid question is the one not asked!

#### John Donovan

• Emeritus
• Posts: 3323
• Other duties as assigned...
##### Re: Conversion from wt% to atom% without normalization
« Reply #3 on: June 04, 2022, 08:48:05 AM »
Hi,
so I recently run into a problem. I made some map and then selected as output atom% in calcimage, because I need to compare with another technique which delivers atom% maps.
It seems that it works fine, but on holes and pores we have a problem. Because on a pore the total can be very low this leads to very strange numbers, because the standard conversion from wt% to atom% (and vice versa) involves normalization to 100%. So I get very high atom% values where is actually a hole or pore.

Is there a way to do the conversion without normalization?
or
Is there a way to de-normalize the atom% values? For example using the wt% total? Like, if in the wt% map I get a 20% total, then I take my 100 atom% total after the conversion and calculate it down to 20%?

Any ideas?

Here's an idea:

When this new checkbox is checked, the pixels will  be set to the "blank value" so in Surfer they will look gray.  The blank value is 1.70141E+38.

The total is considered "bad" if the elemental total is less than AnalyticalTotalMinimum or greater than the AnalyticalTotalMaximum as defined in the [software] section of the Probewin.ini file.
John J. Donovan, Pres.
(541) 343-3400

"Not Absolutely Certain, Yet Reliable"

#### Philipp Poeml

• Professor
• Posts: 222
##### Re: Conversion from wt% to atom% without normalization
« Reply #4 on: June 04, 2022, 02:24:24 PM »
Great idea Nicholas and thanks John for implementing. Let's test that!