package onnx

Get desktop application:
View/edit binary Protocol Buffers messages

A named attribute containing either singular float, integer, string and tensor values, or repeated float, integer, string 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: NodeProto

• optional string name = 1

  The name field MUST be present for this version of the IR.

  namespace Attribute

• optional float f = 2

  float

• optional int64 i = 3

  int

• optional bytes s = 4

  UTF-8 string

• optional TensorProto t = 5

  tensor value

• optional GraphProto g = 6

  graph

• repeated float floats = 7

  list of floats

• repeated int64 ints = 8

  list of ints

• repeated bytes strings = 9

  list of UTF-8 strings

• repeated TensorProto tensors = 10

  list of tensors

• repeated GraphProto graphs = 11

  list of graph

GraphProto defines a parameterized series of nodes to form a directed acyclic graph. This is the equivalent of the "network" and "graph" in many deep learning frameworks.

Used in: AttributeProto, ModelProto

• repeated NodeProto node = 1

  The nodes in the graph.

• optional string name = 2

  The name of the graph.

  namespace Graph

• repeated TensorProto initializer = 5

  A list of named tensor values (constants), used to specify default values for some of the inputs of the graph. Each TensorProto entry must have a distinct name (within the list) that also appears in the input list. In an evaluation, the default value specified here is used if and only if user specifies no value for the corresponding input parameter. May be used to pass serialized parameters for networks.

• optional string doc_string = 10

  A human-readable documentation for this graph. Markdown is allowed.

• repeated ValueInfoProto input = 11

  The inputs and outputs of the graph.

• repeated ValueInfoProto output = 12

• repeated ValueInfoProto value_info = 13

  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.

ModelProto is a top-level file/container format for bundling a ML model. The semantics of the model are described by the GraphProto that represents a parameterized computation graph against a set of named operators that are defined independently from the graph.

• optional int64 ir_version = 1

  The version of the IR this model targets. See Version enum above. This field MUST be present.

• optional string producer_name = 2

  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.

• optional string producer_version = 3

  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.

• optional string domain = 4

  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.

• optional int64 model_version = 5

  The version of the graph encoded. See Version enum below.

• optional string doc_string = 6

  A human-readable documentation for this model. Markdown is allowed.

• optional GraphProto graph = 7

  The parameterized graph that is evaluated to execute the model.

NodeProto stores a node that is similar to the notion of "layer" or "operator" in many deep 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: GraphProto

• repeated string input = 1

  namespace Value

• repeated string output = 2

  namespace Value

• optional string name = 3

  namespace Node

• optional string op_type = 4

  namespace Operator

• repeated AttributeProto attribute = 5

  Additional named attributes.

• optional string doc_string = 6

  A human-readable documentation for this graph. Markdown is allowed.

A sparse tensor must be stored as three dense tensors: 1. dims: The shape of the original dense tensor. 2. indices: A 2-D tensor specifying the indices of the nonzero elements. 3. values: A 1-D tensor containing the values of the nonzero elements.

• repeated int64 dims = 1

  The dimensions in the tensor.

• optional TensorProto indices = 2

  This field MUST be present this version of the IR.

• optional TensorProto values = 3

  This field MUST be present this version of the IR.

A message defined to store a tensor in its serialized format.

Used in: AttributeProto, GraphProto, SparseTensorProto

• repeated int64 dims = 1

  The shape of the tensor.

• optional TensorProto.DataType data_type = 2

  The data type of the tensor.

• optional TensorProto.Segment segment = 3

• repeated float float_data = 4

  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.

• repeated int32 int32_data = 5

  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, INT8, BOOL, or FLOAT32

• repeated bytes string_data = 6

  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

• repeated int64 int64_data = 7

  For int64. When this field is present, the data_type field MUST be INT64

• optional string name = 8

  Optionally, a name for the tensor.

  namespace Value

• optional bytes raw_data = 9

  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

• repeated double double_data = 10

  For double Complex64 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

• repeated uint64 uint64_data = 11

  For uint64 and uint32 values When this field is present, the data_type field MUST be UINT32 or UINT64

Used in: TensorProto, TypeProto.SparseTensorTypeProto, TypeProto.TensorTypeProto

• UNDEFINED = 0

• FLOAT = 1

  Basic types.

  float

• UINT8 = 2

  uint8_t

• INT8 = 3

  int8_t

• UINT16 = 4

  uint16_t

• INT16 = 5

  int16_t

• INT32 = 6

  int32_t

• INT64 = 7

  int64_t

• STRING = 8

  string

• BOOL = 9

  bool

• FLOAT16 = 10

  Advanced types

• DOUBLE = 11

• UINT32 = 12

• UINT64 = 13

• COMPLEX64 = 14

  complex with float32 real and imaginary components

• COMPLEX128 = 15

  complex with float64 real and imaginary components

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

• optional int64 begin = 1

• optional int64 end = 2

Define the types.

Used in: ValueInfoProto

• oneof value

  • TypeProto.TensorTypeProto tensor_type = 1

    The type of a tensor.

  • TypeProto.SparseTensorTypeProto sparse_tensor_type = 2

    The type of a sparse tensor.

Used in: TypeProto

• optional TensorProto.DataType elem_type = 1

  This field MUST NOT have the value of UNDEFINED This field MUST be present for this version of the IR.

• optional TensorShapeProto shape = 2

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: SparseTensorTypeProto, TensorTypeProto

• repeated TensorShapeProto.Dimension dim = 1

Used in: TensorShapeProto

• oneof value

  • int64 dim_value = 1

  • string dim_param = 2

    namespace Shape

Used in: TypeProto

• optional TensorProto.DataType elem_type = 1

  This field MUST NOT have the value of UNDEFINED This field MUST be present for this version of the IR.

• optional TensorShapeProto shape = 2

Defines information on value, including the name, the type, and the shape of the value.

Used in: GraphProto

• optional string name = 1

  This field MUST be present in this version of the IR.

  namespace Value

• optional TypeProto type = 2

  This field MUST be present in this version of the IR.

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.

• IR_VERSION = 1

  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. We should use version as xx(major) - xx(minor) - xxxx(bugfix) and we are starting with 00000001.