2.3.3.3.92. NXem_ebsd¶
Status:
base class (contribution), extends NXprocess
Description:
Base class method-specific for Electron Backscatter Diffraction (EBSD). ...
Base class method-specific for Electron Backscatter Diffraction (EBSD).
The general procedure of an EBSD experiment is as follows: Users load the specimen, collect first a coarse image of the surface. Next, they set an approximate value for the calibrated working distance and tilt the stage into diffraction conditions.
Users then typically configure the microscope for collecting quality data. The EBSD detector is pushed in (if retractable). Subsequently, they fine tune the illumination and aberration corrector settings and select one or multiple ROIs for the microscope to machine off automatically. They configure on-the-fly indexing parameter and then typically start the measurement queue. From this point onwards typically the microscope runs automatically.
Diffraction pattern get collected until the queue finishes or gets interrupted by either errors or arrival at the end of the users’ allocated timeslot at the instrument.
Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. Once indexed, these patterns are often not stored.
Results are stored in files, which afterwards are typically copied automatically or manually for archival purposes to certain storage locations for further consumption. The result of such an EBSD measurement/experiment is a set of usually proprietary or open files from technology partners.
This NXem_ebsd base class is a proposal how to represent method-specific data, metadata, and connections between these for the research field of electron microscopy exemplified here for electron backscatter diffraction (EBSD). The base class solves two key documentation issues within the EBSD community:
Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file that is formatted according to NXem_ebsd) stores the connection between the microscope session and the key datasets which are considered typically results of the afore-mentioned steps involved in an EBSD experiment.
Different groups in NXem_ebsd make connections to data artifacts which were collected when working with electron microscopes via the NXem application definition. Using a file which stores information according to the NXem application definition has the benefit that it connects the sample, references to the sample processing, the user operating the microscope, details about the microscope session, and details about the acquisition and eventual indexing of Kikuchi patterns, associated overview images, like secondary electron or backscattered electron images of the region-of-interest probed, and many more (meta)data.
Secondly, NXem_ebsd connects and stores the conventions and reference frames which were used and which are the key to a correct mathematical interpretation of every experiment or simulation using EBSD.
Otherwise, results would be ripped out of their context like it is the current situation with many traditional studies where EBSD data were indexed on-the-fly and shared with the community only via sharing the strongly processed files with results in some formatting but without communicating all conventions used or just relying on the assumptions that colleagues likely know these conventions even though multiple definitions are possible.
NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- dimensional EBSD datasets. The third dimension is either time (in the case of quasi in-situ experiments) or space (in the case of serial-sectioning) experiments where a combination of repetitive removal of material from the surface layer to measure otherwise the same region-of-interest at different depth increments. Material removal can be achieved with mechanical, electron, or ion polishing, using manual steps or automated equipment like a robot system S. Tsai et al..
Three-dimensional experiments require to follow a sequence of specimen, surface preparation, and data collection steps. By virtue of design, these methods are destructive either because of the necessary material removal or surface degradation due to e.g. contamination or other electron-matter interaction.
For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are combined into one reconstructed stack via a computational workflow. Users collect data for each serial sectioning step via an experiment. This assures that data for associated microscope sessions and steps of data processing stay contextualized and connected.
Eventual tomography methods also use such a workflow because first diffraction images are collected (e.g. with X-ray) and then these images are indexed to process a 3D orientation mapping. Therefore, the here proposed base class can be a blueprint also for future classes to embrace our colleagues from X-ray-based techniques be it 3DXRD or HEDM.
This concept is related to term Electron Backscatter Diffraction of the EMglossary standard.
Symbols:
n_op: Number of arguments per orientation for given parameterization.
n_sc: Number of scan points.
n_z: Number of pixel along the slowest changing dimension for a rediscretized, i.e. standardized default plot orientation mapping.
n_y: Number of pixel along slow changing dimension for a rediscretized i.e. standardized default plot orientation mapping.
n_x: Number of pixel along fast changing dimension for a rediscretized i.e. standardized default plot orientation mapping.
n_solutions: Number of phase solutions
n_hkl: Number of reflectors (Miller crystallographic plane triplets).
- Groups cited:
NXcollection, NXcoordinate_system, NXdata, NXnote, NXphase, NXprocess, NXrotations
Structure:
gnomonic_reference_frame: (optional) NXcoordinate_system
Details about the gnomonic (projection) reference frame. ...
Details about the gnomonic (projection) reference frame.
It is assumed that the configuration is inspected by looking towards the sample surface. If a detector is involved, it is assumed that the configuration is inspected from a position that is located behind this detector.
If any of these assumptions are not met, the user is required to explicitly state this.
Reference https://doi.org/10.1016/j.matchar.2016.04.008 suggests to label the base vectors of this coordinate system as \(X_g, Y_g, Z_g\).
Origin of the gnomonic_reference_frame. ...
Origin of the gnomonic_reference_frame.
Reference https://doi.org/10.1016/j.matchar.2016.04.008 suggests to assume that this is coordinate \(Xg = 0, Yg = 0, Zg = 0\).
Obligatory value:
in_the_pattern_centrex_direction: (optional) NX_CHAR ⤆
Direction of the positively pointing x-axis base vector of the ...
Direction of the positively pointing x-axis base vector of the gnomonic_reference_frame.
Any of these values:
north
east
south
west
in
outy_direction: (optional) NX_CHAR ⤆
Direction of the positively pointing y-axis base vector of the ...
Direction of the positively pointing y-axis base vector of the gnomonic_reference_frame.
Any of these values:
north
east
south
west
in
outz_direction: (optional) NX_CHAR ⤆
Direction of the positively pointing z-axis base vector of the ...
Direction of the positively pointing z-axis base vector of the gnomonic_reference_frame.
Any of these values:
north
east
south
west
in
outpattern_centre: (optional) NXprocess
Details about the definition of the pattern centre as a special point in the ...
Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame.
Typically the gnomonic space is embedded in the detector space. Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane (of the detector reference frame).
When the normalization direction is the same as e.g. the detector x-axis direction one effectively normalizes in fractions of the width of the detector.
The issue with terms like width and height, though, is that these become degenerated if the detector region-of-interest is square-shaped. This is why instead of referring to width and height it is better to state explicitly which direction is considered positive when measuring distances.
For the concepts used to specify the boundary_convention it is assumed that the region-of-interest is defined by a rectangle, referring to the direction of outer-unit normals to the respective edges of this rectangle.
x_boundary_convention: (optional) NX_CHAR
From which border of the EBSP (in the detector reference frame) is the patte ...
From which border of the EBSP (in the detector reference frame) is the pattern centre’s x-position (PCx) measured.
Any of these values:
top|right|bottom|leftx_normalization_direction: (optional) NX_CHAR
In which direction are positive values for the x-axis coordinate value measu ...
In which direction are positive values for the x-axis coordinate value measured from the specified boundary.
Any of these values:
north|east|south|westy_boundary_convention: (optional) NX_CHAR
From which border of the EBSP (in the detector reference frame) is the patte ...
From which border of the EBSP (in the detector reference frame) is the pattern centre’s y-position (PCy) measured.
Any of these values:
top|right|bottom|lefty_normalization_direction: (optional) NX_CHAR
In which direction are positive values for the y-axis coordinate value measu ...
In which direction are positive values for the y-axis coordinate value measured from the specified boundary.
Any of these values:
north|east|south|westmeasurement: (optional) NXprocess
This group documents relevant details about the conditions and the ...
This group documents relevant details about the conditions and the tools for measuring diffraction patterns with an electron microscope.
The most frequently collected EBSD data are captured for rectangular regions-of-interest using a discretization into square or hexagon tiles.
time: (optional) NX_NUMBER {units=NX_TIME}
@epoch_start: (optional) NX_CHAR
depends_on: (optional) NX_CHAR
Path to an instance of NXdata where the measured patterns are stored.
Reference (e.g. path and filename) to an existent data artifact which ...
Reference (e.g. path and filename) to an existent data artifact which stores either the measured patterns or input (already processed EBSD data).
simulation: (optional) NXprocess
This group documents relevant details about the conditions and the tools ...
This group documents relevant details about the conditions and the tools used for simulating diffraction patterns with some physical model.
This group should be used if (e.g. instead of a measurement) the patterns were simulated (possibly awaiting indexing).
In many practical cases where patterns are analyzed on-the-fly and dictionary indexing strategies used, so-called master pattern(s) are used to compare measured or simulated patterns with the master patterns.
depends_on: (optional) NX_CHAR
Path to an instance of NXimage where the simulated patterns are stored.
Reference (e.g. path and filename) to an existent digital resource which ...
Reference (e.g. path and filename) to an existent digital resource which stores either the patterns or input (already processed EBSD data) that are about to become processed further as described by this NXem_ebsd instance.
calibration: (optional) NXprocess
The EBSD system, including components like the electron gun, pole-piece, ...
The EBSD system, including components like the electron gun, pole-piece, stage tilt, EBSD detector, and the gnomonic projection have to be calibrated to achieve reliable, precise, and accurate scientific results.
Specifically, the gnomonic projection has to be calibrated. Typically, standard specimens made from silicon or quartz crystals in specific orientations are used for this purpose.
Considering that a system used is already calibrated well-enough is much more frequently the case in practice than that users perform the calibration themselves (with above-mentioned standard specimens).
In the first case, the user assumes that the principle geometry of the hardware components and the settings in the control and EBSD pattern acquisition software has been calibrated already. Consequently, users pick from an existent library of phase candidates, i.e. NXunit_cell instances. Examples are reflector models as stored in CRY files (HKL/Channel 5/Flamenco).
In the second case, users calibrate the system during the session using standards (silicon, quartz, or other common specimens). There is usually one person in each lab responsible for doing such calibrations. Often this person or technician is also in charge of configuring the graphical user interface and software with which most users control and perform their analyses.
For EBSD this has key implications: Taking TSL OIM/EDAX as an example, the conventions how orientations are stored is affected by how the reference frames are configured and how this setup in the GUI.
Unfortunately, these pieces of information are not necessarily stored in the results files. In effect, key conventions become disconnected from the data so it remains the users’ obligation to remember these settings or write these down in a lab notebook. Otherwise, these metadata get lost. All these issues are a motivation and problem which NXem_ebsd solves in that all conventions can be specified explicitly.
depends_on: (optional) NX_CHAR
Path to an instance of NXem where calibration data are stored.
Reference to a digital resource where the calibration is stored.
indexing: (optional) NXprocess
Indexing is a data processing step performed either after or while (aka on-the ...
Indexing is a data processing step performed either after or while (aka on-the-fly) the beam scans the specimen. The resulting method is also known as orientation imaging microscopy (OIM).
Different algorithms can be used to index EBSP. Common to them is the computational step where simulated or theoretically assumed patterns are compared with the measured ones. These latter patterns are referred to via the measurement or simulation groups of this base class respectively.
Quality descriptors are defined based on which an indexing algorithm yields a quantitative measure of how similar measured and reference patterns are, and thus if no, one, or multiple so-called solutions were found.
Assumed or simulated patterns are simulated using kinematical or dynamical theory of electron diffraction delivering master patterns.
The Hough transform, one of the most frequently used traditional method for indexing EBSP is essentially a discretized Radon transform (for details see M. van Ginkel et al.). Recently, dictionary-based and artificial intelligence-based methods find more widespread usage for indexing.
method: (optional) NX_CHAR
Principal algorithm used for indexing. ...
Principal algorithm used for indexing.
Any of these values or a custom value (if you use a custom value, also set @custom=True):
hough_transform|dictionary|radon_transformstatus: (optional) NX_UINT (Rank: 1, Dimensions: [n_sc]) {units=NX_UNITLESS}
Which return value did the indexing algorithm yield for each scan point. ...
Which return value did the indexing algorithm yield for each scan point.
0 - Not analyzed
1 - Too high angular deviation
2 - No solution
100 - Success
255 - Unexpected errors
phases_per_scan_point: (optional) NX_INT (Rank: 1, Dimensions: [n_sc]) {units=NX_UNITLESS}
How many phases i.e. crystal structure models were used to index each ...
How many phases i.e. crystal structure models were used to index each scan point if any? Let’s assume an example to explain how this field should be used: In the simplest case users collected one pattern for each scan point and have indexed using one phase, i.e. one instance of an NXunit_cell.
In another example users may have skipped some scan points (not indexed them at all) or used differing numbers of phases for indexing different scan points.
The cumulated of this array decodes how identifier_phase and matching_phase arrays have to be interpreted. In the simplest case (one pattern per scan point, and all scan points indexed using that same single phase model), identifier_phase has as many entries as scan points and matching_phase has also as many entries as scan points.
identifier_phase: (optional) NX_INT (Rank: 1, Dimensions: [n_solutions]) {units=NX_UNITLESS}
The array phases_per_scan_point details how the identifier_phase ...
The array phases_per_scan_point details how the identifier_phase and the matching_phase arrays have to be interpreted.
For the example with a single phase identifier_phase has trivial values either 0 (no solution) or 1 (solution matching sufficiently significant with the model for phase 1).
When there are multiple phases, it is possible (although not frequently required) that a pattern matches eventually (not equally well) sufficiently significant with multiple patterns. This can especially happen in cases of pseudosymmetry and more frequently with an improperly calibrated system or false or inaccurate phase models. Having such field is especially relevant for recent dictionary- or artificial intelligence-based indexing methods to communicate the results in a model-agnostic way in combination with matching_phase.
Depending on the phases_per_scan_point value, identifier_phase and matching_phase arrays represent a collection of concatenated tuples. These are organized in sequence: The solutions for the 0-th scan point, the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to phases_per_scan_point.
matching_phase: (optional) NX_INT (Rank: 1, Dimensions: [n_solutions]) {units=NX_UNITLESS}
One-dimensional array, pattern by pattern labelling the solutions found. ...
One-dimensional array, pattern by pattern labelling the solutions found. The array phases_per_scan_point has to be specified because it details how the identifier_phase and the matching_phase arrays are interpreted. See documentation of identifier_phase for further details.
matching_phase_descriptor: (optional) NX_CHAR
Phase_matching is a descriptor for how well the solution matches or not. ...
Phase_matching is a descriptor for how well the solution matches or not. Examples can be confidence_index, mean_angular_deviation, or other.
Any of these values:
confidence_index
mean_angular_deviation
otherscan_point_positions: (optional) NX_NUMBER (Rank: 2, Dimensions: [n_sc, 2]) {units=NX_LENGTH}
Calibrated centre positions of each scan point ...
Calibrated centre positions of each scan point in the sample surface reference system.
indexing_rate: (optional) NX_NUMBER {units=NX_DIMENSIONLESS}
Fraction of successfully indexed patterns with a phase ...
Fraction of successfully indexed patterns with a phase not the null-phase vs the number_of_scan_points.
number_of_scan_points: (optional) NX_UINT {units=NX_UNITLESS}
Number of scan points in the original mapping.
This group enables to establish a logical connection between previous ...
This group enables to establish a logical connection between previous processing steps or on-the-fly-performed indexing of the EBSD map. Typically these processing steps are performed with commercial software. Therefore, in many cases a results file from this indexing is often all that is communicated and saved. These are typically files in a format specific to the instrument and its configuration.
Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5.
background_correction: (optional) NXprocess
Details about the background correction applied to each Kikuchi pattern.
binning: (optional) NXprocess
Binning i.e. downsampling to each pattern.
parameter: (optional) NXcollection ⤆
Specific parameter relevant only for certain algorithms used.
PHASE: (optional) NXphase
Details for each phase used as a model with which the patterns were ...
Details for each phase used as a model with which the patterns were indexed. Instances of NXunit_cell in this group must have the group name prefixed with phase. The identifier in the name is an integer. Start counting from 1 because the value 0 is reserved for the special phase that is the null-model, the null phase also known as notIndexed.
dspacing: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_hkl]) {units=NX_LENGTH}
Spacing between the crystallographic planes that are defined via
miller.relative_intensity: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_hkl]) {units=NX_DIMENSIONLESS}
Relative intensity for the computed diffraction intensity (signal) for the ...
Relative intensity for the computed diffraction intensity (signal) for the plane.
number_of_scan_points: (optional) NX_UINT {units=NX_UNITLESS}
In case the :ref:`NXunit_cell` base class is used with analyzed orientatio ...
In case the NXunit_cell base class is used with analyzed orientation maps this field stores how many scan points of the map were identified as matching best with this phase.
number_of_planes: (optional) NX_UINT {units=NX_UNITLESS}
How many reflectors for crystallographic planes are distinguished.
miller: (optional) NX_NUMBER (Rank: 2, Dimensions: [n_hkl, 6]) {units=NX_UNITLESS}
Miller indices :math:`(hkl)[uvw]` of the planes. ...
Miller indices \((hkl)[uvw]\) of the planes.
The first triplet specifies \((hkl)\). The second triplet specifies \([uvw]\). Miller indices refer to the Cartesian right-handed coordinate system of the unit cell.
rotation: (optional) NXrotations
An overview of the entire ROI.
descriptor: (optional) NX_CHAR
Descriptor representing the image contrast. ...
Descriptor representing the image contrast.
Any of these values:
band_contrast
confidence_index
mean_angular_deviationTitle of the default plot.
data: (optional) NX_NUMBER (Rank: 2, Dimensions: [n_y, n_x]) {units=NX_UNITLESS} ⤆
axis_y: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_y]) {units=NX_LENGTH}
axis_x: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_x]) {units=NX_LENGTH}
Hypertext Anchors¶
List of hypertext anchors for all groups, fields, attributes, and links defined in this class.
