[QUESTION] Request: raw ONNX (pre-ORT) weights for DocQuadNet-256

[SanNian21]

Hi,

First of all, thank you for open-sourcing MakeACopy and the full DocQuadNet-256 training pipeline — it's a really clean, well-documented project.

I'm working on an embedded computer vision project (corner detection on a rigid rectangular object, deployed on an RK3588 SBC via RKNN-Toolkit2 for NPU inference), and DocQuadNet-256's architecture (MobileNetV3 backbone + lightweight FPN, no attention/heavy-reshape ops) looks like an excellent fit — much more NPU-friendly than other document-corner models I've tested.

I noticed the repo currently ships the model as docquadnet256_trained_opset17.ort, which includes ORT-specific fused ops(e.g. com.microsoft;1;FusedConv per the operator config file). RKNN-Toolkit2 requires a standard ONNX graph and can't consume the .ort format or its fused ops directly.

Would it be possible to share the original exported .onnx file (the one produced by training/docquad_m3/export_onnx.py, before the ORT conversion step in Section 11/17 of the training README)? I only need read access to the plain ONNX graph for local RKNN conversion experiments — happy to credit the project if this ends up working out.

Also curious if you've tried RKNN/NPU deployment yourselves, or if there's already an ONNX artifact attached to a past release I might have missed.

Thanks again for the great work!

[egdels]

Hi @SanNian21,

thank you for the kind words and for the detailed explanation of your use case.

You are correct: the .ort file included with MakeACopy is the ONNX Runtime–optimized deployment artifact and is therefore not suitable as input for RKNN-Toolkit2. The plain ONNX graph produced by training/docquad_m3/export_onnx.py is the appropriate starting point for the conversion.

I have attached the original ONNX model:

best.onnx.zip

SHA-256 of the uncompressed best.onnx file:

a0411380e01174da18c004afc2ffc4f71bcd01dbecef531b2b6337acfdd3ac85

I have not tested DocQuadNet-256 with RKNN-Toolkit2 or on the RK3588 NPU, so I cannot confirm compatibility or inference correctness on that platform.

The model was deliberately designed to be edge-friendly, with a MobileNetV3 backbone, a lightweight FPN, static shapes, and no attention or heavy reshape operations. It therefore seems like a promising candidate for the RK3588 NPU. I would be genuinely interested to hear how it performs, particularly after INT8 quantization.

Please feel free to report your results here. A credit to the project would of course be appreciated if the model works well for your use case.

Thanks again for reaching out!