[LEGACY] Model Optimizer Extensions¶
The code described here has been deprecated! Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but you should not use it in contemporary applications.
This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the Frontend Extensions article.
Model Optimizer extensions enable you to inject some logic to the model conversion pipeline without changing the Model Optimizer core code. There are three types of the Model Optimizer extensions:
A model transformation, which can be executed during front, middle or back phase of the model conversion.
An extension is just a plain text file with a Python code. The file should contain a class (or classes) inherited from one of extension base classes. Extension files should be saved to a directory with the following structure:
./<MY_EXT>/ ops/ - custom operations front/ - framework independent front transformations <FRAMEWORK_1>/ - front transformations for <FRAMEWORK_1> models only and extractors for <FRAMEWORK_1> operations <FRAMEWORK_2>/ - front transformations for <FRAMEWORK_2> models only and extractors for <FRAMEWORK_2> operations ... middle/ - middle transformations back/ - back transformations
Model Optimizer uses the same layout internally to keep built-in extensions. The only exception is that the
mo/ops/ directory is also used as a source of the Model Optimizer operations due to historical reasons.
The name of a root directory with extensions should not be equal to “extensions” because it will result in a name conflict with the built-in Model Optimizer extensions.
Model Optimizer itself is built by using these extensions, so there is a huge number of examples of their usage in the Model Optimizer code.