新增需求征集（Collect Feature Request）
shiyutang opened this issue · comments
我们将这个Issue 保持开放状态，以收集用户的功能请求并听取您的声音。我们的发布计划将在不同的问题上进行更新。
在这个Issue中，您可以：
- 通过发表评论来建议新功能。
- 使用 👍 投票支持功能请求，或者使用 👎 反对。 （请记住，我们也许无法响应所有功能请求，因此请投票给您最喜欢的功能请求！）
- 如果你也愿意参加代码贡献，欢迎参与我们的活动 #10223。
- 我们会在上述活动的技术研讨会中对需求进行讨论，如果想要参与讨论你觉得重要的需求，欢迎加入上述活动微信群。
We keep this issue open to collect feature requests from users and hear your voice. Our release plan will be updated on different issues.
In this issue, you can either:
- Suggest a new feature by leaving a comment.
- Vote for a feature request with 👍 or be against it with 👎. (Remember that developers are busy and cannot respond to all feature requests, so vote for your most favorable one!)
- Tell us that you would like to help implement one of the features in the list or review the PRs. Welcome to participate in our activity #10223(This is the greatest thing to hear about! )
- Join the above WeChat group in the activity link if you want to discuss the new features with us
范例：
需求描述：支持文本识别单字位置分割；支持更多小语种模型；训练语种分类模型；文本识别返回单字置信度等
需求场景（这个需求可以解决哪些应用场景的问题）： 覆盖小语种的分类场景
潜在解决方案（问题分解）：调取小语种数据集进行训练。
example:
Description of feature request:
Requirement scenarios (what application scenarios can this feature request solve):
Potential solutions (problem breakdown):
需求描述：
版面恢复里的功能（恢复为docx或者excel）c++版。
需求场景：
c++版本可以部署到端侧，实现本地本地化的办公文档扫描。
潜在解决方案：
版面分析后，使用minidocx创建docx文档，libxlsxwriter生成excel。
需求描述：
返回单字符坐标。
需求场景：
文档比对。
需求描述：
拍照图片矫正模型。
需求场景：
办公文档扫描时，对倾斜等图片进行类似边缘检测，透视变换等的矫正功能。
需求描述：
返回单字符坐标。
需求场景：
ocr 之后 NLP场景需要对应到原图上的文字位置
需求描述：一个支持简繁英日的东亚模型
需求场景：多语言并存场景下的识别
潜在解决方案（问题分解）：
需求描述：表格结构提取
场景：各种业务场景下的表格，其中包括有线、无线表格
潜在解决方案（问题分解）：
需求描述：古籍识别
需求场景：繁体字识别来一下？
范例：
需求描述：版面矫正网络论文复现：DocTr++: Deep Unrestricted Document Image Rectification
需求场景（这个需求可以解决哪些应用场景的问题）：大量文档进行版面分析之前需要进行光照、扭曲等矫正
说明：
- 通过定量实验和定性对比，作者团队验证了 DocTr++ 的性能优势及泛化性，并在现有及所提出的基准测试中刷新了多项最佳记录，是目前最优的文档矫正方案。
- 暂时没有预训练权重和训练代码，需要按照论文描述重新训练尝试。
潜在解决方案（问题分解）：复现上述论文，代码链接：https://github.com/fh2019ustc/DocTr-Plus
Scene Text Recognition with Permuted Autoregressive Sequence Models,即parseq 文本识别算法效果不错，有没有在paddleOCR上实现。
需求描述：PaddleOCR与PaddleDetection与Pillow新版本10.x不兼容。目前PaddleOCR采用的临时解决方案是在依赖列表中限制只能使用旧版本Pillow（参见 #10344 ），而PaddleDetection未采取任何措施（按照文档安装后，使用deploy/python/visualize.py等部分功能时会直接报错）。出于套件可持续建设的考虑，希望能够适配最新版本的Pillow。
需求场景： 目前已发现涉及使用字体的相关场景存在此问题。
潜在解决方案：
- 对于PaddleOCR和PaddleDetection，修改过时的接口名称或参数（例如
FreeTypeFont.getsize），替换为等效的API调用； - 对于PaddleOCR，去除
requirements.txt中Pillow版本的限制。
需求描述：
当前ppocrv3模型存在以下问题：
1 字典不全，没有覆盖《通用规范汉字表》
2 对于字典中存在的生僻字，可能因为训练语料不平衡问题，识别效果很差
希望：
1 扩充中文字典，覆盖《通用规范汉字表》
2 增加平衡语料，重新训练
需求场景：
姓名，古文识别等场景
需求描述：
ocr det 之前增加文档方向检测和矫正过程，支持0,90,180,度的文档，
可以作为ppocr命令行参数
需求场景：
手机拍照，文档材料数字化自动化场景
你好，我基于paddleocr转换了模型，重构了推理代码，可脱离paddlepaddle训练框架，在精度不变的情况下效率和推理速度都提高了：https://github.com/jingsongliujing/OnnxOCR
你好，这个可以提交PR到我们的repo中吗？@jingsongliujing
你好，这个可以提交PR到我们的repo中吗？@jingsongliujing
后续是这样，但是不知道提交到那个repo
来源：Issue #10404
需求描述：支持更长文本输入（＞512 tokens）的KIE模型
需求场景：许多进行KIE的文档都存在大于512 tokens的情况
潜在解决方案（问题分解）：现有的KIE模型大多基于MVLM（Masked Visual language Model），与Bert（MLM，Masked language Model）的网络架构相似，可以参考现有的利用Bert进行处理长文本的方法，比如sliding window approach
paddleocr.py介绍太简单，有点不会用
当前 https://github.com/PaddlePaddle/PaddleOCR/blob/dygraph/doc/doc_ch/quickstart.md 介绍文档过于简单，建议增加使用介绍。
• 1：增加api使用介绍
• 2：增加命令行使用介绍
• 3：适当增加使用demo
找到了部分： https://gitee.com/PaddlePaddle/PaddleOCR/blob/release/2.6/doc/doc_ch/whl.md
这个文件名起的很简略，我给忽略没看到。。。。。。
paddleocr.py介绍太简单，有点不会用
这个确实存在相关问题，关于PPOCR的参数在下面的文档中：https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.6/doc/doc_ch/inference_args.md
需求描述：为PaddleOCR增加训练时周期性验证的开关；为PaddleOCR增加eval_epoch_step参数。
需求场景：与PaddleCV的其它基础套件PaddleSeg、PaddleDetection、PaddleClas、Paddle3D等不同，PaddleOCR不支持上述功能，这导致包括但不限于如下问题：
- 用户有时只想要将模型训练一定的迭代轮数，并不希望在训练时进行精度评估（这可能带来额外的时间开销），而目前PaddleOCR无法优雅地满足这个需求，只能通过设定一个较大的
eval_batch_step数值来实现。 - 更换数据集后，由于数据集大小发生改变，用户往往也需要修改
eval_batch_step配置，以使得eval频率合适。 - PaddleOCR中实现的是epoch-based trainer，在配置文件中设置的也是
epoch_num而不是num_iters，但eval_batch_step却是iters粒度的控制，存在风格不契合的问题。
潜在解决方案：
考虑后向兼容的解决方案：
- 增加
do_eval配置项，可用于关闭训练时周期性验证。默认启用验证，基本维持PaddleOCR现有行为，但希望在训练结束时，即使没有到达eval_step，也进行一次验证（因为有时候eval_step设置不合适，可能会出现指定了do_eval却没有验证的情况，不符合直觉）。 - 在保留
eval_batch_step的情况下，增加eval_epoch_step配置项。关于eval_batch_step与eval_epoch_step之间的关系如何，例如二者互斥或其中一个的优先级更高，我还没有想好，建议开发者从用户使用便利性的角度考虑如何设计。eval_batch_step应当被添加为可选功能，套件的默认行为保持不变。
需求描述：复现论文pidnet
需求场景（这个需求可以解决哪些应用场景的问题）： 该模型为轻量化分割方向的前沿模型，超过自研模型ppliteseg精度和速度平衡，进度直逼高精度OCRNet。
潜在解决方案（问题分解）：
数据和模型、代码均已经开源，可以基于论文复现指南复现上述论文，代码链接：https://github.com/XuJiacong/PIDNet
需求描述：根据原作者提出的建议，复现论文MobileSAM
需求场景（这个需求可以解决哪些应用场景的问题）： 该模型为火爆的SAM模型的加速版本，大大提升了SAM的使用体验，该模型目前已经有2.9k star。
潜在解决方案（问题分解）：
模型、代码已经开源，只需进行前向对齐即可，可以基于论文复现指南复现上述论文，代码链接：https://github.com/ChaoningZhang/MobileSAM
需求描述：根据 @printfxs 的建议，复现论文Parseq
需求场景（这个需求可以解决哪些应用场景的问题）： 该模型将视觉和语义信息结合，实现精度和速度的双重提升，对比前沿模型SVTR有进一步优势。
潜在解决方案（问题分解）：
模型、代码、数据集已经开源，可以基于论文复现指南复现上述论文，代码链接：https://github.com/baudm/parseq
需求描述： 识别文档中的数学公式（LaTex）
需求场景： 科技技术类的PDF文件往往有很多计算公式，目前没法有效识别，例如下角标等
需求描述： 支持小语种-藏文
需求场景： 对藏文的书籍、文稿进行文字提取
需求描述：给 fastdeploy服务化部署 的方式提供修改参数的地方，文档没教我也没找到能修改生效的地方。
需求场景：我需要限制生成的文本框数量，这个参数max_candidates符合，但是我找不到办法把这参数应用在fastdeploy服务化部署里面。目前我只能对识别结果取限制的数量，有点治标不治本。
需求描述：返回字符旋转角度。
需求场景：扫描件文件识别以及自动转正。
需求描述：
fastdeploy ios版本编译。
需求场景：
统一化使用fastdeploy部署符合项目发展趋势，也便于项目的推广。
@HackerWand 我们准备复现doctr++的文档矫正功能，即可实现你的需求。
@zhouyiminga FastDeploy支持部分参数的修改，后续将有开发者在Issue #10562 中分享具体的做法
需求描述：
实时手写汉字识别。
需求场景：
教育场景应用。
需求描述： 实时手写汉字识别。 需求场景： 教育场景应用。
从哪里收流？
需求描述：
针对关键信息提取，可以分为三个阶段，分别为检测识别kie， 每个阶段都相应的评价指标。但是没有一个指标来衡量整个pipeline的效果，值得开发出相关指标用来衡量。
需求场景：
卡证识别
希望官方能够更详细的测试fastdeploy serving的方式启动的服务到底推理速度如何。
根据我在多种英伟达GPU平台测试的结果，使用triton的部署方式是比纯api调用的响应时间慢至少8到10倍（无并发，单次推理）。我觉得有以下几方面原因
- OCR的ensemble写得太复杂，step多了之后，队列太多，会造成大量overhead，造成推理时间大量浪费在IO上面。
- 目前提供的镜像，还是根据triton 2021年10月的镜像打的，落后太多。
希望KIE任务可以添加置信度，目前只有pred_id；另外能否明确一下KIE如何部署到fastapi这种api框架？
需求描述：
支持paddleOCR和其他模型一起使用的时候的多进程使用
需求场景：
不同模型（pytorch,paddle,tensorflow模型）之间的并行使用
表格恢复模型
需求描述：
目前SLANet模型效果比较差，尤其是无线框表格和存在跨行的表格
需求场景：
表格恢复，excel表格恢复等
@wxzwxz131 目前我们有两种表格识别的算法，table master和SLANet，请问是否这两种算法在官方训练的数据上对无框和跨行情况都表现很糟糕？如果是，是否有效果更好的表格回复算法推荐呢？
希望可以将现有的问题记录在一个新建issue中，方便我们跟进
@HackerWand 我们准备复现doctr++的文档矫正功能，即可实现你的需求。
@shiyutang 应该如何做呢？
@HackerWand 我们的开源社区正在在进行doctr++的复现，其可以实现这个功能：#10379
标注工具ppocrlabel，能不能让我们自己选择文字检测或者文本识别的模型；还有，能不能只检测文字区域，或者只识别文字
建议增加新增字符的功能，因为有很多场景会有一些特殊字符或者语言，这样可以提高ppocr的可用性
需求描述：提供参数接口，传入仅需识别的部分字符（比如仅数字、仅个别英文字母等)，避免识别为其他相似字符（比如数字1和i，数字0和字母O……）
需求场景： 在特定范围识别时，准确性低（比如生产手写数字数据识别不准）
潜在解决方案：个人通过修改后处理过程已经实现了相关功能，但使用不方便：
修改rec_postprocess.py文件中的class CTCLabelDecode(BaseRecLabelDecode):
思路：在所有字符概率中，挑选出我们关心的字符概率，在挑选之后看哪个概率最大……
def __call__(self, preds, label=None, *args, **kwargs):
if isinstance(preds, tuple) or isinstance(preds, list):
preds = preds[-1]
if isinstance(preds, paddle.Tensor):
preds = preds.numpy()
'''
limit_char_list = list("0123456789") # 这里仅识别阿拉伯数字，根据情况增加小数点或其他字符
limit_char_list.append("blank") # 必须增加空值【此项是self.character中的第一项，必须加上！！】
# limit_char_list.append(" ") # 这行应该没有太大影响
# 获取要识别的字符（比如0-9）在整个字符集self.character中的位置Index
char_ind = [self.character.index(char) for char in limit_char_list]
# [26, 93, 25, 94, 632, 631, 933, 29, 27, 1109, 0] 不连续的，和chinese_dict.txt中的次序不一样！
# 从preds结果中筛选出我们需要识别字符的概率数据
my_preds=preds[:,:,char_ind]
# 获取my_preds中的最大概率和对应索引及概率值
my_preds_idx = my_preds.argmax(axis=2) # 注意返回的最大概率序号是mypreds中的序号，也是limit_char_list中的序号，不是preds中的序号
preds_prob = my_preds.max(axis=2)
# 将序号列表中自定义字符中的次序修改为self.character中的次序
preds_idx = np.empty(shape=preds_prob.shape)
for i,row in enumerate(my_preds_idx):
preds_idx[i,:] = [ char_ind[j] for j in row ]
preds_idx = preds_idx.astype(int)
'''
preds_idx = preds.argmax(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行
preds_prob = preds.max(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行建议增加新增字符的功能，因为有很多场景会有一些特殊字符或者语言，这样可以提高ppocr的可用性
你好，新增字符的方式需要重新加入新的字典和数据，并对模型进行finetune。
需求描述：提供参数接口，传入仅需识别的部分字符（比如仅数字、仅个别英文字母等)，避免识别为其他相似字符（比如数字1和i，数字0和字母O……） 需求场景： 在特定范围识别时，准确性低（比如生产手写数字数据识别不准） 潜在解决方案：个人通过修改后处理过程已经实现了相关功能，但使用不方便： 修改rec_postprocess.py文件中的class CTCLabelDecode(BaseRecLabelDecode): 思路：在所有字符概率中，挑选出我们关心的字符概率，在挑选之后看哪个概率最大……
def __call__(self, preds, label=None, *args, **kwargs): if isinstance(preds, tuple) or isinstance(preds, list): preds = preds[-1] if isinstance(preds, paddle.Tensor): preds = preds.numpy() ''' limit_char_list = list("0123456789") # 这里仅识别阿拉伯数字，根据情况增加小数点或其他字符 limit_char_list.append("blank") # 必须增加空值【此项是self.character中的第一项，必须加上！！】 # limit_char_list.append(" ") # 这行应该没有太大影响 # 获取要识别的字符（比如0-9）在整个字符集self.character中的位置Index char_ind = [self.character.index(char) for char in limit_char_list] # [26, 93, 25, 94, 632, 631, 933, 29, 27, 1109, 0] 不连续的，和chinese_dict.txt中的次序不一样！ # 从preds结果中筛选出我们需要识别字符的概率数据 my_preds=preds[:,:,char_ind] # 获取my_preds中的最大概率和对应索引及概率值 my_preds_idx = my_preds.argmax(axis=2) # 注意返回的最大概率序号是mypreds中的序号，也是limit_char_list中的序号，不是preds中的序号 preds_prob = my_preds.max(axis=2) # 将序号列表中自定义字符中的次序修改为self.character中的次序 preds_idx = np.empty(shape=preds_prob.shape) for i,row in enumerate(my_preds_idx): preds_idx[i,:] = [ char_ind[j] for j in row ] preds_idx = preds_idx.astype(int) ''' preds_idx = preds.argmax(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行 preds_prob = preds.max(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行
看上去你已经实现了相关功能，请问为什么使用不方便呢？ 欢迎给我们贡献相关代码。
请求新增针对给定图片的语言进行判定的模型。例如对于包含日文的图判定为japanese、对包含俄语的图判定为russian，对于只包含中英的图判定为cn_en。
这个特性的实际意义是，在进行ocr任务的时候，可以对检测到的区域的语言进行判定，以便自动选用合适的文本识别模型，这样即可比较优雅地完成针对任意多语言的ocr任务。
当然，更进一步，可以针对给定的图片进行进一步的拆分，将各个子区域的语言均给出预测，这样甚至可以做到对复杂的多语言混合内容（比如日语、俄语、中文、英文混合的情况）进行准确地识别。
BTW：实际上直接训练一个支持现有主要语言的检测和识别模型也同样可以解决此问题。
需求描述：提供参数接口，传入仅需识别的部分字符（比如仅数字、仅个别英文字母等)，避免识别为其他相似字符（比如数字1和i，数字0和字母O……） 需求场景： 在特定范围识别时，准确性低（比如生产手写数字数据识别不准） 潜在解决方案：个人通过修改后处理过程已经实现了相关功能，但使用不方便： 修改rec_postprocess.py文件中的class CTCLabelDecode(BaseRecLabelDecode): 思路：在所有字符概率中，挑选出我们关心的字符概率，在挑选之后看哪个概率最大……
def __call__(self, preds, label=None, *args, **kwargs): if isinstance(preds, tuple) or isinstance(preds, list): preds = preds[-1] if isinstance(preds, paddle.Tensor): preds = preds.numpy() ''' limit_char_list = list("0123456789") # 这里仅识别阿拉伯数字，根据情况增加小数点或其他字符 limit_char_list.append("blank") # 必须增加空值【此项是self.character中的第一项，必须加上！！】 # limit_char_list.append(" ") # 这行应该没有太大影响 # 获取要识别的字符（比如0-9）在整个字符集self.character中的位置Index char_ind = [self.character.index(char) for char in limit_char_list] # [26, 93, 25, 94, 632, 631, 933, 29, 27, 1109, 0] 不连续的，和chinese_dict.txt中的次序不一样！ # 从preds结果中筛选出我们需要识别字符的概率数据 my_preds=preds[:,:,char_ind] # 获取my_preds中的最大概率和对应索引及概率值 my_preds_idx = my_preds.argmax(axis=2) # 注意返回的最大概率序号是mypreds中的序号，也是limit_char_list中的序号，不是preds中的序号 preds_prob = my_preds.max(axis=2) # 将序号列表中自定义字符中的次序修改为self.character中的次序 preds_idx = np.empty(shape=preds_prob.shape) for i,row in enumerate(my_preds_idx): preds_idx[i,:] = [ char_ind[j] for j in row ] preds_idx = preds_idx.astype(int) ''' preds_idx = preds.argmax(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行 preds_prob = preds.max(axis=2) #若仅识别特定字符，将上面的块注释去掉，并注释掉这行看上去你已经实现了相关功能，请问为什么使用不方便呢？ 欢迎给我们贡献相关代码。
需要来回注释代码，个人再去改命令行的代码改动的位置可能有点多，能力有限，代码效率不一定好；建议官方增加一个命令行参数，传入仅需要识别的字符（字符串或者类似dict.txt字典文件的样子）这样来用更方便。
此外，个人根据调试信息，仅修改的CTCLabelDecode类里面的代码，该文件中还有其他相似的类应该也可以进行类似调整，但那些类在什么时候调用不清楚，还没有吃透整体的程序处理流程
基于昆仑芯R200适配PaddleOCR
建议增加新增字符的功能，因为有很多场景会有一些特殊字符或者语言，这样可以提高ppocr的可用性
你好，新增字符的方式需要重新加入新的字典和数据，并对模型进行finetune。
你好，使用新增数据进行增量训练之后，模型本身的识别能力会严重下降吗？
识别后的文字根据原文恢复排版，去除拍照造成的同一行字Y轴不同的现象。
建议增加新增字符的功能，因为有很多场景会有一些特殊字符或者语言，这样可以提高ppocr的可用性
你好，新增字符的方式需要重新加入新的字典和数据，并对模型进行finetune。
你好，使用新增数据进行增量训练之后，模型本身的识别能力会严重下降吗？
可以微调，减少轮数/学习率，
不会过于严重
识别后的文字根据原文恢复排版，去除拍照造成的同一行字Y轴不同的现象。
我们已经支持返回单字识别的坐标了，可以基于这个#10515 ，使用自己的字体恢复
非常感谢，我去试试
需求描述：PPOCRLabel工具在表格结构识别标注的功能中，增加对单元格标注框类别class label的标注功能
需求场景：给表格标注增加单元格类别标注
潜在解决方案（问题分解）：改进PPOCRLabel工具
#10404 ，这个issue看回复说登记到需求池里面了，点击进来没看到，再update一下~
需求描述：KIE (SER和RE两个任务)支持长度大于512的文档infer
需求场景：很多图片的文字内容长度都超过512这个范围限制了，希望能支持该功能，或者是否现在有其他替换方案
需求描述：c++版本tensorRT的demo每次运行都要大量时间构建trt-engine,期望提供一个临时cache文件夹，固化保存
需求场景： trt方案中，进程重启的场景
潜在解决方案（问题分解）：fastDeploy中提供了trt_engine的cache路径。
带文字的图像矫正模型，可以矫正任意角度的图片
需求描述：针对文本检测在行列方向遇到离得近的文本可能更会检测成同一区域文本，大多数文档的表格中的单元格文字可能在行方向的文本之间的距离比在列方向的文本离得还远，那么就会出现把列方向的文本检测为同一区域文本。希望文本检测模型能分开行检测和列检测模型。
需求场景（这个需求可以解决哪些应用场景的问题）： 大多数存在表格的文档图像，比如户口本、发票、驾驶证等
潜在解决方案（问题分解）：文本检测模型分别微调出行检测和列检测模型。
需求描述： 返回单字符坐标。 需求场景： 文档比对。
请问现在有技术去实现吗
范例：
需求描述：支持工业场景文本识别，主要是背景复杂，字体边界容易有背景干扰，也就是说字体分割无法和背景清晰分出
需求场景（这个需求可以解决哪些应用场景的问题）：工业零件上字体识别，新生产的字体清晰，但维修或者旧的不清晰
潜在解决方案（问题分解）：负责背景识别
需求描述:希望能在apple m2上可以完全运行
需求描述：自然场景下的繁体字识别（chinese_cht_PP-OCRv3对于一些自然场景中的文字识别的不够准确）
需求场景：繁体字地区自然场景下的繁体字识别，如路牌、店铺名称等。
需求描述：基于C#预测引擎推理部署
需求场景：各类基于.Net平台的项目中，能够方便的调用模型进行识别工作
潜在解决方案（问题分解）：使用C#语言编写一个推理部署的样例项目。
需求描述：国际化切换后文本布局对比。
需求场景（这个需求可以解决哪些应用场景的问题）： 网站进行语言切换后，识别排版是否混乱，如文本溢出、高度溢出等异常场景，与无头浏览器结合为国际化测试解决方案。
潜在解决方案（问题分解）：对页面截图进行文本区域检测，对比文本区域数量、文本区域的大小。
不知道是什么语种的时候希望加一个自动识别语言的多语言模型