1.芯片型号：X3派
2.天工开物开发包OpenExplorer版本：
hbdk version 3.39.2
horizon_nn version 0.14.9
hb_mapper version 1.11.2
3.问题定位：模型转换
4.问题具体描述：量化模型精度下降的很厉害，以及关于**_original_float_model.onnx 的使用问题对齐
您好，这里再模型量化转换当中遇到了一些问题：
onnx原始模型测评进度再一个角度回归的问题上下降了10多个点，（精度的评定按照小于10°的误差为tp，算所有结果的accuracy），从原始模型的97%下降到83%
分类分支下降了3个点。
掉点为bin模型上板测量的结果。
一下sigmoid为角度向量的回归分支，conv为分类分支，网络的预处理为cv.imread，之后resize 128,128 , /256
从模型量化loge当中看量化结果应该挺正常的才对
2023-04-13 03:45:23,527 INFO The quantify model output:
======================================================
Node Cosine Similarity L1 Distance L2 Distance Chebyshev Distance
-------------------------------------------------------------------------------------------
Conv_97 0.999954 0.056883 0.027743 0.134689
Sigmoid_101 1.000000 0.001775 0.001278 0.004256
然后开始查找预处理操作可能出现的错误，
然后分别使用
*_quant_model.onnx
*_original_float_model.onnx
用于量化网络的一个pc上的模拟验证和预处理操作是否有误的判断。
这里俩个模型和bin文件的测试结果比较接近（但是quant_model.onnx和bin文件的结果还是有一定差异的不知道是否算正常）
定位可能是量化数据处理和量化预处理设置有问题。
检查配置感觉没有啥问题，于是按照makertbin的执行方式做了一个 1层卷积的网络输入输出完全相等的
用来验证量化工程当中的预处理设置问题，onnx模型本身是bgr输入，bin模型希望设置为nv12输入，所以这里给生成的**_original_float_model.onnx的时候，输入为yuv444_128格式（参考了用户手册当中的 input_type_r对应中间类型表格）应该得到得到正确的预处理的bgr的结果。结果做去归一化 确实也回到了bgr图片的值（np.allclose判断输入输出相似度，1个像素值误差我们就认为预处理本身是没有问题的）
那在预处理确认无误之后，按照用户文档的说法_original_float_model.onnx模型应该就只加了一个预处理，这里我也查看了源模型的weight和_original_float_model的weight ，也是完全一致的。（下图这个三到五的对齐应该也是因为input_type_r在pc上用中间类型表达没有办法完全做到绝对一致，但像上面的实验以及足够验证它是正确的了）
于是这里去掉了量化当中的makertbin环节的预处理操作，所有的操作都放到网络外面完成，也就是input_type_rt 设置为’featuremap’，input_type_train: ‘featuremap’，我理解这个时候得到的_original_float_model.onnx就应该和原始onnx输入数据也是完全等价。
这里出现了：
在同为HB_ONNXRuntime作为后端的时候，_original_float_model.onnx 和原始onnx喂同样的数据的时候，结果完全一致 ，但是开源onnxruntime 的测试结果不一致。
于是，以上过程当中有三个问题不太理解：
1.HB_ONNXRuntime可以调用原始的onnx文件进行推理吗（得到的结果和自己环境的onnxruntime结果不一致）？
2.**_original_float_model.onnx 是否除了预处理步骤，以后的算子完全等价onnx文件本身？
3.bin文件和quant_model.onnx结果存在一定误差是否合理？
如果有其他需要提供表述的log和模型或者测试图像，这边都可以提供的，感谢答疑
