PiNozCam inference models

Pre-compiled, pre-quantized inference models for OctoPrint-PiNozCam, a 3D-print failure detector that watches a nozzle camera.

These files are build inputs, not something an end user installs. The plugin ships each model inside a platform runtime Wheel; this repository is where the release pipeline fetches them from, pinned by commit.

⛔ This repository must never be super-squashed

super_squash_history collapses all history into a single commit and is not revertible. Every build pins a commit SHA, so squashing would break every pinned build at once, including released versions. The same goes for deleting the repository, force-pushing main, or moving a tag.

Total content here is under 300 MB, so the storage pressure that motivates squashing does not apply.

Files

Grouped by the kind of processor that executes them.

file	target	format
cpu/nozcam-cpu.pte	any CPU: armhf, aarch64, x86-64, macOS arm64	ExecuTorch, int8
gpu/nozcam-gpu.pte	Vulkan GPU: aarch64, x86-64	ExecuTorch, int8
npu/nozcam-rk3566.rknn	Rockchip RK3566	RKNN, int8
npu/nozcam-rk3576.rknn	Rockchip RK3576	RKNN, int8
npu/nozcam-rk3588.rknn	Rockchip RK3588	RKNN, int8
npu/nozcam-a733.nb	Allwinner A733, VeriSilicon VIP, VIPLite v2.0	NBG, int8
npu/nozcam-t527.nb	Allwinner T527, VeriSilicon VIP, VIPLite v1.13	NBG, int8
npu/nozcam-x5.bin	D-Robotics RDK X5, BPU (bayes-e)	hbdk bin, int8
npu/nozcam-coreml.pte	Apple Neural Engine, macOS arm64	ExecuTorch CoreML, int8

⚠️ An NPU model never runs on another chip. Every .rknn and .nb carries a hardware identifier and is rejected at load time by anything else. The two Allwinner files additionally target incompatible runtime major versions, so they are not interchangeable even between two VeriSilicon VIP parts. nozcam-coreml.pte is an ExecuTorch file like the CPU one but is equally non-portable: its payload is a CoreML .mlpackage, so only Apple silicon can load it. Only the CPU file is portable, and it is bit-identical across architectures because int8 inference is integer arithmetic with no floating-point reassociation.

Input and output contract

Identical across every target, because the plugin's post-processing is one shared implementation:

• Input — 640x384 RGB, raw 0-255. Normalization is inside the graph, so callers do resize only. The camera frame is scaled to fit and padded with black (never stretched), and the content rectangle is passed alongside so severity is measured against camera content rather than padding.
• Resize must be Pillow's default BICUBIC. Every calibration image and every published accuracy figure used it. OpenCV's INTER_CUBIC measures 3.2x the entire int8 quantization error on this model and can flip an alarm: Pillow antialiases on downscale and OpenCV does not, and their bicubic coefficients differ (-0.5 vs -0.75).
• Output — 10 tensors, decoded by the plugin into boxes, scores and a severity fraction.

Naming and versioning

File names never change. npu/nozcam-t527.nb is that target's name forever; a new build replaces its contents in a new commit.

The version is therefore the commit, and consumers pin a commit SHA:

https://huggingface.co/DrAlexLiu/PiNozCam/resolve/<commit-sha>/npu/nozcam-t527.nb

Tags (models-1.0, models-1.1, ...) name a commit for humans; see CHANGELOG.md. Builds pin the SHA, not the tag — a tag can be moved, a commit cannot.

Updating one target does not disturb the others: they stay pinned to the older commit and keep receiving byte-identical content. Rolling back is the same operation in reverse, because the pin is content-addressed.

SHA256SUMS covers every file at that commit. Consumers are expected to check both the resolved commit (the x-repo-commit response header) and the file digest: the first proves the fetch came from the intended version, the second proves the bytes are intact.

A genuinely different network — not a recalibration, but different input or output shapes — belongs in a new directory rather than a new commit on the same names, so that a build pinned to an older commit cannot silently receive a file it is unable to run.

Accuracy

Reported against the fp32 model on the project's 34-frame calibration set, under the same fit-and-pad preprocessing the plugin uses, with boxes paired by nearest neighbour and the deviation averaged over every box.

file	mean abs. score deviation	box-count agreement
npu/nozcam-t527.nb	0.0222	34/34
npu/nozcam-coreml.pte	0.0078	26/34

⚠️ That set is both the calibration and the evaluation set, and every frame in it is 16:9. It can falsify a regression; it cannot confirm accuracy on unseen scenes or other aspect ratios.

Figures for the other targets are published with the plugin rather than here, because they were measured on their own hardware.

License

AGPL-3.0, matching the plugin.