3.3.1.13. NXdetector

Status:

base class, extends NXobject

Description:

A detector, detector bank, or multidetector.

Symbols:

These symbols will be used below to illustrate the coordination of the rank and ...

These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets will vary according to the situation) and the general ordering principle is slowest to fastest. The type of each dimension should follow the order of scan points, detector output (e.g. pixels), then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced by a detector at each trigger.

nP: number of scan points (only present in scanning measurements)

i: number of detector pixels in the first (slowest) direction

j: number of detector pixels in the second (faster) direction

tof: number of bins in the time-of-flight histogram

Groups cited:

NXcollection, NXcylindrical_geometry, NXdata, NXdetector_channel, NXdetector_module, NXgeometry, NXnote, NXoff_geometry, NXtransformations

Structure:

@default: (optional) NX_CHAR

Declares which child group contains a path leading ...

Declares which child group contains a path leading to a NXdata group.

It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion.

time_of_flight: (optional) NX_FLOAT (Rank: 1, Dimensions: [tof+1]) {units=NX_TIME_OF_FLIGHT}

Total time of flight

@axis: (optional) NX_POSINT

Obligatory value: 3

@primary: (optional) NX_POSINT

Obligatory value: 1

@long_name: (optional) NX_CHAR

Total time of flight

raw_time_of_flight: (optional) NX_INT (Rank: 1, Dimensions: [tof+1]) {units=NX_PULSES}

In DAQ clock pulses

@frequency: (optional) NX_NUMBER

Clock frequency in Hz

detector_number: (optional) NX_INT

Identifier for detector (pixels) ...

Identifier for detector (pixels) Can be multidimensional, if needed

data: (optional) NX_NUMBER (Rank: 4, Dimensions: [nP, i, j, tof]) {units=NX_ANY}

Data values from the detector. The rank and dimension ordering should follow a ...

Data values from the detector. The rank and dimension ordering should follow a principle of slowest to fastest measurement axes and may be explicitly specified in application definitions.

Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single scan-axis in the data array, especially if the scan pattern doesn’t fit a rectangular array nicely. Repetition of an experiment in a time series tends to be used similar to a slow scan axis and so will often be in the first dimension of the data array.

The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data will add the corresponding number of dimensions. Note that the detector dimensions don’t necessarily have to be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide.

Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array.

The type of each dimension should should follow the order of scan points, detector pixels, then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) shown here are merely illustrative of coordination between related datasets.

@long_name: (optional) NX_CHAR

Title of measurement

@check_sum: (optional) NX_INT

Integral of data as check of data integrity

data_errors: (optional) NX_NUMBER (Rank: 4, Dimensions: [nP, i, j, tof]) {units=NX_ANY}

The best estimate of the uncertainty in the data value (array size should matc ...

The best estimate of the uncertainty in the data value (array size should match the data field). Where possible, this should be the standard deviation, which has the same units as the data. The form data_error is deprecated.

x_pixel_offset: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_LENGTH}

Offset from the detector center in x-direction. ...

Offset from the detector center in x-direction. Can be multidimensional when needed.

@axis: (optional) NX_POSINT

Obligatory value: 1

@primary: (optional) NX_POSINT

Obligatory value: 1

@long_name: (optional) NX_CHAR

x-axis offset from detector center

y_pixel_offset: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_LENGTH}

Offset from the detector center in the y-direction. ...

Offset from the detector center in the y-direction. Can be multidimensional when different values are required for each pixel.

@axis: (optional) NX_POSINT

Obligatory value: 2

@primary: (optional) NX_POSINT

Obligatory value: 1

@long_name: (optional) NX_CHAR

y-axis offset from detector center

z_pixel_offset: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_LENGTH}

Offset from the detector center in the z-direction. ...

Offset from the detector center in the z-direction. Can be multidimensional when different values are required for each pixel.

@axis: (optional) NX_POSINT

Obligatory value: 3

@primary: (optional) NX_POSINT

Obligatory value: 1

@long_name: (optional) NX_CHAR

y-axis offset from detector center

distance: (optional) NX_FLOAT (Rank: 3, Dimensions: [nP, i, j]) {units=NX_LENGTH}

This is the distance to the previous component in the ...

This is the distance to the previous component in the instrument; most often the sample. The usage depends on the nature of the detector: Most often it is the distance of the detector assembly. But there are irregular detectors. In this case the distance must be specified for each detector pixel.

Note, it is recommended to use NXtransformations instead.

polar_angle: (optional) NX_FLOAT (Rank: 3, Dimensions: [nP, i, j]) {units=NX_ANGLE}

This is the polar angle of the detector towards the previous ...

This is the polar angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the nature of the detector. Most often it is the polar_angle of the detector assembly. But there are irregular detectors. In this case, the polar_angle must be specified for each detector pixel.

Note, it is recommended to use NXtransformations instead.

azimuthal_angle: (optional) NX_FLOAT (Rank: 3, Dimensions: [nP, i, j]) {units=NX_ANGLE}

This is the azimuthal angle angle of the detector towards ...

This is the azimuthal angle angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the nature of the detector. Most often it is the azimuthal_angle of the detector assembly. But there are irregular detectors. In this case, the azimuthal_angle must be specified for each detector pixel.

Note, it is recommended to use NXtransformations instead.

description: (optional) NX_CHAR

name/manufacturer/model/etc. information

serial_number: (optional) NX_CHAR

Serial number for the detector

local_name: (optional) NX_CHAR

Local name for the detector

solid_angle: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_SOLID_ANGLE}

Solid angle subtended by the detector at the sample

x_pixel_size: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_LENGTH}

Size of each detector pixel. If it is scalar all pixels are the same size.

y_pixel_size: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_LENGTH}

Size of each detector pixel. If it is scalar all pixels are the same size

dead_time: (optional) NX_FLOAT (Rank: 3, Dimensions: [nP, i, j]) {units=NX_TIME}

Detector dead time

gas_pressure: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_PRESSURE}

Detector gas pressure

detection_gas_path: (optional) NX_FLOAT {units=NX_LENGTH}

maximum drift space dimension

crate: (optional) NX_INT (Rank: 2, Dimensions: [i, j])

Crate number of detector

@local_name: (optional) NX_CHAR

Equivalent local term

slot: (optional) NX_INT (Rank: 2, Dimensions: [i, j])

Slot number of detector

@local_name: (optional) NX_CHAR

Equivalent local term

input: (optional) NX_INT (Rank: 2, Dimensions: [i, j])

Input number of detector

@local_name: (optional) NX_CHAR

Equivalent local term

type: (optional) NX_CHAR

Description of type such as He3 gas cylinder, He3 PSD, scintillator, ...

Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, …

real_time: (optional) NX_NUMBER (Rank: 3, Dimensions: [nP, i, j]) {units=NX_TIME}

Real-time of the exposure (use this if exposure time varies for ...

Real-time of the exposure (use this if exposure time varies for each array element, otherwise use count_time field).

Most often there is a single real time value that is constant across an entire image frame. In such cases, only a 1-D array is needed. But there are detectors in which the real time changes per pixel. In that case, more than one dimension is needed. Therefore the rank of this field should be less than or equal to (detector rank + 1).

start_time: (optional) NX_FLOAT (Rank: 1, Dimensions: [nP]) {units=NX_TIME}

start time for each frame, with the start attribute as absolute reference

@start: (optional) NX_DATE_TIME

stop_time: (optional) NX_FLOAT (Rank: 1, Dimensions: [nP]) {units=NX_TIME}

stop time for each frame, with the start attribute as absolute reference

@start: (optional) NX_DATE_TIME

calibration_date: (optional) NX_DATE_TIME

date of last calibration (geometry and/or efficiency) measurements

layout: (optional) NX_CHAR

How the detector is represented ...

How the detector is represented

Any of these values: point | linear | area

count_time: (optional) NX_NUMBER (Rank: 1, Dimensions: [nP]) {units=NX_TIME}

Elapsed actual counting time

sequence_number: (optional) NX_INT (Rank: 1, Dimensions: [nP])

In order to properly sort the order of the images taken in (for ...

In order to properly sort the order of the images taken in (for example) a tomography experiment, a sequence number is stored with each image.

beam_center_x: (optional) NX_FLOAT {units=NX_LENGTH}

This is the x position where the direct beam would hit the detector. ...

This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute.

beam_center_y: (optional) NX_FLOAT {units=NX_LENGTH}

This is the y position where the direct beam would hit the detector. ...

This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute.

frame_start_number: (optional) NX_INT

This is the start number of the first frame of a scan. In protein crystallogra ...

This is the start number of the first frame of a scan. In protein crystallography measurements one often scans a couple of frames on a give sample, then does something else, then returns to the same sample and scans some more frames. Each time with a new data file. This number helps concatenating such measurements.

diameter: (optional) NX_FLOAT {units=NX_LENGTH}

The diameter of a cylindrical detector

acquisition_mode: (optional) NX_CHAR

The acquisition mode of the detector. ...

The acquisition mode of the detector.

Any of these values:

  • gated

  • triggered

  • summed

  • event

  • histogrammed

  • decimated

angular_calibration_applied: (optional) NX_BOOLEAN

True when the angular calibration has been applied in the ...

True when the angular calibration has been applied in the electronics, false otherwise.

angular_calibration: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j])

Angular calibration data.

flatfield_applied: (optional) NX_BOOLEAN

True when the flat field correction has been applied in the ...

True when the flat field correction has been applied in the electronics, false otherwise.

flatfield: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j])

Flat field correction data.

flatfield_errors: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j])

Errors of the flat field correction data. ...

Errors of the flat field correction data. The form flatfield_error is deprecated.

pixel_mask_applied: (optional) NX_BOOLEAN

True when the pixel mask correction has been applied in the ...

True when the pixel mask correction has been applied in the electronics, false otherwise.

pixel_mask: (optional) NX_INT (Rank: 2, Dimensions: [i, j])

The 32-bit pixel mask for the detector. Can be either one mask ...

The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be an array with indices np, i, j).

Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirable pixels. They have the following meaning:

  • bit 0: gap (pixel with no sensor)

  • bit 1: dead

  • bit 2: under responding

  • bit 3: over responding

  • bit 4: noisy

  • bit 5: -undefined-

  • bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others)

  • bit 7: -undefined-

  • bit 8: user defined mask (e.g. around beamstop)

  • bits 9-30: -undefined-

  • bit 31: virtual pixel (corner pixel with interpolated value)

Normal data analysis software would not take pixels into account when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper two bytes would indicate special pixel properties that normally would not be a sole reason to reject the intensity value (unless lower bits are set.

If the full bit depths is not required, providing a mask with fewer bits is permissible.

If needed, additional pixel masks can be specified by including additional entries named pixel_mask_N, where N is an integer. For example, a general bad pixel mask could be specified in pixel_mask that indicates noisy and dead pixels, and an additional pixel mask from experiment-specific shadowing could be specified in pixel_mask_2. The cumulative mask is the bitwise OR of pixel_mask and any pixel_mask_N entries.

image_key: (optional) NX_INT (Rank: 1, Dimensions: [np])

This field allow to distinguish different types of exposure to the same detect ...

This field allow to distinguish different types of exposure to the same detector “data” field. Some techniques require frequent (re-)calibration inbetween measuremnts and this way of recording the different measurements preserves the chronological order with is important for correct processing.

This is used for example in tomography (:ref:`NXtomo) sample projections, dark and flat images, a magic number is recorded per frame.

The key is as follows:

  • projection (sample) = 0

  • flat field = 1

  • dark field = 2

  • invalid = 3

  • background (no sample, but buffer where applicable) = 4

In cases where the data is of type NXlog this can also be an NXlog.

countrate_correction_applied: (optional) NX_BOOLEAN

Counting detectors usually are not able to measure all incoming particles, ...

Counting detectors usually are not able to measure all incoming particles, especially at higher count-rates. Count-rate correction is applied to account for these errors.

True when count-rate correction has been applied, false otherwise.

countrate_correction_lookup_table: (optional) NX_NUMBER (Rank: 1, Dimensions: [m])

The countrate_correction_lookup_table defines the LUT used for count-rate ...

The countrate_correction_lookup_table defines the LUT used for count-rate correction. It maps a measured count \(c\) to its corrected value \(countrate\_correction\_lookup\_table[c]\).

\(m\) denotes the length of the table.

virtual_pixel_interpolation_applied: (optional) NX_BOOLEAN

True when virtual pixel interpolation has been applied, false otherwise. ...

True when virtual pixel interpolation has been applied, false otherwise.

When virtual pixel interpolation is applied, values of some pixels may contain interpolated values. For example, to account for space between readout chips on a module, physical pixels on edges and corners between chips may have larger sensor areas and counts may be distributed between their logical pixels.

bit_depth_readout: (optional) NX_INT

How many bits the electronics reads per pixel. ...

How many bits the electronics reads per pixel. With CCD’s and single photon counting detectors, this must not align with traditional integer sizes. This can be 4, 8, 12, 14, 16, …

detector_readout_time: (optional) NX_FLOAT {units=NX_TIME}

Time it takes to read the detector (typically milliseconds). ...

Time it takes to read the detector (typically milliseconds). This is important to know for time resolved experiments.

trigger_delay_time: (optional) NX_FLOAT {units=NX_TIME}

Time it takes to start exposure after a trigger signal has been received. ...

Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector firmware after receiving the trigger signal to when the detector starts to acquire the exposure, including any user set delay.. This is important to know for time resolved experiments.

trigger_delay_time_set: (optional) NX_FLOAT {units=NX_TIME}

User-specified trigger delay.

trigger_internal_delay_time: (optional) NX_FLOAT {units=NX_TIME}

Time it takes to start exposure after a trigger signal has been received. ...

Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector hardware after receiving the trigger signal to when the detector starts to acquire the exposure. It forms the lower boundary of the trigger_delay_time when the user does not request an additional delay.

trigger_dead_time: (optional) NX_FLOAT {units=NX_TIME}

Time during which no new trigger signal can be accepted. ...

Time during which no new trigger signal can be accepted. Typically this is the trigger_delay_time + exposure_time + readout_time. This is important to know for time resolved experiments.

frame_time: (optional) NX_FLOAT (Rank: 1, Dimensions: [nP]) {units=NX_TIME}

This is time for each frame. This is exposure_time + readout time.

gain_setting: (optional) NX_CHAR

The gain setting of the detector. This is a detector-specific value ...

The gain setting of the detector. This is a detector-specific value meant to document the gain setting of the detector during data collection, for detectors with multiple available gain settings.

Examples of gain settings include:

  • standard

  • fast

  • auto

  • high

  • medium

  • low

  • mixed high to medium

  • mixed medium to low

Developers are encouraged to use one of these terms, or to submit additional terms to add to the list.

saturation_value: (optional) NX_NUMBER

The value at which the detector goes into saturation. ...

The value at which the detector goes into saturation. Especially common to CCD detectors, the data is known to be invalid above this value.

For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value.

The precise type should match the type of the data.

underload_value: (optional) NX_NUMBER

The lowest value at which pixels for this detector would be reasonably ...

The lowest value at which pixels for this detector would be reasonably measured. The data is known to be invalid below this value.

For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value.

The precise type should match the type of the data.

number_of_cycles: (optional) NX_INT

CCD images are sometimes constructed by summing ...

CCD images are sometimes constructed by summing together multiple short exposures in the electronics. This reduces background etc. This is the number of short exposures used to sum images for an image.

sensor_material: (optional) NX_CHAR

At times, radiation is not directly sensed by the detector. ...

At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the name of this converter material.

sensor_thickness: (optional) NX_FLOAT {units=NX_LENGTH}

At times, radiation is not directly sensed by the detector. ...

At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the thickness of this converter material.

threshold_energy: (optional) NX_FLOAT {units=NX_ENERGY}

Single photon counter detectors can be adjusted ...

Single photon counter detectors can be adjusted for a certain energy range in which they work optimally. This is the energy setting for this.

depends_on: (optional) NX_CHAR

NeXus positions components by applying a set of translations and rotations ...

NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on field defines the path to the top most operation of the dependency chain or the string “.” if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere.

The reference point of the detector is the center of the first pixel. In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference.

GEOMETRY: (optional) NXgeometry

DEPRECATED: Use the field depends_on and NXtransformations to position the detector and NXoff_geometry to describe its shape instead

Position and orientation of detector

CHANNELNAME_channel: (optional) NXdetector_channel

Group containing the description and metadata for a single channel from a mult ...

Group containing the description and metadata for a single channel from a multi-channel detector.

Given an NXdata group linked as part of an NXdetector group that has an axis with named channels (see the example in NXdata), the NXdetector will have a series of NXdetector_channel groups, one for each channel, named CHANNELNAME_channel.

efficiency: (optional) NXdata

Spectral efficiency of detector with respect to e.g. wavelength

@signal: (optional) NX_CHAR ⤆

Obligatory value: efficiency

@axes: (optional) NX_CHAR ⤆

Any of these values: . | . . | . . . | . . . . | wavelength

@wavelength_indices: (optional) NX_CHAR

Obligatory value: 0

efficiency: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_DIMENSIONLESS}

efficiency of the detector

wavelength: (optional) NX_FLOAT (Rank: 2, Dimensions: [i, j]) {units=NX_WAVELENGTH}

This field can be two things: ...

This field can be two things:

  1. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated.

  2. For other detectors this field has to be seen together with the efficiency field above. For some detectors, the efficiency is wavelength dependent. Thus this field provides the wavelength axis for the efficiency field. In this use case, the efficiency and wavelength arrays must have the same dimensionality.

calibration_method: (optional) NXnote

summary of conversion of array data to pixels (e.g. polynomial ...

summary of conversion of array data to pixels (e.g. polynomial approximations) and location of details of the calibrations

data_file: (optional) NXnote

COLLECTION: (optional) NXcollection

Use this group to provide other data related to this NXdetector group.

DETECTOR_MODULE: (optional) NXdetector_module

For use in special cases where the data in NXdetector ...

For use in special cases where the data in NXdetector is represented in several parts, each with a separate geometry.

TRANSFORMATIONS: (optional) NXtransformations

This is the group recommended for holding the chain of translation ...

This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups.

Hypertext Anchors

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

NXDL Source:

https://github.com/nexusformat/definitions/blob/main/base_classes/NXdetector.nxdl.xml