.. auto-generated by dev_tools.docs.nxdl from the NXDL source contributed_definitions/NXem_ebsd.nxdl.xml -- DO NOT EDIT
.. index::
! NXem_ebsd (base class)
! em_ebsd (base class)
see: em_ebsd (base class); NXem_ebsd
.. _NXem_ebsd:
=========
NXem_ebsd
=========
**Status**:
base class, extends :ref:`NXem_method`
**Description**:
.. collapse:: 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 :ref:`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.
**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.
**Groups cited**:
:ref:`NXcrystal_structure`, :ref:`NXdata`, :ref:`NXem_conventions`, :ref:`NXms_odf_set`, :ref:`NXms_pf_set`, :ref:`NXms_recon`, :ref:`NXprocess`, :ref:`NXrotation_set`, :ref:`NXserialized`
.. index:: NXem_conventions (base class); used in base class, NXprocess (base class); used in base class, NXserialized (base class); used in base class, NXcrystal_structure (base class); used in base class, NXrotation_set (base class); used in base class, NXms_odf_set (base class); used in base class, NXms_pf_set (base class); used in base class, NXms_recon (base class); used in base class, NXdata (base class); used in base class
**Structure**:
.. _/NXem_ebsd/conventions-group:
**conventions**: (optional) :ref:`NXem_conventions`
.. _/NXem_ebsd/measurement-group:
**measurement**: (optional) :ref:`NXprocess` :ref:`⤆ </NXem_method/PROCESS-group>`
.. collapse:: 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.
.. _/NXem_ebsd/measurement@depends_on-attribute:
.. index:: depends_on (group attribute)
**@depends_on**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: If available and it is stored in an instance of an application definition ...
If available and it is stored in an instance of an application definition
this field gives the path of an :ref:`NXdata` where the pattern are stored.
.. _/NXem_ebsd/measurement/time-field:
.. index:: time (field)
**time**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` {units=\ :ref:`NX_TIME <NX_TIME>`}
.. collapse:: 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 have have 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
of annealing, 30 minutes, 6 hours, or 24 hours of annealing.
.. _/NXem_ebsd/measurement/time@depends_on-attribute:
.. index:: depends_on (field attribute)
**@depends_on**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: Timestamp relative to which time was counted to aid ...
Timestamp relative to which time was counted to aid
converting between time and timestamp.
.. _/NXem_ebsd/measurement/source-group:
**source**: (optional) :ref:`NXserialized`
.. collapse:: 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).
.. _/NXem_ebsd/simulation-group:
**simulation**: (optional) :ref:`NXprocess` :ref:`⤆ </NXem_method/PROCESS-group>`
.. collapse:: 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 :ref:`NXem_sim`.
.. _/NXem_ebsd/simulation@depends_on-attribute:
.. index:: depends_on (group attribute)
**@depends_on**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: If available and it is stored in an instance of an application definition ...
If available and it is stored in an instance of an application definition
this field gives the path of an :ref:`NXimage_r_set_diff`
where the simulated pattern are stored.
.. _/NXem_ebsd/simulation/source-group:
**source**: (optional) :ref:`NXserialized`
.. collapse:: 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.
.. _/NXem_ebsd/calibration-group:
**calibration**: (optional) :ref:`NXprocess` :ref:`⤆ </NXem_method/PROCESS-group>`
.. collapse:: 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.
:ref:`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
:ref:`NXem_ebsd` solves in that all conventions can be specified explicitly.
.. _/NXem_ebsd/calibration@depends_on-attribute:
.. index:: depends_on (group attribute)
**@depends_on**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: If available and it is stored in an instance of an application definition ...
If available and it is stored in an instance of an application definition
this field gives the path of an :ref:`NXem_msr` where the calibration is
stored.
.. _/NXem_ebsd/calibration/source-group:
**source**: (optional) :ref:`NXserialized`
Reference to a digital resource where the calibration is stored.
.. _/NXem_ebsd/indexing-group:
**indexing**: (optional) :ref:`NXprocess` :ref:`⤆ </NXem_method/PROCESS-group>`
.. collapse:: 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. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_).
Recently, dictionary-based indexing methods are increasingly becoming used
partly driven by the interest to use artificial intelligence algorithms.
.. _/NXem_ebsd/indexing/method-field:
.. index:: method (field)
**method**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: Principal algorithm used for indexing. ...
Principal algorithm used for indexing.
Any of these values:
* ``undefined``
* ``hough_transform``
* ``dictionary``
* ``radon_transform``
* ``other``
.. _/NXem_ebsd/indexing/status-field:
.. index:: status (field)
**status**: (optional) :ref:`NX_UINT <NX_UINT>` (Rank: 1, Dimensions: [n_sc]) {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`}
.. collapse:: 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
.. _/NXem_ebsd/indexing/n_phases_per_scan_point-field:
.. index:: n_phases_per_scan_point (field)
**n_phases_per_scan_point**: (optional) :ref:`NX_INT <NX_INT>` (Rank: 1, Dimensions: [n_sc]) {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`}
.. collapse:: 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.
.. _/NXem_ebsd/indexing/phase_identifier-field:
.. index:: phase_identifier (field)
**phase_identifier**: (optional) :ref:`NX_INT <NX_INT>` (Rank: 1, Dimensions: [i]) {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`}
.. collapse:: 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
.. _/NXem_ebsd/indexing/phase_matching-field:
.. index:: phase_matching (field)
**phase_matching**: (optional) :ref:`NX_INT <NX_INT>` (Rank: 1, Dimensions: [i]) {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`}
.. collapse:: 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.
.. _/NXem_ebsd/indexing/phase_matching_descriptor-field:
.. index:: phase_matching_descriptor (field)
**phase_matching_descriptor**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: 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``
.. _/NXem_ebsd/indexing/scan_point_positions-field:
.. index:: scan_point_positions (field)
**scan_point_positions**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` (Rank: 2, Dimensions: [n_sc, 2]) {units=\ :ref:`NX_LENGTH <NX_LENGTH>`}
.. collapse:: Calibrated center positions of each scan point ...
Calibrated center positions of each scan point
in the sample surface reference system.
.. _/NXem_ebsd/indexing/indexing_rate-field:
.. index:: indexing_rate (field)
**indexing_rate**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` {units=\ :ref:`NX_DIMENSIONLESS <NX_DIMENSIONLESS>`}
.. collapse:: 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.
.. _/NXem_ebsd/indexing/number_of_scan_points-field:
.. index:: number_of_scan_points (field)
**number_of_scan_points**: (optional) :ref:`NX_UINT <NX_UINT>` {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`}
Number of scan points in the original mapping.
.. _/NXem_ebsd/indexing/source-group:
**source**: (optional) :ref:`NXserialized`
.. collapse:: 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.
.. _/NXem_ebsd/indexing/background_correction-group:
**background_correction**: (optional) :ref:`NXprocess`
Details about the background correction applied to each Kikuchi pattern.
.. _/NXem_ebsd/indexing/binning-group:
**binning**: (optional) :ref:`NXprocess`
Binning i.e. downsampling of the pattern.
.. _/NXem_ebsd/indexing/parameter-group:
**parameter**: (optional) :ref:`NXprocess`
Specific parameter relevant only for certain algorithms used.
.. _/NXem_ebsd/indexing/phaseID-group:
**phaseID**: (optional) :ref:`NXcrystal_structure`
.. collapse:: 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 :ref:`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.
.. _/NXem_ebsd/indexing/rotation_set-group:
**rotation_set**: (optional) :ref:`NXrotation_set`
.. _/NXem_ebsd/indexing/odf-group:
**odf**: (optional) :ref:`NXms_odf_set`
.. _/NXem_ebsd/indexing/pf-group:
**pf**: (optional) :ref:`NXms_pf_set`
.. _/NXem_ebsd/indexing/microstructureID-group:
**microstructureID**: (optional) :ref:`NXms_recon`
.. _/NXem_ebsd/indexing/roi-group:
**roi**: (optional) :ref:`NXdata`
An overview of the entire ROI.
.. _/NXem_ebsd/indexing/roi/descriptor-field:
.. index:: descriptor (field)
**descriptor**: (optional) :ref:`NX_CHAR <NX_CHAR>`
.. collapse:: Descriptor representing the image contrast. ...
Descriptor representing the image contrast.
Any of these values:
* ``normalized_band_contrast``
* ``normalized_confidence_index``
* ``normalized_mean_angular_deviation``
.. _/NXem_ebsd/indexing/roi/title-field:
.. index:: title (field)
**title**: (optional) :ref:`NX_CHAR <NX_CHAR>` :ref:`⤆ </NXdata/title-field>`
Title of the default plot.
.. _/NXem_ebsd/indexing/roi/data-field:
.. index:: data (field)
**data**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` (Rank: 2, Dimensions: [n_y, n_x]) {units=\ :ref:`NX_UNITLESS <NX_UNITLESS>`} :ref:`⤆ </NXdata/DATA-field>`
Descriptor values displaying the ROI.
.. _/NXem_ebsd/indexing/roi/data@long_name-attribute:
.. index:: long_name (field attribute)
**@long_name**: (optional) :ref:`NX_CHAR <NX_CHAR>` :ref:`⤆ </NXdata/DATA@long_name-attribute>`
Descriptor values.
.. _/NXem_ebsd/indexing/roi/axis_y-field:
.. index:: axis_y (field)
**axis_y**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` (Rank: 1, Dimensions: [n_y]) {units=\ :ref:`NX_LENGTH <NX_LENGTH>`} :ref:`⤆ </NXdata/AXISNAME-field>`
Calibrated coordinate along the y-axis.
.. _/NXem_ebsd/indexing/roi/axis_y@long_name-attribute:
.. index:: long_name (field attribute)
**@long_name**: (optional) :ref:`NX_CHAR <NX_CHAR>` :ref:`⤆ </NXdata/AXISNAME@long_name-attribute>`
Label for the y axis
.. _/NXem_ebsd/indexing/roi/axis_x-field:
.. index:: axis_x (field)
**axis_x**: (optional) :ref:`NX_NUMBER <NX_NUMBER>` (Rank: 1, Dimensions: [n_x]) {units=\ :ref:`NX_LENGTH <NX_LENGTH>`} :ref:`⤆ </NXdata/AXISNAME-field>`
Calibrated coordinate along the x-axis.
.. _/NXem_ebsd/indexing/roi/axis_x@long_name-attribute:
.. index:: long_name (field attribute)
**@long_name**: (optional) :ref:`NX_CHAR <NX_CHAR>` :ref:`⤆ </NXdata/AXISNAME@long_name-attribute>`
Label for the x axis
Hypertext Anchors
-----------------
List of hypertext anchors for all groups, fields,
attributes, and links defined in this class.
* :ref:`/NXem_ebsd/calibration-group </NXem_ebsd/calibration-group>`
* :ref:`/NXem_ebsd/calibration/source-group </NXem_ebsd/calibration/source-group>`
* :ref:`/NXem_ebsd/calibration@depends_on-attribute </NXem_ebsd/calibration@depends_on-attribute>`
* :ref:`/NXem_ebsd/conventions-group </NXem_ebsd/conventions-group>`
* :ref:`/NXem_ebsd/indexing-group </NXem_ebsd/indexing-group>`
* :ref:`/NXem_ebsd/indexing/background_correction-group </NXem_ebsd/indexing/background_correction-group>`
* :ref:`/NXem_ebsd/indexing/binning-group </NXem_ebsd/indexing/binning-group>`
* :ref:`/NXem_ebsd/indexing/indexing_rate-field </NXem_ebsd/indexing/indexing_rate-field>`
* :ref:`/NXem_ebsd/indexing/method-field </NXem_ebsd/indexing/method-field>`
* :ref:`/NXem_ebsd/indexing/microstructureID-group </NXem_ebsd/indexing/microstructureID-group>`
* :ref:`/NXem_ebsd/indexing/n_phases_per_scan_point-field </NXem_ebsd/indexing/n_phases_per_scan_point-field>`
* :ref:`/NXem_ebsd/indexing/number_of_scan_points-field </NXem_ebsd/indexing/number_of_scan_points-field>`
* :ref:`/NXem_ebsd/indexing/odf-group </NXem_ebsd/indexing/odf-group>`
* :ref:`/NXem_ebsd/indexing/parameter-group </NXem_ebsd/indexing/parameter-group>`
* :ref:`/NXem_ebsd/indexing/pf-group </NXem_ebsd/indexing/pf-group>`
* :ref:`/NXem_ebsd/indexing/phase_identifier-field </NXem_ebsd/indexing/phase_identifier-field>`
* :ref:`/NXem_ebsd/indexing/phase_matching-field </NXem_ebsd/indexing/phase_matching-field>`
* :ref:`/NXem_ebsd/indexing/phase_matching_descriptor-field </NXem_ebsd/indexing/phase_matching_descriptor-field>`
* :ref:`/NXem_ebsd/indexing/phaseID-group </NXem_ebsd/indexing/phaseID-group>`
* :ref:`/NXem_ebsd/indexing/roi-group </NXem_ebsd/indexing/roi-group>`
* :ref:`/NXem_ebsd/indexing/roi/axis_x-field </NXem_ebsd/indexing/roi/axis_x-field>`
* :ref:`/NXem_ebsd/indexing/roi/axis_x@long_name-attribute </NXem_ebsd/indexing/roi/axis_x@long_name-attribute>`
* :ref:`/NXem_ebsd/indexing/roi/axis_y-field </NXem_ebsd/indexing/roi/axis_y-field>`
* :ref:`/NXem_ebsd/indexing/roi/axis_y@long_name-attribute </NXem_ebsd/indexing/roi/axis_y@long_name-attribute>`
* :ref:`/NXem_ebsd/indexing/roi/data-field </NXem_ebsd/indexing/roi/data-field>`
* :ref:`/NXem_ebsd/indexing/roi/data@long_name-attribute </NXem_ebsd/indexing/roi/data@long_name-attribute>`
* :ref:`/NXem_ebsd/indexing/roi/descriptor-field </NXem_ebsd/indexing/roi/descriptor-field>`
* :ref:`/NXem_ebsd/indexing/roi/title-field </NXem_ebsd/indexing/roi/title-field>`
* :ref:`/NXem_ebsd/indexing/rotation_set-group </NXem_ebsd/indexing/rotation_set-group>`
* :ref:`/NXem_ebsd/indexing/scan_point_positions-field </NXem_ebsd/indexing/scan_point_positions-field>`
* :ref:`/NXem_ebsd/indexing/source-group </NXem_ebsd/indexing/source-group>`
* :ref:`/NXem_ebsd/indexing/status-field </NXem_ebsd/indexing/status-field>`
* :ref:`/NXem_ebsd/measurement-group </NXem_ebsd/measurement-group>`
* :ref:`/NXem_ebsd/measurement/source-group </NXem_ebsd/measurement/source-group>`
* :ref:`/NXem_ebsd/measurement/time-field </NXem_ebsd/measurement/time-field>`
* :ref:`/NXem_ebsd/measurement/time@depends_on-attribute </NXem_ebsd/measurement/time@depends_on-attribute>`
* :ref:`/NXem_ebsd/measurement@depends_on-attribute </NXem_ebsd/measurement@depends_on-attribute>`
* :ref:`/NXem_ebsd/simulation-group </NXem_ebsd/simulation-group>`
* :ref:`/NXem_ebsd/simulation/source-group </NXem_ebsd/simulation/source-group>`
* :ref:`/NXem_ebsd/simulation@depends_on-attribute </NXem_ebsd/simulation@depends_on-attribute>`
**NXDL Source**:
https://github.com/FAIRmat-NFDI/nexus_definitions/tree/fairmat/contributed_definitions/NXem_ebsd.nxdl.xml