码部落

因为实际项目需要，昨天又做了一遍yolov5的模型转换和后处理的代码开发的工作，过程中居然还是发现了一个坑的点。这里说的并不是新的 5.6 T算力的哪个 svp_npu的模型转换，而是还是哪个4.8 T 的哪个，官方文档上说的 “NNN” 的哪个 npu 的模型转换。需然这条路我在前天终于走通了，但今天还是在模型转换时遇到了个坑，然后发现了个官方文 档的问题。这个问题是这样的，以下是官方文 档的原文 ：
9.1.3 ONNX 算子规格
该算子规格仅适用于ONNX原生IR定义的网络模型。算子详情请参见《Caffe&ONNX算
子规格清单》>支持ONNX算子清单.。
如果要查看基于Ascend IR定义的单算子信息，请参见《CANN 算子规格说明》手册。
当前支持的ONNX版本为1.8.0、Opset版本为v9~v13、ONNX Runtime版本为1.6.0。

这里说Opset 版本为v9-v13 但实际中，我使用了opset v10  版本把 yolov5s.pt 转为onnx 后，再把这个 yolov5s.onnx 转为 .om 时就会报  Resize 138 节点 input size error 的错误。这个问题折腾了很久，最后发现，就是 .pt 转onnx 时，选用了 v10版本的Opset , 而使用 v12 版本的 Opset 就不会产生这个 Resize138 input size error 的错误。

昨天，把供应商提供的（据称）官方的SDK包里的python 预处理的坑给填了，下面是这个python 的原码，然后分析里面的坑

import os
import numpy as np
from PIL import Image

def process(input_path):
try:
input_image = Image.open(input_path)
input_image = input_image.resize((640, 640), resample=Image.BILINEAR)
# hwc
img = np.array(input_image)
# rgb to bgr
img = img[:, :, ::-1]
shape = img.shape
img = img.astype("uint8")
# img = img.astype("float32")
img = img.reshape([1] + list(shape))
result = img.transpose([0, 3, 1, 2])
output_name = input_path.split('.')[0] + "_yolov5.bin"
result.tofile(output_name)
except Exception as except_err:
print(except_err)
return 1
else:
return 0


这段python 代码作做主要是为了对图片进行尺寸、和输入数据统一化的处理。yolov5的输入一般是640×640 的尺寸 是以 NCHW 的布局排列，其中N 是批次数 一船是1 ，C是通道数一般是3 （代表RGB 三个通道），H是 height 高度，W是width 宽度，所以这个代码主要作用是为了把图片的长，宽转成640×640。然后把图片转为numpy 数组，增加一个批次维度，然后再把数组的shaep 即布局转为 NCHW 即[1,3,640,640]

但从这个代码看，他并没有考虑图像的长宽比因为resize 的强行处理，被强行扭曲了。这将导致图像的内容会被压扁扭曲了。在一般的模型，包括官方的，或者使用自行标注的数据集，都不会使用这样扭曲了的图像进行训练。需要某些时候会使用一些方法对原始采集的图片进行一些人工处理凭空造一些数据。但这么扭曲压扁的是比较少的。所以，这么对输入图像进行处理是会造成模型识别结果不正确的问题。这是问题其一。

其二，这个代码使用Pillow包进行图像的处理，PIL的Image.open 是把原始图像以RGB的色域格式进行读取处理。但他在下面的代码里进行了 img = img[:, :, ::-1] 处理，这个处理是把RGB 转为 BGR 。这么干其实是错的，也可能是多此一举。原因是，yolov5 的输入图像是RGB 格式的，因为训练的程序就是以RGB的格式进行训练的，所以模型是不能识别BGR格式的图像。在供应商的提拱的官方文 档中说到了一个–-insert_op_conf=  参数。经过我对这个文档的研究和对照yolov5 的官方算法处理流程。个人认为，这个其实是定义一个预处理的的方式和参数的东西。相当于把预处理以预先定义好的参数文件整合到模型里。里面提到了把BGR转为RGB的方法，这里可以以使用这个把BGR的输入图像转回RGB再输入到真正模型进行处理。但个人认为，这么做是能对应上python 文件的RGB 转BGR的操作。但这纯粹的多此一举。因为我的第一目标是要把模型推理在NPU上跑起来，且跑正确了，下一步再考虑性能的问题。所以我是直接在模型转换时不加 –insert_op_conf 这个参数。直接是：

atc –model=./yolov5s_v6.2.onnx –framework=5 –input_shape=”images:1,3,640,640″ –output=v5s_o –soc_version=”OPTG” –output_type=FP32

其三，也是最后的坑，即使修改这个python 程序，把RGB 的转换去掉了，再把图像resize 这个处理改掉，保持原图模宽比。但最后输出的.bin 文件，再调用官方的库读进去处理，模型识别的结果还是错的。原因，目前还不明，估计是保存或读取文件到内存的方式哪里不对导致最后读进去处理，输入到模型的数据是错的。在这个问题是我花了大量的时间来调试代码。一开始以为是后处理代码的问题，怎么都不对。然后才怀疑前处理的数据问题。最后，解决方法是，直接不要官方的这个python 代码生成.bin 文件，把他这个处理，直接使用c++重写。然后，把处理后数据直接输入到 ACL 库的对应输入数据函数。然后，调用ACL库进行模型推理。

以下是整个过程的完整代码，里面有部份是调试过程中产生的无效代码，也有些是走了弯路的代码，懒得整理重构去掉了，先记下来再说：

之所以写这个日记是为了记着整个过程的问题，因为过去的一段时间里，已经踩过不少的坑，到目前为止，有些坑还是没有解决。所以需要记着做过的尝试，成功的要记着，失败的也得记着。

首先，根据供应商和线上一些有限的资料看到，3403-SS928这个芯片号称的10.4T算力是由一个有4.8T算力和另一个5.6T算力的两个不同架构的NPU组成。这两个NPU互相不能通用，模型虽都是.om格式但不通用，调用模型的推理程序和库也不通用。

目前我可以做到4.8T（号称）的这个核的模型转换，使用的是供应商提供的官方模型转换工具  Ascend-cann-toolkit_5.13.t5.0.b050_linux-x86_64.run  这个ATC工具

这个工具的安装也有坑，具体是什么有空再写，总之目前我能成功装上的环境是使用windows10 的 wsl2 安装 ubuntu 20.04版本linux  再加上手工编译安装的 Python 3.8.16

安装atc 工具后，使用 source /${安装目录}/Ascend/ascend-toolkit/latest/x86_64-linux/bin/setenv.bash 引用atc工具环境

运行atc 进行模型转换，命令如下：

atc –model=./yolov5s_v6.2.onnx –framework=5 –input_shape=”images:1,3,640,640″ –output=v5s_o –soc_version=”OPTG” –output_type=FP32

看到网上有些大神的文章说使用 –insert_op_conf= xxx.cfg 定义AAPP，在研究了一翻供应商官方提供的关于ATC的官方文档后暂时觉得没有必要。这东西其实是把图像的前处理以某种方式整合到.om文件里，这是我的个人理解，不知道对不对。但现在我的问题并不是性能问题，而是需要先让整个模型推理过程运行正确。所以我现在没有加入 –insert_op_conf= 这个参数

另外，供应商提供的包里有一个把图片转成.bin 格式的 python 程序。对其分析研究一翻后，先前认为这个程序只是把.jpg图片转成需要输入模型的大小，即 640×640 ,并且把图片数组转为 NCHW 的布局，然后保存成 binary 格式的.bin 文件。但现在感觉这里有两个大坑。

一，图片是使用resize 强制转大小，并没有保持原图的横宽比，这将会导致图像压缩扭曲，使模型识别结果错误（暂时个人认为是这样）。

二，是程序使用PILLOW 库进行图像读取和处理，图像在初始读取时是以RGB 的色域格式进行读取的，但程序对这个RGB 色域进行了错误的转换（暂时我认为是错的），把色域转为BGR。所以，下一步我将修改这个python 使之保持RGB的格式。