Get desktop application:
View/edit binary Protocol Buffers messages
Attributes A named attribute containing either singular float, integer, string, graph, and tensor values, or repeated float, integer, string, graph, and tensor values. An AttributeProto MUST contain the name field, and *only one* of the following content fields, effectively enforcing a C/C++ union equivalent.
Used in:
The name field MUST be present for this version of the IR.
namespace Attribute
if ref_attr_name is not empty, ref_attr_name is the attribute name in parent function. In this case, this AttributeProto does not contain data, and it's a reference of attribute in parent scope. NOTE: This should ONLY be used in function (sub-graph). It's invalid to be used in main graph.
A human-readable documentation for this attribute. Markdown is allowed.
The type field MUST be present for this version of the IR. For 0.0.1 versions of the IR, this field was not defined, and implementations needed to use has_field hueristics to determine which value field was in use. For IR_VERSION 0.0.2 or later, this field MUST be set and match the f|i|s|t|... field in use. This change was made to accomodate proto3 implementations.
discriminator that indicates which field below is in use
Exactly ONE of the following fields must be present for this version of the IR
float
int
UTF-8 string
tensor value
graph
sparse tensor value
list of floats
list of ints
list of UTF-8 strings
list of tensors
list of graph
list of sparse tensors
Note: this enum is structurally identical to the OpSchema::AttrType enum defined in schema.h. If you rev one, you likely need to rev the other.
Used in:
Graphs A graph defines the computational logic of a model and is comprised of a parameterized list of nodes that form a directed acyclic graph based on their inputs and outputs. This is the equivalent of the "network" or "graph" in many deep learning frameworks.
Used in:
,The nodes in the graph, sorted topologically.
The name of the graph.
namespace Graph
A list of named tensor values, used to specify constant inputs of the graph. Each TensorProto entry must have a distinct name (within the list) that MAY also appear in the input list.
Initializers (see above) stored in sparse format.
A human-readable documentation for this graph. Markdown is allowed.
The inputs and outputs of the graph.
Information for the values in the graph. The ValueInfoProto.name's must be distinct. It is optional for a value to appear in value_info list.
This field carries information to indicate the mapping among a tensor and its quantization parameter tensors. For example: For tensor 'a', it may have {'SCALE_TENSOR', 'a_scale'} and {'ZERO_POINT_TENSOR', 'a_zero_point'} annotated, which means, tensor 'a_scale' and tensor 'a_zero_point' are scale and zero point of tensor 'a' in the model.
Models ModelProto is a top-level file/container format for bundling a ML model and associating its computation graph with metadata. The semantics of the model are described by the associated GraphProto.
The version of the IR this model targets. See Version enum above. This field MUST be present.
The OperatorSets this model relies on. All ModelProtos MUST have at least one entry that specifies which version of the ONNX OperatorSet is being imported. All nodes in the ModelProto's graph will bind against the operator with the same-domain/same-op_type operator with the HIGHEST version in the referenced operator sets.
The name of the framework or tool used to generate this model. This field SHOULD be present to indicate which implementation/tool/framework emitted the model.
The version of the framework or tool used to generate this model. This field SHOULD be present to indicate which implementation/tool/framework emitted the model.
Domain name of the model. We use reverse domain names as name space indicators. For example: `com.facebook.fair` or `com.microsoft.cognitiveservices` Together with `model_version` and GraphProto.name, this forms the unique identity of the graph.
The version of the graph encoded. See Version enum below.
A human-readable documentation for this model. Markdown is allowed.
The parameterized graph that is evaluated to execute the model.
Named metadata values; keys should be distinct.
Nodes Computation graphs are made up of a DAG of nodes, which represent what is commonly called a "layer" or "pipeline stage" in machine learning frameworks. For example, it can be a node of type "Conv" that takes in an image, a filter tensor and a bias tensor, and produces the convolved output.
Used in:
namespace Value
namespace Value
An optional identifier for this node in a graph. This field MAY be absent in ths version of the IR.
namespace Node
The symbolic identifier of the Operator to execute.
namespace Operator
The domain of the OperatorSet that specifies the operator named by op_type.
namespace Domain
Additional named attributes.
A human-readable documentation for this node. Markdown is allowed.
Operator Sets OperatorSets are uniquely identified by a (domain, opset_version) pair.
Used in:
The domain of the operator set being identified. The empty string ("") or absence of this field implies the operator set that is defined as part of the ONNX specification. This field MUST be present in this version of the IR when referring to any other operator set.
The version of the operator set being identified. This field MUST be present in this version of the IR.
A serialized sparse-tensor value
Used in:
,The sequence of non-default values are encoded as a tensor of shape [NNZ]. The default-value is zero for numeric tensors, and empty-string for string tensors.
The indices of the non-default values, which may be stored in one of two formats. (a) Indices can be a tensor of shape [NNZ, rank] with the [i,j]-th value corresponding to the j-th index of the i-th value (in the values tensor). (b) Indices can be a tensor of shape [NNZ], in which case the i-th value must be the linearized-index of the i-th value (in the values tensor). The linearized-index can be converted into an index tuple (k_1,...,k_rank) using the shape provided below. The indices must appear in ascending order without duplication. In the first format, the ordering is lexicographic-ordering: e.g., index-value [1,4] must appear before [2,1]
The shape of the underlying dense-tensor: [dim_1, dim_2, ... dim_rank]
StringStringEntryProto follows the pattern for cross-proto-version maps. See https://developers.google.com/protocol-buffers/docs/proto3#maps
Used in:
, ,Used in:
<key, value> pairs to annotate tensor specified by <tensor_name> above. The keys used in the mapping below must be pre-defined in ONNX spec. For example, for 8-bit linear quantization case, 'SCALE_TENSOR', 'ZERO_POINT_TENSOR' will be pre-defined as quantization parameter keys.
Tensors A serialized tensor value.
Used in:
, ,The shape of the tensor.
The data type of the tensor. This field MUST have a valid TensorProto.DataType value
For float and complex64 values Complex64 tensors are encoded as a single array of floats, with the real components appearing in odd numbered positions, and the corresponding imaginary component apparing in the subsequent even numbered position. (e.g., [1.0 + 2.0i, 3.0 + 4.0i] is encoded as [1.0, 2.0 ,3.0 ,4.0] When this field is present, the data_type field MUST be FLOAT or COMPLEX64.
For int32, uint8, int8, uint16, int16, bool, and float16 values float16 values must be bit-wise converted to an uint16_t prior to writing to the buffer. When this field is present, the data_type field MUST be INT32, INT16, INT8, UINT16, UINT8, BOOL, or FLOAT16
For strings. Each element of string_data is a UTF-8 encoded Unicode string. No trailing null, no leading BOM. The protobuf "string" scalar type is not used to match ML community conventions. When this field is present, the data_type field MUST be STRING
For int64. When this field is present, the data_type field MUST be INT64
Optionally, a name for the tensor.
namespace Value
A human-readable documentation for this tensor. Markdown is allowed.
Serializations can either use one of the fields above, or use this raw bytes field. The only exception is the string case, where one is required to store the content in the repeated bytes string_data field. When this raw_data field is used to store tensor value, elements MUST be stored in as fixed-width, little-endian order. Floating-point data types MUST be stored in IEEE 754 format. Complex64 elements must be written as two consecutive FLOAT values, real component first. Complex128 elements must be written as two consecutive DOUBLE values, real component first. Boolean type MUST be written one byte per tensor element (00000001 for true, 00000000 for false). Note: the advantage of specific field rather than the raw_data field is that in some cases (e.g. int data), protobuf does a better packing via variable length storage, and may lead to smaller binary footprint. When this field is present, the data_type field MUST NOT be STRING or UNDEFINED
Data can be stored inside the protobuf file using type-specific fields or raw_data. Alternatively, raw bytes data can be stored in an external file, using the external_data field. external_data stores key-value pairs describing data location. Recognized keys are: - "location" (required) - POSIX filesystem path relative to the directory where the ONNX protobuf model was stored - "offset" (optional) - position of byte at which stored data begins. Integer stored as string. Offset values SHOULD be multiples 4096 (page size) to enable mmap support. - "length" (optional) - number of bytes containing data. Integer stored as string. - "checksum" (optional) - SHA1 digest of file specified in under 'location' key.
If value not set, data is stored in raw_data (if set) otherwise in type-specified field.
For double Complex128 tensors are encoded as a single array of doubles, with the real components appearing in odd numbered positions, and the corresponding imaginary component apparing in the subsequent even numbered position. (e.g., [1.0 + 2.0i, 3.0 + 4.0i] is encoded as [1.0, 2.0 ,3.0 ,4.0] When this field is present, the data_type field MUST be DOUBLE or COMPLEX128
For uint64 and uint32 values When this field is present, the data_type field MUST be UINT32 or UINT64
Location of the data for this tensor. MUST be one of: - DEFAULT - data stored inside the protobuf message. Data is stored in raw_data (if set) otherwise in type-specified field. - EXTERNAL - data stored in an external location as described by external_data field.
Used in:
Basic types.
float
uint8_t
int8_t
uint16_t
int16_t
int32_t
int64_t
string
bool
IEEE754 half-precision floating-point format (16 bits wide). This format has 1 sign bit, 5 exponent bits, and 10 mantissa bits.
complex with float32 real and imaginary components
complex with float64 real and imaginary components
Non-IEEE floating-point format based on IEEE754 single-precision floating-point number truncated to 16 bits. This format has 1 sign bit, 8 exponent bits, and 7 mantissa bits.
For very large tensors, we may want to store them in chunks, in which case the following fields will specify the segment that is stored in the current TensorProto.
Used in:
Defines a tensor shape. A dimension can be either an integer value or a symbolic variable. A symbolic variable represents an unknown dimension.
Used in:
Used in:
namespace Shape
Standard denotation can optionally be used to denote tensor dimensions with standard semantic descriptions to ensure that operations are applied to the correct axis of a tensor. Refer to https://github.com/onnx/onnx/blob/master/docs/DimensionDenotation.md#denotation-definition for pre-defined dimension denotations.
Types The standard ONNX data types.
Used in:
, ,The type of a tensor.
The type of a sequence.
The type of a map.
An optional denotation can be used to denote the whole type with a standard semantic description as to what is stored inside. Refer to https://github.com/onnx/onnx/blob/master/docs/TypeDenotation.md#type-denotation-definition for pre-defined type denotations.
map<K,V>
Used in:
This field MUST have a valid TensorProto.DataType value This field MUST be present for this version of the IR. This field MUST refer to an integral type ([U]INT{8|16|32|64}) or STRING
This field MUST be present for this version of the IR.
repeated T
Used in:
The type and optional shape of each element of the sequence. This field MUST be present for this version of the IR.
Used in:
This field MUST NOT have the value of UNDEFINED This field MUST have a valid TensorProto.DataType value This field MUST be present for this version of the IR.
Defines information on value, including the name, the type, and the shape of the value.
Used in:
This field MUST be present in this version of the IR.
namespace Value
This field MUST be present in this version of the IR for inputs and outputs of the top-level graph.
A human-readable documentation for this value. Markdown is allowed.
Versioning ONNX versioning is specified in docs/IR.md and elaborated on in docs/Versioning.md To be compatible with both proto2 and proto3, we will use a version number that is not defined by the default value but an explicit enum number.
proto3 requires the first enum value to be zero. We add this just to appease the compiler.
The version field is always serialized and we will use it to store the version that the graph is generated from. This helps us set up version control. For the IR, we are using simple numbers starting with with 0x00000001, which was the version we published on Oct 10, 2017.
IR_VERSION 2 published on Oct 30, 2017 - Added type discriminator to AttributeProto to support proto3 users
IR VERSION 3 published on Nov 3, 2017 - For operator versioning: - Added new message OperatorSetIdProto - Added opset_import in ModelProto - For vendor extensions, added domain in NodeProto
IR VERSION 4 published on Jan 22, 2019 - Relax constraint that initializers should be a subset of graph inputs - Add type BFLOAT16
IR VERSION 5 published on March 18, 2019 - Add message TensorAnnotation. - Add quantization annotation in GraphProto to map tensor with its scale and zero point quantization parameters.
IR VERSION 6 published on Sep 19, 2019 - Add support for sparse tensor constants stored in model. - Add message SparseTensorProto - Add sparse initializers