Supporting parsing models in other formats

[ChaojifeixiaDazhuang]

Hi @asyms , Will we consider supporting parsing models to workload in other formats，such as .pb，.tflite and so on? Currently, it seems that the framework only supports the ONNX format. Thanks！

[asyms]

Hi,

As of right now, there are no plans to also support parsing from other formats, as most of them can be exported to onnx. This export additionally provides critical reflection on what the model looks like, which can help to identify unsupported operators early.

.pb files can be exported to onnx using tf2onnx
.tflite files can be exported to onnx using tflite2onnx

[ChaojifeixiaDazhuang]

Hi,

As of right now, there are no plans to also support parsing from other formats, as most of them can be exported to onnx. This export additionally provides critical reflection on what the model looks like, which can help to identify unsupported operators early.

.pb files can be exported to onnx using tf2onnx .tflite files can be exported to onnx using tflite2onnx

Hi, thanks for your reply. In fact that, when we convert a model to .onnx from such as .pb or .tflite, it is possible that an operator will be split into many sub-oprators. The following is an example, the origin operator is LayerNorm in pb model，but when we convert it to onnx model, it seems more complicated:

So，I think it may be lead to inaccurate evaluation results?

[asyms]

Yes, this depends on your export pass. Most exporters allow you to define your own custom conversion for specific types if you're interested in them.
Anyways, as of right now ZigZag focuses only on the "computationally intensive" operators, such as Conv, GEMM and MatMul. Other operators will be not be considered. You can read more here
So, as long as those operators are converted correctly, there isn't a problem.

[ChaojifeixiaDazhuang]

Yes, this depends on your export pass. Most exporters allow you to define your own custom conversion for specific types if you're interested in them. Anyways, as of right now ZigZag focuses only on the "computationally intensive" operators, such as Conv, GEMM and MatMul. Other operators will be not be considered. You can read more here So, as long as those operators are converted correctly, there isn't a problem.

I see, thanks.