• 写这篇文章的立意是讲清楚sample仓库01-yolov5的onnx文件的来源
• 同时要讲清楚与当前使用的Ultralytics 的 yolov5s 的区别
• 如果要自己训练并且使用200I dk A2 或者 香橙派进行模型移植，一定要注意到这个差异性
• 否则就会识别框识别不准而且完全混乱

• 有看过sample仓代码的一定很熟悉这个ATC代码，无论是哪个仓库都是直接ATC转换onnx 到 om，然后运行
• 就相当于告诉你1+1等于2，但是1是什么？他那里来的，为什么他就是1？我们都不知道

• 仓库里的这两个文件就是我们最熟悉的陌生人
• 这个时候熟悉yolov系列的同学要说了，这不简单吗？
• 直接去github 下载 Ultralytics的源码，然后用Python export.py 转换pt 为onnx
• 或者直接选取最新releases V7.0提供的 yolov5s就可以，然后再用ATC转换 

• 嗯，思路是这个思路，可你怎么能够确认Ultralytics的逻辑跟仓库提供的逻辑一样呢？
• 你们有没有亲自动手用Ultralytics导出的onnx文件试过呢？我试过，结果惨不忍睹，一开始 我还怀疑是ATC转换的om出问题了 
• 但是后来我就明白并非如此。下图就是我提高conf_thres 到0.999 ，iou_thres到0.99的结果

• 这个时候我就怀疑模型不一致了，所以用netron看下两个模型层次
• 发现samples仓库多了一个1 * 1卷积层，我就奇怪了，这个1 * 1卷积层什么作用？

• 仔细看下具体的结构，恍然大悟
• 考下大家1 * 3 * 640 * 640 卷 3 *  1 * 1 *  1，stride = 1, 1 pad = 0, 0, 0, 0 得到最终shape是多少？
• 考下大家3 * 3 * 640 * 640 卷 32 *  3 * 6 *  6  ，stride = 2,2 pad = 2,2,2,2 得到最终shape是多少？

• normalize 字眼已出现，em~~开始有种灵感，为了验证想法，我查了Ultralytics的源码
• samples仓库的det_utils.py 基本与 Ultralytics的源码一致
• 只是在Ultralytics的源码 中 多了这么一句 /255 ，与层结构一对照，哦吼，是这样

• 打开normalize_weight 
• 0.003921568859368563 这个数字很熟悉呀
• 1/255 = 0.0039215686274509803921568627451
• 验证上了

• 如果不做任何修改，按照源码进行编译成Onnx，再去用这个model套用sample 的调用算法，就会少了一个 /255归一化的步骤
• 导致最后的乱框问题，修改下调用算法就OK了