Issue with EMEBSDDI in EMsoft 5.0: incorrect quantitative orientations

[christiankwalters]

Hi everyone,

I am encountering an issue with the EMEBSDDI program in EMsoft 5.0, and I would be grateful for any tips or assistance the community here might be able to provide. My attempts to troubleshoot this myself over the past several weeks have been unsuccessful so far.

My dataset is a coarse-grained cubic material with point group m-3m. Indexing the patterns with my institution's Oxford EBSD system returns the following IPF-Z map when plotted in either MTEX or CHANNEL5:

I am then taking the binned (311 x 256) patterns and running them through EMEBSDDI with the following pattern center conversion: --- In Oxford coordinates, (x, y, z*) = (0.520, 0.551, 0.659) --- In EMsoft coordinates, (xpc, ypc, L) = (-6.22, 13.055, 15552) with a binned pixel size of 75.88 microns.

The top portion of the EMsoft indexed dataset is attached below. Qualitatively, the indexing results seem good; the unindexed pixels have been "filled in." Any stray pixels can be attributed to small precipitates. However, the quantitative coloring of the EMsoft IPF-Z map is visibly quite misoriented from AZtec's results. This IPF-Z map has been plotted in MTEX, but CHANNEL5 returns the same result.

For reference, here is MTEX's IPF colorkey.

I should note that I am using Python to bin the experimental patterns separately and save them as a binary .data file prior to indexing. This process involves importing the experimental patterns from the Oxford .h5oina file, performing the pixel binning, and writing them as 32-bit floats to disk, where both the navigational and signal dimensions are flattened in row-major form. I initially suspected that this process might be responsible for the issues I am seeing, but kikuchipy is able to do the pattern matching on the same .data file with no issues. These results show nice agreement with AZtec's.

Are there any strategies I could try next to troubleshoot this issue? Thanks in advance for your help.

[hakonanes]

Hi @christiankwalters,

based on the orientation maps, your results from EMsoft seem consistent, while there is a slight (systematic?) change in the orientation. Might this be related to your projection center? How did you arrive at y_pc = 13.055? I get y_pc = (Nx y) - (Ny / 2) = (311 * 0.551) - (256 / 2) = 43.361. I based this expression on the assumptions listed in kikuchipy's docs. Such a change in PC should cause a change in orientation.

[christiankwalters]

Thanks, @hakonanes, for your quick reply!

Your suggested value of y_pc was exactly right, and my issue seems to be resolved now. Indexing the same portion of the scan shows good agreement between the EMsoft results and those of AZtec/kikuchipy.

I think I understand the source of my confusion now. In the Pattern Simulation wiki page for EMsoft, the pattern center relations agree with your calculation for y_pc:

pcx = Nx x - Nx/2 pcy = Nx y - Ny/2 L = W z*.

In my case, I was performing these calculations based on M. Jackson's 2019 paper, which has the relation as y_pc = (Ny y) - (Ny/2) = 256*(0.551 - 0.5) = 13.056.

Maybe the correct procedure has changed since 2019. In any event, I'm glad this orientation issue seems to be fixed. Thanks very much for your help!

Best, Christian

[hakonanes]

Great! I'm glad this solved your issue.

The beta version of EMsoft v6.0 (EMsoftOO) has a new PC conversion program EMEBSDpc (https://github.com/EMsoft-org/EMsoftOO/blob/develop/NamelistTemplates/EMEBSDpc.template). This and the wiki should have the most updated conversions.

An alternative is to use kikuchipy, which I did to check your PC (current version is v0.8.4):

>>> import kikuchipy as kp
>>> det = kp.detectors.EBSDDetector(
...     (256, 311), pc=[0.52, 0.551, 0.659], convention="oxford", px_size=75.88
... )
>>> det.pc_emsoft()
array([[-6.22000000e+00,  4.33610000e+01,  1.55515301e+04]])

[marcdegraef]

Hi everyone,

yes, the EMsoft <-> Oxford conversion was changed after the 2019 paper because Oxford made a change (if I remember correctly)... my apologies if that caused you to go on the wrong path for a while...

Also, you should be able to directly read the .h5oina file if you use EMsoftOO v6.0 ...

I'm glad it is resolved now.

Regards, Marc.

On 5/3/23 3:48 AM, Håkon Wiik Ånes wrote:

Great! I'm glad this solved your issue.

The beta version of EMsoft v6.0 (EMsoftOO) has a new PC conversion program |EMEBSDpc| (https://github.com/EMsoft-org/EMsoftOO/blob/develop/NamelistTemplates/EMEBSDpc.template). This and the wiki should have the most updated conversions.

An alternative is to use kikuchipy, which I did to check your PC (current version is v0.8.4):

import kikuchipy as kp det = kp.detectors.EBSDDetector( ... (256,311),pc=[0.52,0.551,0.659],convention="oxford",px_size=75.88 ... ) det.pc_emsoft() array([[-6.22000000e+00,4.33610000e+01,1.55515301e+04]])

— Reply to this email directly, view it on GitHub https://github.com/EMsoft-org/EMsoft/issues/170#issuecomment-1532591021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB26VWABCD76YFTD4OAGX4LXEIEVDANCNFSM6AAAAAAXSFLQQY. You are receiving this because you are subscribed to this thread.Message ID: @.***>