paddlepaddle OCR 0x01 使用paddleserving并发性能应该比paddlehub serving更好 https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.3/deploy/pdserving/README_CN.md 指定图片路径并且使用多进程，这样的话不是服务 平均速度15秒左右 python3 tools/infer/predict_system.py --image_dir="/root/pic/" --det_model_dir="/root/pnew/module/det" --rec_model_dir="/root/pnew/module/rec" --use_mp=True --total_process_num=8 --enable_mkldnn=True https://github.com/PaddlePaddle/Serving/blob/develop/doc/Install_CN.md https://github.com/PaddlePaddle/Serving/blob/v0.7.0/doc/Process_data_CN.md https://github.com/PaddlePaddle/Serving/blob/v0.7.0/doc/Model_Zoo_CN.md https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.3/deploy/pdserving/README_CN.md#%E6%A8%A1%E5%9E%8B%E8%BD%AC%E6%8D%A2 https://github.com/PaddlePaddle/Serving/blob/v0.7.0/doc/Install_CN.md#4%E6%94%AF%E6%8C%81%E7%9A%84%E9%95%9C%E5%83%8F%E7%8E%AF%E5%A2%83%E5%92%8C%E8%AF%B4%E6%98%8E 在文件 /usr/local/lib/python3.6/site-packages/paddle_serving_app/local_predict.py 的281行加入print("input_name: ",input_names,feed.keys()) 用来打印出模型需要的名称和实际传入的名称，需要一致。 Serving模型转换： python3 -m paddle_serving_client.convert --dirname ./det/ --model_filename inference.pdmodel --params_filename inference.pdiparams --serving_server ./ppocr_det_mobile_2.0_serving/ --serving_client ./ppocr_det_mobile_2.0_client/ python3 -m paddle_serving_client.convert --dirname ./rec/ --model_filename inference.pdmodel --params_filename inference.pdiparams --serving_server ./ppocr_rec_mobile_2.0_serving/ --serving_client ./ppocr_rec_mobile_2.0_client/ 在Serving中的web_service.py中加入了方向分类，默认是没有方向分类的，所以几乎不太准确 在rec的preprocess中增加了paddlepaddle中的方向分类代码，以及复用unitily.py和模型文件 一个新的问题：在serving增加了cls分类后，发现会出现以下错误，追踪到 /usr/local/lib/python3.6/site-packages/paddle_serving_app/reader/ocr_reader.py 的输出发现是text为空导致np.mean计算出错，增加判断 if len(text)==0:continue 来解决，还不清楚导致的根本原因 目前还存在的问题： 1.增加cls后处理时间被增加，hub部署方式可以看到cls的时间大约是0.1秒，但是这里的cls时间大约在0.4到1秒，差距过大 2.对于有方向的图片准确率提升，但仍然有一定的误差，能否解决 3.并发的时候cls延迟增加太多，在1.4s左右 测试在cpu指令集支持avx512 vnni的机器上，身份证识别可以到0.3~0.5秒

ddddocr的验证码识别方案 验证码识别方案 之前已经说过了 tesseract 的验证码识别方案，具体的代码和实现思路可以参考代码。但是它只是一个思路并且不能代表所有的情况。 在最新的一个环境中，验证码的图片颜色前几行存在与验证码字符相同的颜色，导致的结果是产出的整个验证码变成了替换的纯色，虽然这个验证码图片与之前一样简单，都是数字、字母组合，但是完全无法识别 ddddocr 在解决以及寻找解决方案的时候，看到了 ddddocr 的模块，试用了以下，这个模块相对于 tesseract 来说简单太多，以下是代码: import ddddocr ocr = ddddocr.DdddOcr() ori_ymz = 'test\\tttt1111.png' # new_ymz = 'test\\test_test.png' with open(ori_ymz,'rb') as f: img_bytes = f.read() result = ocr.classification(img_bytes) print(result) 基本上是直接调用一个函数就识别到了，不需要额外的处理图片颜色、格式等 但是 ddddocr 也是有一定的弊端的，首先它的这个函数基本上没有任何参数，无法设置需要识别限定的内容，比如 tesseract 可以设置数字和字母，这对于简单类型的验证码来说足够了。所以 ddddocr 出现了更多的识别错误，准确率比我们改良的 tesseract 要少 1-2 层左右。