# TensorFlow Lite Model Maker to ONNX: A Complete Detection Deployment Walkthrough

Author: AlgoFly Team
Published: 2022-07-02T11:39:27Z
Canonical: https://algofly.ai/blog/tflite-model-maker-object-detection-onnx

Training a detector is only part of getting it into an application. The exported graph, input layout, class map, output interpretation, and runtime all have to agree. Our [TensorFlow Lite Model Maker walkthrough](https://www.youtube.com/watch?v=4QSi4N9u4R8) follows that path from custom detection data to an ONNX Runtime inference wrapper.


The original video was published in 2022\. Its value is the complete debugging workflow: prepare the data, train and export, inspect the graph, read runtime metadata, and draw the results. This article preserves those lessons while treating the original package environment as a historical reproduction, rather than a promise that every old installation command works in a current notebook.


## Make dataset preparation visible


The video deliberately spends time on data preparation rather than jumping directly to a high\-level training call. That is a useful choice. A detector depends on correct class labels and box coordinates, and mistakes in the input table can survive all the way to a plausible\-looking output visualization.


Keep image paths, split assignments, class names, and bounding boxes inspectable. Draw a sample of the annotations before training, including a non\-square image and an image containing several classes. Verify whether the annotation format expects normalized coordinates or pixel coordinates and whether it stores corners or centers and sizes.


Save the class mapping beside the model artifact. The original walkthrough eventually encounters incorrect displayed class names because the class list and loaded model do not match. A correct box with the wrong label is still an incorrect prediction from the application's perspective.


## Understand what the helper library packages


![Original AlgoFly TensorFlow Lite Model Maker video thumbnail with an object detection example](/content/videos/tflite-model-maker-object-detection-onnx/video-thumbnail.jpg)

The original Model Maker video links the training notebook and demonstrates the deployment steps discussed here.


TensorFlow Lite Model Maker provides a transfer\-learning workflow for custom detection data. The video uses an EfficientDet\-Lite specification and trains through the library rather than implementing a detector's training loop directly. Google's [reference tutorial](https://developers.google.com/edge/litert/libraries/modify/object_detection) remains useful for understanding that historical API and its export path.


The helper library reduces boilerplate, but does not remove the need for validation. Check the training split, held\-out images, label mapping, and expected input size. A loss curve can indicate that optimization is proceeding without showing whether a model works on the camera images the application will receive.


For a fresh project, choose a supported training and deployment environment deliberately. For reproduction, start with a recorded environment compatible with the original notebook. Mixing a legacy training package with arbitrary new dependencies often turns an experiment about detection into an experiment about package resolution.


## Inspect the model you actually exported


![Object detection deployment workflow from annotation data through Model Maker and TFLite export to ONNX inspection and runtime validation](/content/videos/tflite-model-maker-object-detection-onnx/workflow.svg)

Export is one stage in a pipeline whose input and output contracts still need verification.


The walkthrough exports a TensorFlow Lite model and converts it to ONNX with [tf2onnx](https://github.com/onnx/tensorflow-onnx). It then inspects the graph with Netron. That inspection is more valuable than assuming every detector exposes the same tensor contract.


The conversion path shown uses opset 16 and a TFLite input. Treat that as the original example's configuration. Operator support and runtime compatibility should be checked for the actual model being deployed. Converting successfully does not establish numeric equivalence with the source model.


The video's exported graph uses a batch\-one, channel\-last input with 320\-by\-320 image dimensions, and exposes several outputs. Those details belong to that exported artifact. Another model can use a different size, layout, dtype, output order, or postprocessing arrangement.


## Read shapes and names from ONNX Runtime


Start a runtime wrapper by inspecting the model rather than hard\-coding assumptions from a different detector. This small example illustrates that inspection with a CPU provider; it does not contain the model\-specific image transform or output decoder:



```
import onnxruntime as ort

session = ort.InferenceSession(
    "detector.onnx",
    providers=["CPUExecutionProvider"],
)

for value in session.get_inputs():
    print("input", value.name, value.shape, value.type)
for value in session.get_outputs():
    print("output", value.name, value.shape, value.type)

```

If you use a GPU provider, verify that it is available in the installed runtime and inspect which providers the session actually uses. Requesting GPU execution is not a measurement of GPU execution or speed. The [official Python guide](https://onnxruntime.ai/docs/get-started/with-python.html) documents runtime setup and the session interface.


## Color and layout are part of the contract


The video catches a familiar integration mistake: OpenCV loads color images in BGR order, while the inference path expects RGB. A model may still return boxes when the channels are wrong, which makes this kind of error easy to miss if the only check is that the code runs.


Validate input dtype, channel order, layout, resize strategy, and normalization against the exported model. Do not add a channel\-first transpose simply because another PyTorch\-based detector needed one. Likewise, do not apply a normalization formula that belongs to a different backbone.


Preserve the relationship between the original image and the model input. If resizing or padding changes the geometry, the output decoder must invert that operation before drawing boxes. Use tall and wide test images to expose mistakes that a square input photograph can hide.


## Decode boxes, labels, and counts together


The inference wrapper in the walkthrough reads output tensors, filters scores, assigns class names, and scales normalized coordinates back to the source resolution. Check which output is which by inspecting the graph and comparing with the source model; relying only on a remembered output index is fragile.


The video description highlights postprocessing, including non\-maximum suppression, in the exported graph. Verify that property in your own artifact before adding another suppression pass. A second NMS stage can remove legitimate detections, while omitting a required one can leave duplicates. Neither behavior is fixed by changing how boxes are drawn.


Test class indexing explicitly. Some detection workflows reserve an index for background or use a label order different from the original directory order. Store and load one reviewed mapping instead of manually copying labels between notebook cells and application code.


## Compare complete pipelines on the same images


Run the source and exported models on a small fixed image set and compare the final detections. Inspect disagreements in coordinates, scores, classes, and detection counts. When a result changes, isolate preprocessing, graph conversion, and postprocessing before assuming the training failed.


The original video discusses timings from its Colab session. Those measurements should not become a universal speed claim. Benchmark your actual hardware with warm\-up, repeated runs, and a clear definition of what is timed. Separate graph execution from image decoding, preprocessing, drawing, and network overhead, then measure the complete path that users experience.


The lasting lesson is to treat deployment as a verifiable interface. A model file, its transforms, class metadata, and decoder belong together. Once that contract is explicit, changing runtimes becomes a controlled comparison instead of a sequence of guesses.


## Watch and explore


* [AlgoFly: TensorFlow Lite Model Maker and ONNX deployment](https://www.youtube.com/watch?v=4QSi4N9u4R8)
* [Notebook linked from the original video](https://colab.research.google.com/drive/1P_ufG0ueE58Xdtm7kaKbSRJrCDOOQdE0?usp=sharing)
* [Google's Model Maker detection tutorial](https://developers.google.com/edge/litert/libraries/modify/object_detection)
* [tf2onnx converter](https://github.com/onnx/tensorflow-onnx)
* [ONNX Runtime Python guide](https://onnxruntime.ai/docs/get-started/with-python.html)