2.3.3.3.112. NXem_ebsd

Status:

base class, extends NXem_method

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 to set the desired diffraction conditions.

Users then typically configure the microscope for collecting higher quality data and push in the EBSD detector. 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 start the measurement queue.

Nowadays, this is in most cases an automated process. The pattern collection runs during the allocated microscope session until the queue finishes or gets interrupted by errors or the next user terminates sessions which run over time.

Kikuchi pattern surplus eventually multi-modal detector signals are collected and usually indexed on-the-fly. Patterns may be stored or not so one should not assume that raw data are always stored.

Results are stored in files, which afterwards are typically copied automatically or manual for archival purposes to certain storage locations or 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.

More specifically, exemplified here for electron backscatter diffraction (EBSD) we show how NeXus can be used to solve two key documentation issues so far missing in the field of EBSD.

Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted according to NXem_ebsd) stores the connection between the microscope session and the key datasets which are considered typically results of the various processing steps involved when working with EBSD data.

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 pattern, associated overview images, like secondary electron or backscattered electron images of the region-of-interest probed and many more pieces of information.

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 EBSD result. Otherwise, results would be ripped out of their context, as 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 results file in some technology-partner-specific file format but without communicating all conventions or 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) methods where a combination of mechanical or ion milling is used repetitively to measure the same region-of-interest at different depth increments. Material removal can be achieved with electron or ion polishing, using manual steps or using automated equipment like a robot system.

Three-dimensional experiments require to follow a sequence of specimen, surface preparation, and data collection steps. By nature these methods are destructive in that they either require the removal of the previously measured material region or that the sample surface can degrade 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. That is serial-sectioning is mainly 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 connected and contextualized.

Eventual tomography methods also use such a workflow because first diffraction images are collected (e.g. with X-ray) and then these imagres are indexed and computed into a 3D orientation mapping. The here proposed NXem_ebsd application definition contains conceptual ideas how this splitting between measurement and post-processing can be granularized also for such X-ray-based techniques, whether it be 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

Groups cited:

NXcoordinate_system, NXcrystal_structure, NXdata, NXmicrostructure_ipf, NXmicrostructure_odf, NXmicrostructure_pf, NXmicrostructure, NXprocess, NXrotation_set, NXserialized

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 is not met, the user is required to explicitly state this.

Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the base vectors of this coordinate system as Xg, Yg, Zg.

origin: (optional) NX_CHAR ⤆

Origin of the gnomonic_projection_reference_frame. ...

Origin of the gnomonic_projection_reference_frame.

Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to assume that this is coordinate Xg = 0, Yg = 0, Zg = 0.

Any of these values: undefined | in_the_pattern_centre

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

  • undefined

  • north

  • east

  • south

  • west

  • in

  • out

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

  • undefined

  • north

  • east

  • south

  • west

  • in

  • out

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

  • undefined

  • north

  • east

  • south

  • west

  • in

  • out

pattern_centre: (optional) NXprocess ⤆

Details about the definition of the pattern centre as a special point in the g ...

Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame.

Keep in mind that the gnomonic space is in virtually all cases 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 is that these degenerate if the detector region-of-interest is square-shaped. This is why instead of referring to width and height one should report as if one were to measure practically with a ruler and one is specific about in which direction positive distances are measured.

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: undefined | top | right | bottom | left

x_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: undefined | north | east | south | west

y_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: undefined | top | right | bottom | left

y_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: undefined | north | east | south | west

measurement: (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 measuring a stack of Kikuchi diffraction pattern with an electron microscope.

The most frequently collected EBSD data are captured for rectangular regions-of-interested which are sampled with regular square or hexagon-shaped pixels.

time: (optional) NX_NUMBER {units=NX_TIME}

Physical time since the beginning of a timestamp that is required to be ...

Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is to identify how all experiments in the set need to be arranged sequentially based on the time elapsed. The time is relevant to sort e.g. experiments of consecutive quasi in-situ experiments where a measurement was e.g. taken after 0 minutes, 30 minutes, 6 hours, or 24 hours of annealing.

@epoch_start: (optional) NX_CHAR

Timestamp relative to which time was counted to aid ...

Timestamp relative to which time was counted to aid converting between time and timestamp.

depends_on: (optional) NX_CHAR

If available and it is stored in an instance of an application definition th ...

If available and it is stored in an instance of an application definition this field specifies the path to an instance of NXdata where the measured patterns are stored.

source: (optional) NXserialized

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 pattern 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 a stack of Kikuchi diffraction pattern with some physical model.

This group should not be confused with a group named simulation that is however an instance of NXem_sim. Instead, the simulation group here should be used if (e.g. instead of a measurement) a stack of pattern were simulated that one wishes to use for indexing patterns.

In many practical cases where pattern are analyzed on-the-fly and dictionary indexing strategies are used, so-called master pattern(s) are used to compare measured or simulated pattern with the master pattern. In this case, master pattern are the result of a computer simulation and thus should be stored using an own properly documented entry within a simulation group as an instance of NXem_sim.

depends_on: (optional) NX_CHAR

If available and it is stored in an instance of an application definition th ...

If available and it is stored in an instance of an application definition this field specifies the path to an instance of NXimage_set where the simulated patterns are stored.

source: (optional) NXserialized

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 pattern or input (already processed EBSD data) which is now 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 tilting, EBSD detector, and the gnomonic projection have to be calibrated to achieve reliable indexing results.

Specifically, the gnomonic projection has to be calibrated. Typically, silicon or quartz crystals are used for this purpose.

Considering a system is well-calibrated, it is much more frequently the case in practice that users assume the system is calibrated (and thus usable) vs. they perform the calibration of the EBSD system.

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. Consequently, users pick from an existent library of phase candidates, i.e. NXcrystal_structure 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 this setup is made at the level of the GUI software.

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

If available and it is stored in an instance of an application definition th ...

If available and it is stored in an instance of an application definition this field specifies the path to an instance of NXem_msr where calibration is stored.

source: (optional) NXserialized

Reference to a digital resource where the calibration is stored.

indexing: (optional) NXprocess ⤆

Indexing is a data processing step performed either after or while ...

Indexing is a data processing step performed either after or while (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 EBSD pattern. Common to them is the computational step where simulated reference pattern are compared with measured or simulated patterns. These latter patterns are referred to via the measurement or simulation groups of this base class.

Quality descriptors are defined based on which an indexing algorithm yields a quantitative measure of how similar measured and reference pattern are, and thus if no, one, or multiple so-called solutions were found.

Assumed or simulated pattern are simulated using kinematic or dynamical theory of electron diffraction delivering master pattern.

The Hough transform is essentially a discretized Radon transform (for details see M. van Ginkel et al.). Recently, dictionary-based indexing methods are increasingly becoming used partly driven by the interest to use artificial intelligence algorithms.

method: (optional) NX_CHAR

Principal algorithm used for indexing. ...

Principal algorithm used for indexing.

Any of these values:

  • undefined

  • hough_transform

  • dictionary

  • radon_transform

  • other

status: (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. Practically useful is to use an uint8 mask.

  • 0 - Not analyzed

  • 1 - Too high angular deviation

  • 2 - No solution

  • 100 - Success

  • 255 - Unexpected errors

n_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 NXem_ebsd_crystal_structure_model.

In another example users may have skipped some scan points (not indexed) them at all) and/or used differing numbers of phases for different scan points.

The cumulated of this array decodes how phase_identifier and phase_matching 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), phase_identifier has as many entries as scan points and phase_matching has also as many entries as scan points.

phase_identifier: (optional) NX_INT (Rank: 1, Dimensions: [n_solutions]) {units=NX_UNITLESS}

The array n_phases_per_scan_point details how the phase_identifier ...

The array n_phases_per_scan_point details how the phase_identifier and the phase_matching arrays have to be interpreted.

For the example with a single phase phase_identifier 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 needed) that a pattern matches eventually (not equally well) sufficiently significant with multiple pattern. This can especially happen in cases of pseudosymmetry and more frequently with an improperly calibrated system or false or inaccurate phase models e.g. (ferrite, austenite). Having such field is especially relevant for recent machine learning or dictionary based indexing schemes because in combination with phase_matching these fields communicate the results in a model-agnostic way.

Depending on the n_phases_per_scan_point value phase_identifier and phase_matching arrays represent a collection of concatenated tuples, which 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 n_phases_per_scan_point

phase_matching: (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 n_phases_per_scan_point has to be specified because it details how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details.

phase_matching_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, some AI-based matching probability (other), i.e. the details are implementation-specific.

Any of these values:

  • undefined

  • confidence_index

  • mean_angular_deviation

  • other

scan_point_positions: (optional) NX_NUMBER (Rank: 2, Dimensions: [n_sc, 2]) {units=NX_LENGTH}

Calibrated center positions of each scan point ...

Calibrated center positions of each scan point in the sample surface reference system.

indexing_rate: (optional) NX_NUMBER {units=NX_DIMENSIONLESS}

Fraction of successfully indexed pattern with a phase ...

Fraction of successfully indexed pattern 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.

source: (optional) NXserialized

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 of the pattern.

parameter: (optional) NXprocess

Specific parameter relevant only for certain algorithms used.

phaseID: (optional) NXcrystal_structure

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 NXcrystal_structure in this group must have the group name prefix phase. The identifier in the name is an integer. We start counting from 1 because the value 0 is reserved for the special phase that is the null-model, i.e. the null phase, notIndexed.

rotation_set: (optional) NXrotation_set

odfID: (optional) NXmicrostructure_odf

pfID: (optional) NXmicrostructure_pf

ipfID: (optional) NXmicrostructure_ipf

microstructureID: (optional) NXmicrostructure

roi: (optional) NXdata

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_deviation

title: (optional) NX_CHAR ⤆

Title of the default plot.

data: (optional) NX_NUMBER (Rank: 2, Dimensions: [n_y, n_x]) {units=NX_UNITLESS} ⤆

Descriptor values displaying the ROI.

@long_name: (optional) NX_CHAR ⤆

Descriptor values.

axis_y: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_y]) {units=NX_LENGTH} ⤆

Calibrated coordinate along the y-axis.

@long_name: (optional) NX_CHAR ⤆

Label for the y axis

axis_x: (optional) NX_NUMBER (Rank: 1, Dimensions: [n_x]) {units=NX_LENGTH} ⤆

Calibrated coordinate along the x-axis.

@long_name: (optional) NX_CHAR ⤆

Label for the x axis

Hypertext Anchors

List of hypertext anchors for all groups, fields, attributes, and links defined in this class.

NXDL Source:

https://github.com/FAIRmat-NFDI/nexus_definitions/tree/fairmat/contributed_definitions/NXem_ebsd.nxdl.xml