ONNX denotations and metadata keys

Several strings in an ONNX file have standard values. They come from TypeDenotation.md, DimensionDenotation.md, MetadataProps.md and IR.md in the ONNX repository. The explorer adds these meanings to the notes on the fields concerned.

Type denotations

TypeProto.denotation says what a value is, beyond its element type and shape.

Value	Meaning
`TENSOR`	A plain, general-purpose tensor.
`IMAGE`	An image. Read the dimension denotations for its layout, and the metadata properties below for its pixel format and range.
`AUDIO`	An audio clip.
`TEXT`	A block of text.

Dimension denotations

TensorShapeProto.Dimension.denotation says what one axis of a tensor means, in a way that does not depend on the model. The names are coarse on purpose: height and width are both features.

Value	Meaning
`DATA_BATCH`	The batch dimension: N in NCHW.
`DATA_CHANNEL`	The channel dimension: C.
`DATA_TIME`	A time dimension.
`DATA_FEATURE`	A feature dimension: the spatial H and W, or the feature dimension of an RNN.
`FILTER_IN_CHANNEL`	A filter’s in-channel dimension; matches the channels of the input feature maps.
`FILTER_OUT_CHANNEL`	A filter’s out-channel dimension; matches the channels of the output feature maps.
`FILTER_SPATIAL`	A filter’s spatial dimension.

Operators pass denotations along by their own rules: Transpose gives output dimension i the denotation of input perm[i], and a 2-D AveragePool expects [DATA_BATCH, DATA_CHANNEL, DATA_FEATURE, DATA_FEATURE]; a mismatch is an error for a consumer that checks.

Metadata properties

metadata_props are free-form key and value strings on the model, graph, nodes, value infos and tensors. Keys should be distinct. ONNX recommends that keys be qualified with a reverse-DNS prefix, such as ai.onnxruntime.key1. These keys are defined:

Key	Meaning
`model_author`	The personal name of the author(s) of the model, and/or their organisations.
`model_license`	The well-known name or URL of the licence under which the model is made available.

Image metadata

For a tensor whose type is denoted IMAGE, ONNX says these keys should be given. Keys and values are case-insensitive; they apply to all types that share the denotation.

Key	Value	Meaning
`Image.BitmapPixelFormat`	`Gray8`	One channel, grey, 8 bits.
	`Rgb8`	Three channels, RGB order, 8 bits, no alpha.
	`Bgr8`	Three channels, BGR order, 8 bits, no alpha.
	`Rgba8`	Four channels, RGBA order, 8 bits, straight alpha.
	`Bgra8`	Four channels, BGRA order, 8 bits, straight alpha.
`Image.ColorSpaceGamma`	`Linear`	Gamma 1.0.
`Image.ColorSpaceGamma`	`SRGB`	Gamma 2.2.
`Image.NominalPixelRange`	`NominalRange_0_255`	0 to 255 for 8-bit samples.
	`Normalized_0_1`	0 to 1, normalised.
	`Normalized_1_1`	−1 to 1, normalised.
	`NominalRange_16_235`	16 to 235 for 8-bit samples.

Optional inputs and variadics

Two ways of leaving out an input are defined by IR.md:

Static optional: a trailing optional input or output is simply left out of the node’s list.
Dynamic optional (IR 8): an Optional value holds or does not hold a value at run time; Optional and OptionalGetElement convert between the two forms explicitly.

Where an operator lists a variadic input, the node supplies at least as many inputs as the operator’s minimum arity. An empty name in a node’s input list marks an omitted optional input that is not at the end.

Multi-device annotations

Device configurations (IR 11) describe how a node is spread over devices. ONNX says they are “hints to execution backends and do not affect the computational semantics”, and that backends may ignore them.