PaddleOCR
PaddleOCR copied to clipboard
PaddlePaddle
[Discussion] How to get PaddleOCR better maintained.
I'd like to start a discussion about maintenance of PaddleOCR project.
Current Status
PaddleOCR is an open-source OCR toolkit, based on PaddlePaddle, and is known for it's high performance, and practical PP-OCR models. While many development activities are conducted by individuals from Baidu, as evidenced by contributors ranked at top of git shortlog -s -n, who are or were Baidu employees, there are also numerous valuable contributions from contributors around the world.
Since the inception of PaddleOCR in 2020, PaddleOCR has become a vital upstream project in the OCR domain, there are 2,328 dependents, with an average of 120 new issues reported every month. Additionally, I have heard of some commercial success cases using PaddleOCR.
However, since last year, development activities have significantly slowed down, with PP-OCR models halted at version 4 and many issues lacking triage, reproduction, and fix. In order to sustainably maintain PaddleOCR, I would like to propose the following actions that the community can take.
Short term actions the community can take
- Help to solve long standing issues: there is a fundable project in recent PaddlePaddle event, please check fundable project NO.6, in this issue: https://github.com/PaddlePaddle/Paddle/issues/62908, and recent progress: #11906.
- Improve dev infrastructure:
- Setup a linting workflow in github action: although there is a pre-commit config in the repository, but never protected by a workflow.
- Migrate CI-PaddleOCR-Py37-LinuxUbuntu-Cuda102-PR-Release to github action: I don’t think we need to identically migrate this workflow. Setup a new CI pipeline in GitHub action to cover testcases and several typical mini-size models running on CPU is enough, since PaddlePaddle/Paddle has sophisticated CI checks.
- Modernize python packaging: using pyproject.toml, as recommended here: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/
- Comply with best OSS practices: set the default branch to a real develop branch, use semantic versioning, etc. I will take this item.
- Improve documentation: dev docs, contribution docs, user facing docs, etc.
Long term actions the community can take
- Establish a Project Management Committee (PMC) to contribute and provide oversight for the project. Anyone who is skilled and interested in investing to this project, please reply or send an email to: [email protected].
- Developing new PP-OCR models: We have organized a competition with OpenAtom Foundation, aimed for accelerating innovation in OCR technologies based on PaddleOCR. However, developing new models is challenging and requiring expertise and resources.
- Design and implement new features.
Although I am not an OCR expert, but I do love open source, please reply to discuss and help to improve maintenance of PaddleOCR.
let me ping some people, who I think could share ideas:
- PaddleOCR key contributors I know: @dyning @tink2123 @Sunting78
- PaddlePaddle OpenSource Development Working Group members: @luotao1 @Aurelius84 @Ligoml @Liyulingyue @Zheng-Bicheng @GreatV @liyongchao911 @jinyouzhi @jzhang533
This post is written in English, so the broader community member can know what's going on, but please feel free to reply in Chinese.
As a member of the PaddlePaddle team, I am very happy to assist everyone who plans to contribute to the PaddleOCR project. Make PaddleOCR great again!🥳
We need to add more cutting-edge OCR models, but this requires computational power resources.
We may organize a PaddleOCR issues solving contest to promote the elimination of accumulated issues in the community.
I personally trained one rec-model on multiple languages. I will add more language dictionaries and corpora that I've collected over the past few months.
原谅我这里用中文了，英文表达有些费劲。 我在想一个问题：PaddleOCR项目的定位是什么？ 是为了成为应用最广泛的开源OCR？还是成为学术界大家以此作为baseline的基础呢？
这个问题很关键，它决定了之后PaddleOCR怎么发展？
从我看到的情况来看，学术界大部分的学者，但凡涉及到OCR相关的研究时，更愿意用mmocr。因此，在我这里，刻板印象是搞学术用mmocr，搞应用用PaddleOCR.
原谅我这里用中文了，英文表达有些费劲。 我在想一个问题：PaddleOCR项目的定位是什么？ 是为了成为应用最广泛的开源OCR？还是成为学术界大家以此作为baseline的基础呢？
这个问题很关键，它决定了之后PaddleOCR怎么发展？
从我看到的情况来看，学术界大部分的学者，但凡涉及到OCR相关的研究时，更愿意用mmocr。因此，在我这里，刻板印象是搞学术用mmocr，搞应用用PaddleOCR.
我其实没明白搞学术和搞应用上侧重的点分别是什么，按我的理解来看，mmocr似乎和ppocr没有特别大的区别呀。
我觉得还是要定位成应用广泛的开源 OCR，才有独特价值。如果做学术界的 baseline 的话，很现实的问题是 paddle 在学术界的使用还远不如 pytorch。
代码仓库确实需要有一个较大的调整才行，我现在看的也是有些懵，这里有不少历史原因。
原谅我这里用中文了，英文表达有些费劲。 我在想一个问题：PaddleOCR项目的定位是什么？ 是为了成为应用最广泛的开源OCR？还是成为学术界大家以此作为baseline的基础呢？ 这个问题很关键，它决定了之后PaddleOCR怎么发展？ 从我看到的情况来看，学术界大部分的学者，但凡涉及到OCR相关的研究时，更愿意用mmocr。因此，在我这里，刻板印象是搞学术用mmocr，搞应用用PaddleOCR.
我其实没明白搞学术和搞应用上侧重的点分别是什么，按我的理解来看，mmocr似乎和ppocr没有特别大的区别呀。
搞学术侧重的是可以复现算法在论文中的效果，提供算法基线 搞应用侧重的是方便部署，依赖少，泛化强，效果好。这个可以参考我们搞的：RapidOCR，不管模型是什么，只要最好的。
目前PaddleOCR的优势在于轻量效果最强，可以说做到了极致。但是由于Paddle推理框架的束缚，导致在学术界差了些。
Paddle框架有些硬伤会间接影响PaddleOCR。比如内存泄漏、兼容性、生态不足等。
目前PaddleOCR的优势在于轻量效果最强，可以说做到了极致。但是由于Paddle推理框架的束缚，导致在学术界差了些。
Paddle框架有些硬伤会间接影响PaddleOCR。比如内存泄漏、兼容性、生态不足等。
内存泄露似乎torch也有，后两个确实不是短时间内能解决的
抛开Paddle框架的原因，说回这个项目。 我觉得优化点可以从以下几点着手：
- 耦合项目剥离
- 完善Action，自动化规范化代码、发版
- Github中Issue、 Discussion和Project利用起来，各个issue做分类。bug放到issue，讨论需求放到discussion中。修复进度关联到project。感觉1.2k个issue中，大部分都是无效提问，可以先做个整理。
简单想法哈，没有任何恶意。
我觉得还是要定位成应用广泛的开源 OCR，才有独特价值。如果做学术界的 baseline 的话，很现实的问题是 paddle 在学术界的使用还远不如 pytorch。
代码仓库确实需要有一个较大的调整才行，我现在看的也是有些懵，这里有不少历史原因。
Paddle的套件确实都有类似的问题（写的比较死），比如PaddleClas你想通过yaml配置MobileNetV3_0x25是没问题的，但是配置MobileNet_0x125居然就不行了，还需要自己修改代码。
抛开Paddle框架的原因，说回这个项目。 我觉得优化点可以从以下几点着手：
- 耦合项目剥离
- 完善Action，自动化规范化代码、发版
- Github中Issue、 Discussion和Project利用起来，各个issue做分类。bug放到issue，讨论需求放到discussion中。修复进度关联到project。感觉1.2k个issue中，大部分都是无效提问，可以先做个整理。
简单想法哈，没有任何恶意。
哈哈哈，畅所欲言啦，Paddle社区的G点没那么多，放心。
我觉得还是要定位成应用广泛的开源 OCR，才有独特价值。如果做学术界的 baseline 的话，很现实的问题是 paddle 在学术界的使用还远不如 pytorch。 代码仓库确实需要有一个较大的调整才行，我现在看的也是有些懵，这里有不少历史原因。
Paddle的套件确实都有类似的问题（写的比较死），比如PaddleClas你想通过yaml配置MobileNetV3_0x25是没问题的，但是配置MobileNet_0x125居然就不行了，还需要自己修改代码。
对，看着很全，很多。其实，一试用demo以外的算法，多半都会报错
还有一个比较重要的是：将项目文档独立为一个单独仓库。重新整理，编写。在独立文档项目中支持i18n
现在文档散落在项目中，太乱了。
我感觉做到下载整个项目时，总大小不超5M比较合适。大部分都是代码，其实没那么大的。现在整个项目大小起码一百多M
还有一个比较重要的是：将项目文档独立为一个单独仓库。重新整理，编写。在独立文档项目中支持i18n
现在文档散落在项目中，太乱了。
我感觉做到下载整个项目时，总大小不超5M比较合适。大部分都是代码，其实没那么大的。现在整个项目大小起码一百多M
这个确实是，现在文档太散乱了。 按道理，应该有一个专门展示文档的站点，还要做好 i18n ，现在国际的用户也挺多的，对他们非常不友好。
代码仓库里的数据之类的，应该找更适合的地方存储。
还想到两点：
- PaddleOCR whl版本需要瘦身，更新起来，毕竟大多数用户都是pip使用的
- 在线demo要重新做一下，兼顾各个语言的
表明态度：我乐意和大家一起完善这个仓库
还有一点我想到的， 现在模型 weights 的托管，是在百度的 bos 上， 我在想，是不是可以托管到 huggingface 之类的地方。
嗯呢，赞同。国内建议自家的AI Studio，国外Hugging Face
还有一点我想到的， 现在模型 weights 的托管，是在百度的 bos 上， 我在想，是不是可以托管到 huggingface 之类的地方。
军哥，如果目的是想摆脱bos的话，其实暂时还有点难度。bos上的东西感觉比较杂，不光光是模型，甚至可能还有图片还有各种打包好的压缩包。全部转移到别的地方，短期内感觉不太现实。
军哥，如果目的是想摆脱bos的话，其实暂时还有点难度。bos上的东西感觉比较杂，不光光是模型，甚至可能还有图片还有各种打包好的压缩包。全部转移到别的地方，短期内感觉不太现实。
嗯，短期内，可以先这样。 先畅想着~
嗯嗯，后续有什么想要一起做的，可以喊我。光畅想不太行呀
是的，现在有四位表达了投入精力维护 PaddleOCR 的想法： @GreatV @Topdu @SWHL @Liyulingyue 。 我们可以在五一之后，正式成立一个 PMC， 然后开始启动 PaddleOCR 的社区化研发。
我提一点哈，我觉得不建议完全脱离研究性方向，标准化，产业化等这一系列成功是因为OCR研究的取得了有效的进展，paddleocr社区当前维护人员的规模可能变换很大，考虑先集中精力从易用向下手保证社区活跃度是非常正确的选择，但是作为国内头部的ocr社区，其实是有责任维护研究向的工作，不建议设计的时候忽视了这方面考虑。
当然了，如果是应用向的开发与维护的工作，这边伸手报名。
研究性和应用可以都考虑。 研究性负责探索最新算法，提供实现算法baseline，便于研究人员快速在上面做实验。 选取最新有效的算法，整合到应用分支，打造最强工业可落地模型。