PINTO_model_zoo: pre-converted TFLite, OpenVINO and CoreML models in one repository

What PINTO_model_zoo actually is, and who it is for

This is a storage repository, not a framework. Its own description says it stores models that have been inter-converted between TensorFlow, PyTorch, ONNX, OpenVINO, TFJS, TFTRT, TensorFlowLite (Float32/16/INT8), EdgeTPU and CoreML. Each model lives in a numbered directory such as 004_efficientnet, 030_BlazeFace or 057_BiSeNetV2, and the README carries a table of pre-quantized models with columns for FP32, FP16, INT8, DQ (dynamic range quantization), TPU, WQ (weight quantization), OV (OpenVINO IR), CM (CoreML), TFJS, TF-TRT and ONNX. A filled circle in a column means that artifact exists for that model.

The intended reader is someone who has a target runtime already chosen. If you are deploying to a Coral EdgeTPU, a Raspberry Pi, an iPhone via CoreML, or a browser via TensorFlow.js, the value here is that the conversion work is done and the file is sitting in a directory. The author states plainly that this has been hobby work on quantization and that sample code to check operation was skipped because it takes too much time, with an invitation for pull requests to supply it. That single sentence sets expectations: you get artifacts, and you write the harness around them.

The per-folder licence split is the first thing to check

The README opens with an instruction to read the LICENSE file directly under each folder before using the model. The reason is stated in the same paragraph: the conversion scripts are released under MIT, but the licence of the source model itself follows the licence of the provider repository. The repository-level licence being MIT therefore tells you almost nothing about the model you are about to ship.

This is a real operational constraint, not a formality. A converted MobileNet variant and a converted face landmark model can arrive under different upstream terms, and the conversion does not relicense them. If you are packaging a model into a commercial product, the numbered folder is the unit of review, not the repository. The README does not document a consolidated licence manifest, so the check has to be done folder by folder for each model you actually use.

How the artifacts are produced and laid out

The conversion path is documented through the author's linked tooling rather than inside this repository. The README points to tflite2tensorflow, described as generating saved_model, tfjs, tf-trt, EdgeTPU, CoreML, quantized tflite, ONNX, OpenVINO, Myriad Inference Engine blob and .pb from .tflite. It also links openvino2tensorflow for PyTorch to ONNX to OpenVINO IR to TensorFlow saved_model, h5, tflite and pb, and onnx2tf for converting ONNX (NCHW) to TensorFlow format (NHWC), which the README frames as solving the Transpose extrapolation problem in onnx-tensorflow.

So the data flow is one-directional and hub-and-spoke: a source model is converted into one intermediate format, then fanned out into the target runtimes. That explains the shape of the model table. A model with a circle under OV and CM but nothing under TF-TRT simply has not had that branch generated. The repository is the output store of that pipeline, and the numbered directories hold the results plus the conversion scripts.

One consequence worth stating: because the fan-out is generated per model, the set of available precisions is uneven across the zoo. You cannot assume that because EfficientNet-lite has FP32, FP16, INT8, DQ, TPU, WQ, OV, CM, TFJS and TF-TRT, a neighbouring model has the same coverage.

Getting a model and running a first inference

There is no installer. The repository is consumed by cloning it and picking a numbered folder. The README gives no pip package and no CLI entry point for the zoo itself; the tooling it links to (tflite2tensorflow, onnx2tf, openvino2tensorflow) are separate projects.

Start by cloning the repository, then look at the folder for the model you want. The listing below uses 004_efficientnet as the example because it appears in the README table with FP32, INT8 and WQ columns filled.

git clone https://github.com/PINTO0309/PINTO_model_zoo.git
cd PINTO_model_zoo/004_efficientnet
ls

What you should see is the folder contents for that model: the conversion script and the LICENSE file the README tells you to read. The exact filenames are not enumerated in the README, so the directory listing is the source of truth.

Before using the artifact, read the licence that sits next to it:

cat LICENSE

If you need a format that is not already in the folder, the conversion tools are the route. The README links tflite2tensorflow for generating saved_model, tfjs, tf-trt, EdgeTPU, CoreML, quantized tflite, ONNX, OpenVINO and .pb from a .tflite, and onnx2tf for ONNX to TensorFlow conversion. Those are separate repositories with their own installation instructions; the zoo README does not reproduce them.

Known-broken models and the missing sample code

The README carries two dated notes near the top. The note from Jan 05, 2020 states that the MobileNetV3 backbone model and the Full Integer Quantization model do not return correctly. That is a direct warning about correctness, not performance, and it applies to a backbone that many downstream models are built on. Anyone planning an INT8 path through MobileNetV3-derived entries should treat that note as current until a later note supersedes it; the README does not record a fix.

The second limitation is structural. The author writes that sample code to check operation was skipped, and asks for pull requests to add it. In practice this means the repository gives you a file and a conversion script, not a runnable demo. For a TFLite model you will write the interpreter setup, the input normalization and the output decoding yourself. For an OpenVINO IR pair (.xml/.bin) you will write the inference loop. The pre-quantized model table tells you a file exists; it does not tell you the input shape convention, the preprocessing or the postprocessing, and the README does not document those per model.

Where this is the wrong tool, and what to use instead

If you want a maintained library with a stable API, tests and sample inference code, PINTO_model_zoo is the wrong shape. It is a collection of artifacts with per-folder licences and no bundled runtime code. The natural alternative for that need is a framework's own model garden: TensorFlow's model garden and the TensorFlow Lite model collection ship models together with documented training and inference code, and a single project-level licence. The difference in approach is that a model garden owns the whole path from training to inference API, while this repository owns only the conversion output.

A second alternative is converting the model yourself with onnx2tf or tflite2tensorflow. That is the same toolchain the zoo is built on, and the README links both. Going direct means you control the opset, the input layout and the quantization calibration, and you can regenerate when the upstream model changes. The cost is that you now own the conversion failures. Using the zoo means someone else already hit those and published the result.

A third case: if your target is not in the supported list (TensorFlow, PyTorch, ONNX, OpenVINO, TFJS, TFTRT, TensorFlowLite Float32/16/INT8, EdgeTPU, CoreML), there is nothing here for you. The README lists exactly those frameworks and no others.

Maintenance, releases and the upgrade question

The repository is not archived and the last push was on 2026-09-05, which is recent. The release history is thin: the only listed release is 1.0.0, a DOI release dated 2023-11-30. That DOI, 10.5281/zenodo.10229410, is the citable artifact, and it is what you would reference in a paper rather than a version number.

Upgrade cost is where this repository differs from a library. There is no semantic version to pin and no changelog to read. New models appear as new numbered directories, and updates to existing models appear as changes to files inside a folder. If you depend on a converted artifact, the practical pin is the commit hash you cloned, because the folder contents can change without a version bump. The README does not document a rollback procedure, a deprecation policy or a compatibility matrix between model versions and runtime versions.

The licence position does not get simpler with time either. Because each model folder carries its own LICENSE, an upgrade that swaps the upstream source model can change the terms you are bound by, and the repository-level MIT does not cover that. Reviewing the folder's LICENSE again after an update is the only check the README offers.

Editorial conclusion

Adopt PINTO_model_zoo if you need a quantized TFLite or OpenVINO artifact for a known architecture and you are willing to read the LICENSE file inside that numbered folder before shipping anything. Do not adopt it if you need a supported library with a test suite, sample inference code and a single licence covering the whole download. Verify first that the model you want has the precision column you need (FP32, FP16, INT8, DQ, TPU or WQ), open that folder's LICENSE and its conversion script, and check the README notes about models that do not return correct results before you plan around them.

Frequently asked questions

Official sources

1. License: MIT
2. PINTO0309/PINTO_model_zoo on GitHub
3. Project website
4. README
5. Releases