ONNX Prootocol Buffer (proto2)

ONNX protocol buffer is defined by [link1].

They share some features with tf-pb but there are some different points which should be noted down.

Followings are some features of ONNX protocol buffer.

DL model assumes to be stored under ModelProto. ModelProto has GraphProto.

GraphProto often needs to have following four fields [NodeProto,input,output,initializer].

NodeProto

NodeProto in ONNX is similar to NodeDef in TF protocol buffer. It has following fields. opType,name,node,ìnput,output.attribute

In comparison with TF-pb, roles of optype (op in tf) name, input and attribute is quite similar.

Notable difference is following two.

• output list which refers parent object from a child. Since its structures are DAG, parents can be multiple.
• attribute is not a map but list of map.

Input (repeated ValueInfoProto)

Input is a meta information to store leaf in a graph. They do not store actual value but meta information such as tensor shape and type information.

By contrast with the fact that Tensorflow stores no matter what nodes they are in a node on a graph, their underlying idea I suppose is letting meta information close to a standard format of an object file.

For instance, elf file sperates .text section which contains codes of operations from statically allocated section such as .rodata, .data and .bss. Like elf format, ONNX sets a line between data which will be allocated statically and each instructions and attributes which will be dynamically allocated.

Output (repeated ValueInfoProto)

Output attributes output meta information on a graph.

It is usually single.

Intializer (repeated TensorProto)

If an input needs to be allocated statically by constant or non-constant manner, initializer will refer name of input to feed them when a graph is initialized.

When size of weights are huge and your aim is reffering meta information, this field should be skipped.