使用FastDeploy部署PPOCRv3模型存在精度问题

C4a15Wh commented 1 year ago

环境

【FastDeploy版本】： fastdeploy-gpu-python 1.0.2与fastdeploy-python 1.0.2均能复现
【系统平台】: Windows x64(Windows10)
【硬件】： R9-5900HS/RTX3060 Laptop
【编译语言】：Python 3.7.9
【测试语言】：日语
【测试模型】：PPOCRv3-日语模型

问题日志及出现问题的操作流程

您好，我们于近期测试发现，FastDeploy在PPOCRv3-日语模型下的识别精度似乎远不及PaddleServing Pipeline(0.8.3)。 👇这是我们用于测试的图片 👆 FD这边测试的服务端代码采用FD提供的example去除CLS流程，加载日语模型后使用: https://github.com/PaddlePaddle/FastDeploy/tree/develop/examples/vision/ocr/PP-OCRv3/python/serving Serving这边的服务端代码: https://github.com/PaddlePaddle/Serving/blob/v0.9.0/examples/Pipeline/PaddleOCR/ocr/web_service.py 请注意，Serving的样例的RecOp内的OCRReader()需要对char_dict_path进行初始化，否则您无法顺利在Pipeline上进行推理。 请注意，由于Serving的兼容性较差，您可能无法在Windows和MacOS上顺利完成推理，需要Linux复现。 我们用于启动FD的命令是:

fastdeploy simple_serving --app server:app

在上述环境下，我们使用FD进行识别得到的结果是:

{
    "result":"{\"boxes\": [[28, 18, 265, 18, 265, 32, 28, 32], [23, 36, 209, 36, 209, 50, 23, 50]], \"text\": [\"(\あ\れ?\ス\ズ\ぐ\ん\、\台\本\持\っ\て\る\", \"\で\も\公\温\の\色\衣\じ\ゃ\な\い\な)\"], \"rec_scores\": [0.8192606568336487, 0.7393889427185059], \"cls_scores\": [], \"cls_labels\": []}"
}

使用PaddleServing Pipeline加载同样模型识别的结果是:

{
    "err_no": 0,
    "err_msg": "",
    "key": [
        "result"
    ],
    "value": ["{\"Result\": [{\"Coordinate\": {\"UpperLeft\": [31.0, 74.0], \"UpperRight\": [553.0, 74.0], \"LowerRight\": [553.0, 101.0], \"LowerLeft\": [31.0, 101.0]}, \"Words\": \"(\あ\れ?\ス\ズ\く\ん\、\台\本\持\っ\て\る\…\", \"Score\": 0.978085994720459}, {\"Coordinate\": {\"UpperLeft\": [20.0, 117.0], \"UpperRight\": [394.0, 117.0], \"LowerRight\": [394.0, 141.0], \"LowerLeft\": [20.0, 141.0]}, \"Words\": \"\で\も\公\演\の\台\本\じ\ゃ\な\い\な)\", \"Score\": 0.8853415250778198}], \"Code\": 0, \"Message\": \"Success\"}"
    ],
    "tensors": []
}

按理来说同样的模型不该产生如此巨大的差异，我们认为FastDeploy进行推理的参数存在问题，导致实际精度不如PaddleServing（例如FD的batch_size是写死的）。详细情况劳烦您进一步代为分析。

yunyaoXYY commented 1 year ago

温馨提示：根据社区不完全统计，按照模板提问，可以加快回复和解决问题的速度

环境

【FastDeploy版本】： fastdeploy-gpu-python 1.0.2与fastdeploy-python 1.0.2均能复现

【系统平台】: Windows x64(Windows10)

【硬件】： R9-5900HS/RTX3060 Laptop

【编译语言】：Python 3.7.9

【测试语言】：日语

【测试模型】：PPOCRv3-日语模型

问题日志及出现问题的操作流程

您好，我们于近期测试发现，FastDeploy在PPOCRv3-日语模型下的识别精度似乎远不及PaddleServing Pipeline(0.8.3)。 👇这是我们用于测试的图片 👆 FD这边测试的服务端代码采用FD提供的example去除CLS流程，加载日语模型后使用: https://github.com/PaddlePaddle/FastDeploy/tree/develop/examples/vision/ocr/PP-OCRv3/python/serving Serving这边的服务端代码: https://github.com/PaddlePaddle/Serving/blob/v0.9.0/examples/Pipeline/PaddleOCR/ocr/web_service.py 请注意，Serving的样例的RecOp内的OCRReader()需要对char_dict_path进行初始化，否则您无法顺利在Pipeline上进行推理。 请注意，由于Serving的兼容性较差，您可能无法在Windows和MacOS上顺利完成推理，需要Linux复现。 我们用于启动FD的命令是:
fastdeploy simple_serving --app server:app
在上述环境下，我们使用FD进行识别得到的结果是:
{
    "result":"{\"boxes\": [[28, 18, 265, 18, 265, 32, 28, 32], [23, 36, 209, 36, 209, 50, 23, 50]], \"text\": [\"(\あ\れ?\ス\ズ\ぐ\ん\、\台\本\持\っ\て\る\", \"\で\も\公\温\の\色\衣\じ\ゃ\な\い\な)\"], \"rec_scores\": [0.8192606568336487, 0.7393889427185059], \"cls_scores\": [], \"cls_labels\": []}"
}
使用PaddleServing Pipeline加载同样模型识别的结果是:
{
    "err_no": 0,
    "err_msg": "",
    "key": [
        "result"
    ],
    "value": ["{\"Result\": [{\"Coordinate\": {\"UpperLeft\": [31.0, 74.0], \"UpperRight\": [553.0, 74.0], \"LowerRight\": [553.0, 101.0], \"LowerLeft\": [31.0, 101.0]}, \"Words\": \"(\あ\れ?\ス\ズ\く\ん\、\台\本\持\っ\て\る\…\", \"Score\": 0.978085994720459}, {\"Coordinate\": {\"UpperLeft\": [20.0, 117.0], \"UpperRight\": [394.0, 117.0], \"LowerRight\": [394.0, 141.0], \"LowerLeft\": [20.0, 141.0]}, \"Words\": \"\で\も\公\演\の\台\本\じ\ゃ\な\い\な)\", \"Score\": 0.8853415250778198}], \"Code\": 0, \"Message\": \"Success\"}"
    ],
    "tensors": []
}
按理来说同样的模型不该产生如此巨大的差异，我们认为FastDeploy进行推理的参数存在问题，导致实际精度不如PaddleServing（例如FD的batch_size是写死的）。详细情况劳烦您进一步代为分析。

你好， 1.请问你的检测模型和识别模型, 还有日文字典文件分别是从哪里下载的呢？ 2.输入给FD和Paddle Serving的模型都是相同的吗？ 3.FD的batch_size, 检测模型默认为1，分类模型默认为1，识别模型默认为6, Paddle Serving也是这样的吗 4.现在看起来, 是检测模型就出现了坐标误差，是否和检测模型的预处理参数有关？Paddle Serving那边是怎么设置的呢

C4a15Wh commented 1 year ago

您好，det和rec模型选用PPOCRv3日语模型：https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.6/doc/doc_ch/models_list.md#23-%E5%A4%9A%E8%AF%AD%E8%A8%80%E8%AF%86%E5%88%AB%E6%A8%A1%E5%9E%8B%E6%9B%B4%E5%A4%9A%E8%AF%AD%E8%A8%80%E6%8C%81%E7%BB%AD%E6%9B%B4%E6%96%B0%E4%B8%AD 我们确定模型相同。给PaddleServing的详细参数:

DET_THR # default: 0.3
DET_BOX_THR # default: 0.6
DET_MAX_CAND # default: 1000
DET_UNCLIP_RATIO # default: 1.5
DET_MIN_SIZE # default: 3

对于REC模块，我们仅在OCRReader()类中指定char_dict和char_type为ch，其余地方均保持默认参数。 serving的预处理部分您可以参考serving的example代码，我们测试时没有做过多改动。

yunyaoXYY commented 1 year ago

您好，det和rec模型选用PPOCRv3日语模型：https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.6/doc/doc_ch/models_list.md#23-%E5%A4%9A%E8%AF%AD%E8%A8%80%E8%AF%86%E5%88%AB%E6%A8%A1%E5%9E%8B%E6%9B%B4%E5%A4%9A%E8%AF%AD%E8%A8%80%E6%8C%81%E7%BB%AD%E6%9B%B4%E6%96%B0%E4%B8%AD 我们确定模型相同。给PaddleServing的详细参数:
DET_THR # default: 0.3
DET_BOX_THR # default: 0.6
DET_MAX_CAND # default: 1000
DET_UNCLIP_RATIO # default: 1.5
DET_MIN_SIZE # default: 3
对于REC模块，我们仅在OCRReader()类中指定char_dict和char_type为ch，其余地方均保持默认参数。 serving的预处理部分您可以参考serving的example代码，我们测试时没有做过多改动。

OK,就等于说，两边的检测模型，用的都是模型库里的 ch_PP-OCRv3_det ，识别模型，用的是 japan_PP-OCRv3_rec 字典用的是，ppocr/utils/dict/japan_dict.txt，我会先去拿这些模型和字典跑一下

yunyaoXYY commented 1 year ago

温馨提示：根据社区不完全统计，按照模板提问，可以加快回复和解决问题的速度

环境

【FastDeploy版本】： fastdeploy-gpu-python 1.0.2与fastdeploy-python 1.0.2均能复现

【系统平台】: Windows x64(Windows10)

【硬件】： R9-5900HS/RTX3060 Laptop

【编译语言】：Python 3.7.9

【测试语言】：日语

【测试模型】：PPOCRv3-日语模型

问题日志及出现问题的操作流程

您好，我们于近期测试发现，FastDeploy在PPOCRv3-日语模型下的识别精度似乎远不及PaddleServing Pipeline(0.8.3)。 👇这是我们用于测试的图片 👆 FD这边测试的服务端代码采用FD提供的example去除CLS流程，加载日语模型后使用: https://github.com/PaddlePaddle/FastDeploy/tree/develop/examples/vision/ocr/PP-OCRv3/python/serving Serving这边的服务端代码: https://github.com/PaddlePaddle/Serving/blob/v0.9.0/examples/Pipeline/PaddleOCR/ocr/web_service.py 请注意，Serving的样例的RecOp内的OCRReader()需要对char_dict_path进行初始化，否则您无法顺利在Pipeline上进行推理。 请注意，由于Serving的兼容性较差，您可能无法在Windows和MacOS上顺利完成推理，需要Linux复现。 我们用于启动FD的命令是:
fastdeploy simple_serving --app server:app
在上述环境下，我们使用FD进行识别得到的结果是:
{
    "result":"{\"boxes\": [[28, 18, 265, 18, 265, 32, 28, 32], [23, 36, 209, 36, 209, 50, 23, 50]], \"text\": [\"(\あ\れ?\ス\ズ\ぐ\ん\、\台\本\持\っ\て\る\", \"\で\も\公\温\の\色\衣\じ\ゃ\な\い\な)\"], \"rec_scores\": [0.8192606568336487, 0.7393889427185059], \"cls_scores\": [], \"cls_labels\": []}"
}
使用PaddleServing Pipeline加载同样模型识别的结果是:
{
    "err_no": 0,
    "err_msg": "",
    "key": [
        "result"
    ],
    "value": ["{\"Result\": [{\"Coordinate\": {\"UpperLeft\": [31.0, 74.0], \"UpperRight\": [553.0, 74.0], \"LowerRight\": [553.0, 101.0], \"LowerLeft\": [31.0, 101.0]}, \"Words\": \"(\あ\れ?\ス\ズ\く\ん\、\台\本\持\っ\て\る\…\", \"Score\": 0.978085994720459}, {\"Coordinate\": {\"UpperLeft\": [20.0, 117.0], \"UpperRight\": [394.0, 117.0], \"LowerRight\": [394.0, 141.0], \"LowerLeft\": [20.0, 141.0]}, \"Words\": \"\で\も\公\演\の\台\本\じ\ゃ\な\い\な)\", \"Score\": 0.8853415250778198}], \"Code\": 0, \"Message\": \"Success\"}"
    ],
    "tensors": []
}
按理来说同样的模型不该产生如此巨大的差异，我们认为FastDeploy进行推理的参数存在问题，导致实际精度不如PaddleServing（例如FD的batch_size是写死的）。详细情况劳烦您进一步代为分析。

你好，我按照上条的两个模型，跑出来的结果，和你的坐标差距较大，我用的图片是你直接传到github这张图片. 我怀疑你的输入并不是这张图片, 能发一张原图吗

C4a15Wh commented 1 year ago

您好，我们这边已经没有保存原图了，但是Serving和FD之间的精度差距是确实存在的，您可以部署后对二者精度差进行分析。

yunyaoXYY commented 1 year ago

您好，我们这边已经没有保存原图了，但是Serving和FD之间的精度差距是确实存在的，您可以部署后对二者精度差进行分析。

你直接用你这张图跑了一下，FastDeploy本地跑demo的结果和PaddleOCR套件库的预测结果是对齐的. SimpleServing由于对图片有压缩过程，和PaddleOCR的检测结果只有像素上有微小差距. 但是我看你直接用PaddleServing推理出的结果和SimpleServing结果差异太大，所以我怀疑是PaddleServing没有和PaddleOCR套件库对齐

C4a15Wh commented 1 year ago

您好，主要不是det的问题，是rec的问题，您可以观察一下FD对复杂汉字的识别，较Serving明显弱了一些。我们再次进行了识别，结果如下：

{
    "err_no": 0,
    "err_msg": "",
    "key": [
        "result"
    ],
    "value": ["{\"Result\": [{\"Coordinate\": {\"UpperLeft\": [31.0, 74.0], \"UpperRight\": [553.0, 74.0], \"LowerRight\": [553.0, 101.0], \"LowerLeft\": [31.0, 101.0]}, \"Words\": \"(\あ\れ?\ス\ズ\く\ん\、\台\本\持\っ\て\る\…\", \"Score\": 0.9780859351158142}, {\"Coordinate\": {\"UpperLeft\": [20.0, 117.0], \"UpperRight\": [394.0, 117.0], \"LowerRight\": [394.0, 141.0], \"LowerLeft\": [20.0, 141.0]}, \"Words\": \"\で\も\公\演\の\台\本\じ\ゃ\な\い\な)\", \"Score\": 0.8853414058685303}], \"Code\": 0, \"Message\": \"Success\"}"
    ],
    "tensors": []
}

laugh12321 commented 1 year ago

我这边用PPVehicle的车牌识别模型，在pipline上测试3张图片，全部检测正确。但是在FastDeploy上只检测正确一次，其中两次连车牌都没有检测上。尝试各种后端都一样。 4951abed976500ad1739bd532c10509a_

huangjun11 commented 11 months ago

你好，请问这个问题得到解决了吗

C4a15Wh commented 11 months ago

没有，我们回去用PaddleServing了

C4a15Wh_5.1 @.***

------------------ 原始邮件 ------------------ 发件人: @.>; 发送时间: 2023年11月26日(星期天) 上午10:56 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [PaddlePaddle/FastDeploy] 使用FastDeploy部署PPOCRv3模型存在精度问题 (Issue #1121)

你好，请问这个问题得到解决了吗

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

PaddlePaddle / FastDeploy