1.芯片型号：J5
2.天工开物开发包OpenExplorer版本：J5_OE_1.1.68
3.问题定位：模型转换时，reshape出错，且sub精度低
4.问题具体描述：量化log如下：
trafficLightV2.yaml-
hb_mapper_makertbin.log-
onnx_inference.py-
onnx_output.jpg-
quantized_inference.py-
quantized_output.jpg
@颜值即正义 非常感谢您的回复
已经解决了，修改校准算法为default后，量化精度损失在可接受的范围内了
同时，以int16编译model时，编译报错
主要的误差为activation
主要引起误差的节点是’/model.24/Mul_1/model.24/Constant_8_output_0_expand_dims_HzCalibration-
‘/model.24/Mul_1/model.24/Constant_29_output_0_expand_dims_HzCalibration’
取消量化/model.24/Mul_1/model.24/Constant_8_output_0_expand_dims_HzCalibration后-
cosine-similarity并没有得到改善
我已经更新了推理代码，并新增了可视化输出。输出结果差距还是比较大的
请问是我的前处理代码有问题吗，麻烦请指出有问题的点
我针对输入的onnx模型，和量化后的yolov5s_640x640_nv12_quantized_model模型写了推理代码，推理输出tensor完全不一致
您好，地平线工具链在持续迭代优化，为了给您提供更好的服务，希望您能抽出3分钟左右的时间，将您在使用工具链期间的感受和建议告诉我们，您的宝贵意见对我们很重要，非常感谢！-
问卷链接：地平线算法工具链使用满意度反馈
你好，log日志显示模型转换已经成功完成，reshape那行报错可以忽略，是使用多batch校准发生的，工具自动使用batch1校准已成功；建议关注量化后模型总体的精度，参考社区文章 模型精度验证及调优建议 (horizon.cc) 验证精度是否符合预期，如不符合预期，也请参考那篇文章排查。如果定位确实是量化损失，对于像模型中Sub这样量化敏感的算子，可以考虑使用Int16精度量化，参考 PTQ精度调优手段—设置Int16量化 (horizon.cc) 。
你好，img = cv2.cvtColor(img, cv2.COLOR_BGR2YUV)这里调用的cv接口未必符合我们要求的yuv444排布格式，建议使用我们提供的代码
可以从 PTQ&QAT方案板端验证注意事项 (horizon.cc) 获取，其他前处理和推理代码没有问题。此外建议直接接后处理看可视化，直接对比输出数值工作量大且不可靠（量化有损，输出数值部分不同不代表精度有很大损失）
你好，基本可以确定是量化精度损失，建议这边使用精度debug工具分析，参考 PTQ精度Debug工具 (horizon.cc)
你好，正确做法是根据量化敏感的校准节点，找到其对应的普通节点，对普通节点设置取消量化或输入输出int16量化，而不是直接取消量化校准节点，因为校准节点只作为中间产物存储对应普通节点的量化参数，实际参与量化的是普通节点
你好，set_model_output_int16是将模型的输出设置为int16精度，我看log文件中模型输出已经是浮点FP32了，没必要设置set_model_output_int16，强行设置会改变工具对计算图的优化，可能跑不通，就像截图中这样。此时正确做法是使用node_info参数采用逐节点的方式，对量化敏感节点的输入或者输出设置int16量化，参考 6.2.2.2. 模型编译命令（hb_mapper makertbin） — Horizon Open Explorer 。
感谢您的认可，还望您拨冗为我们的工具打分 地平线算法工具链使用满意度反馈 (feishu.cn) ，谢谢！
对于量化敏感的节点，可以参考文章中的建议，采用Int16精度量化；如果部分节点输入数据通道间分布范围过大，可以开启per-channel量化。同时可以调整校准方式为max，调整max_percentile参数去调优精度