KlemenSkrlj
Hi Klemen,
Wanted to follow up with the complete resolution from yesterday — we found and fixed the root cause of the PatchCore output discrepancy on the OAK4/RVC4.
Investigation:
We first verified the model at each stage to isolate the issue. The PyTorch FP32/FP16 outputs and the ONNX Runtime outputs were correct and matched the expected feature ranges. However, on the OAK4, layer2 and layer3 were producing values roughly 300–400x higher than the PC output. This confirmed that the issue was not with the PatchCore model, preprocessing, or the ONNX model itself.
We then investigated the RVC4 conversion pipeline. Initially, snpe-dlc-graph-prepare was failing with an error while loading libHtpPrepare.so. As part of debugging, we inspected the libraries inside the published Docker image:
ghcr.io/luxonis/modelconverter-rvc4:2.41.0-latest
Several SNPE/QNN libraries were found to be corrupted and 0 bytes, including:
libHtpPrepare.so
libQnnHtp.so
libQnnCpu.so
We also tested the workaround of skipping the offline graph preparation step. Although this allowed us to proceed further, the resulting model did not contain layer2 as an on-device output — only layer3 was registered. This was because the --set_output_tensors layer2,layer3 step from snpe-dlc-graph-prepare was never applied.
Fix:
We checked the upstream ModelConverter repository and followed the RVC4 Docker build process. We downloaded the actual Qualcomm SNPE package:
snpe-2.41.0.251128.zip (~1.49 GB)
using the full version string mentioned in the ModelConverter documentation. We placed it in the expected docker/extra_packages/ location and rebuilt the RVC4 Docker image locally.
The rebuilt image contains a valid libHtpPrepare.so of approximately 93 MB, instead of the 0-byte library in the published image.
We then reconverted the PatchCore backbone using FP16_STANDARD with onnx_optimizations=False. The complete conversion pipeline successfully executed:
snpe-onnx-to-dlc → snpe-dlc-quant → snpe-dlc-graph-prepare
The offline graph preparation successfully created the HTP cache and correctly registered both layer2 and layer3.
Final validation:
We tested the resulting .rvc4.tar.xz on the real OAK4. The layer2 and layer3 feature values now match the PC/PyTorch outputs almost exactly, with the expected range around min ~0 to max ~2. Previously, the hardware outputs were around 300–400x higher.
So the discrepancy was caused by the corrupted SNPE/QNN libraries in the published RVC4 Docker image, rather than the PatchCore model, preprocessing, or inference configuration.
It may be worth checking whether the ghcr.io/luxonis/modelconverter-rvc4:2.41.0-latest image needs to be rebuilt and republished, as the same issue could occur for others pulling that image.
Thanks for the guidance throughout this. The suggestion to test onnx_optimizations=False and pointing us toward the upstream repository helped us narrow down and resolve the issue.
Best,
Omkar
