添加AMD的GPU加速

[nzm001]

准备工作

将onnxruntime包替换为onnxruntime-rocm，infer_engine.py的CPUExecutionProvider改为ROCMExecutionProvider即可开启加速。

sudo python3 -m pip uninstall onnxruntime
sudo python3 -m pip install onnxruntime-rocm -f https://repo.radeon.com/rocm/manylinux/rocm-rel-6.3.1/
sudo sed -i 's/CPU_EP = "CPUExecutionProvider"/CPU_EP = "ROCMExecutionProvider"/' /usr/local/lib/python3.10/dist-packages/rapidocr_onnxruntime/utils/infer_engine.py

环境

AMD 6600H无独显，Ubuntu 22.04。

识别图片为1080x2160的手机截图（png，大小1432408B）。

测试代码

from rapidocr_onnxruntime import RapidOCR

engine = RapidOCR()

img_path = '1.png'
result, elapse = engine(img_path) # 排除第一次

# 运行十次
sum_elpase = [0, 0, 0]

for i in range(10):
    result, elapse = engine(img_path)
    sum_elpase = list(map(lambda x, y: x + y, sum_elpase, elapse))

elapse = [i/10 for i in sum_elpase]

结果

• CPUExecutionProvider: [0.3969314919999988, 0.0306060791015625, 0.8933536291122437]
• ROCMExecutionProvider: [0.2842670244999681, 0.08865513801574706, 1.1470747232437133]

总结

1. 只加速了det部分，其他反而变慢。原因可能是6600H核显规模太小仅6CU，6800H为12CU，独显RX7600为32CU。
2. 不知道是否有其他参数须要设置。
3. CPU_EP = "MIGraphXExecutionProvider"不能运行，不知道是啥。
4. onnxruntime-rocm目前仅有Linux的包。https://repo.radeon.com/rocm/manylinux/rocm-rel-6.3.1/

[SWHL]

待我有空看看

[nzm001]

这一个月在单位办公机上使用下来的问题，因为办公电脑，所以以下都是CPU运行的结果。

图片缩放

关于图片缩放的问题，源码main.py中：

def preprocess(self, img: np.ndarray) -> Tuple[np.ndarray, float, float]:
    h, w = img.shape[:2]
    max_value = max(h, w)
    ratio_h = ratio_w = 1.0
    if max_value > self.max_side_len:
        img, ratio_h, ratio_w = reduce_max_side(img, self.max_side_len)

    h, w = img.shape[:2]
    min_value = min(h, w)
    if min_value < self.min_side_len:
        img, ratio_h, ratio_w = increase_min_side(img, self.min_side_len)
    return img, ratio_h, ratio_w

这段我的理解，如果有一个图片尺寸比较特殊，会不会须要reduce_max_side的同时increase_min_side，导致反复修改图片尺寸。出于性能考虑，max_side_len的优先级应该更高；出于准确率考虑，min_side_len的优先级应该更高。

插值算法

图片放大缩小的插值算法（interpolation method，大概这个意思？）。

源码process_img.py中用的是cv2.resize，根据opencv官方文档，默认用的应该是bilinear interpolation，其他算法能否系统性的提高识别率？

我尝试了pillow模块的几个算法，放大一张比较小的裁剪后图片（346x83，放大10倍），结果放大算法bicubic和Lanczos识别率（det）比bilinear稍好，bilinear比nearest好，但一张图片不具有参考性。当然如果是upscale算法（比方说esdr 2x后再放大5倍，或者fsr）是要比这些都好，但是太耗时，得不偿失。

因为这些算法对图片来说都比较快，所以可以分别找合适的放大、缩小算法去提高准确率。

性能优化

这个是刚好看到pyautogui模块的启发。

减小图片文件大小：灰阶和降低色深单独或者同时使用，尽管大幅减少图片文件大小，基本都不能提升效率，效率提升最多不超过5％，但是识别结果都挺差的。测试图片是手机截图1080x2160（8bit RGB）。以下均已测试（基于CPU）：8bit RGB转8bit灰阶，8bit RGB转4bit灰阶，8bit RGB转黑白，8bit RGB转4bit RGB，8bit RGB转2bit RGB，8bit RGB转1bit RGB。

裁切图片：裁剪图片对提速效果巨大。

from PIL import Image

region = (left, upper, right, lower)
result, elapse = engine(Image.open(img_path).crop(region))
result = [[[[x + region[0], y + region[1]] for x, y in polygon], text, score] for polygon, text, score in result]

对比度和γ：如果能确定字体颜色深浅，可以以较小的代价提高准确度，而不必使用server识别。例如深色字体则提高γ然后提高对比度。这个纯属个人使用感受，可能有误。

[SWHL]

关于图像缩放问题，这里需要重新梳理一下全局所有关于图像缩放的问题。

插值算法这块，之前看到过一个比赛经验帖子，的确提高了不同的插值算法会影响图像识别结果。不过从工具的泛化性来看，比较难以找寻出哪些图像适用哪些插值算法。

性能优化这里测试的很好，很有启发。不过本质来说，还是图像在不影响文字识别的前提下，缩小尺寸，提速作为明显。

[nzm001]

除了max_side_len和min_side_len还有一个det_limit_side_len，我这里电脑截图后追求运行速度裁剪为3840x28，按照我理解的逻辑和默认设置：3840x28 -> 2000x15 -> 4000x30 -> 98133x736，虽然放大到736识别确实非常有效，不过长边已经快10w了。det_limit_side_len除非特殊图片单独设置，不注意的话可能突然搞个大的。

[SWHL]

嗯呢， 这块还需要认真考虑，重新优化一下

[nzm001]

找了下，现在的论文现在好像比的都是传统interpolation method和现代super resolution，然后说super resolution多少多少好，不过对比基准倒是bicubic。老的有对比interpolation method，bicubic和Lanczos比bilinear稍微好一点但是速度慢，bicubic和Lanczos这两个差不多。不过都是英文识别，用的还是谷歌的那个OCR，中文啥也没有。
其他还有转为灰阶之类的，也不一定适用中文。

[SWHL]

嗯呢，感觉这部分只能是锦上添花，根本还是在模型效果