[Discussion] How to get PaddleOCR better maintained.
jzhang533 opened this issue · 40 comments
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: PaddlePaddle/Paddle#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: ext_paddle_oss@baidu.com.
- 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!🥳
Make PaddleOCR great again!🥳
We need to add more cutting-edge OCR models, but this requires computational power resources.
Make PaddleOCR great again!🥳
Willing to do something to make PP-OCR great again within my reach.
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.
另外一个问题：是否考虑将现有项目中的PPOCRLabel、StyleText、ppstructure分离出去？
现有许多问题都交织在一起，耦合太强了。
原谅我这里用中文了，英文表达有些费劲。 我在想一个问题：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 之类的地方。
还有一点我想到的， 现在模型 weights 的托管，是在百度的 bos 上， 我在想，是不是可以托管到 huggingface 之类的地方。
嗯呢，赞同。国内建议自家的AI Studio，国外Hugging Face
还有一点我想到的， 现在模型 weights 的托管，是在百度的 bos 上， 我在想，是不是可以托管到 huggingface 之类的地方。
军哥，如果目的是想摆脱bos的话，其实暂时还有点难度。bos上的东西感觉比较杂，不光光是模型，甚至可能还有图片还有各种打包好的压缩包。全部转移到别的地方，短期内感觉不太现实。
军哥，如果目的是想摆脱bos的话，其实暂时还有点难度。bos上的东西感觉比较杂，不光光是模型，甚至可能还有图片还有各种打包好的压缩包。全部转移到别的地方，短期内感觉不太现实。
嗯，短期内，可以先这样。 先畅想着~
我感觉做到下载整个项目时，总大小不超5M比较合适。大部分都是代码，其实没那么大的。现在整个项目大小起码一百多M
主要是图片字体什么的占了空间。
嗯嗯，后续有什么想要一起做的，可以喊我。光畅想不太行呀
嗯嗯，后续有什么想要一起做的，可以喊我。光畅想不太行呀
是的，现在有四位表达了投入精力维护 PaddleOCR 的想法： @GreatV @Topdu @SWHL @Liyulingyue 。
我们可以在五一之后，正式成立一个 PMC， 然后开始启动 PaddleOCR 的社区化研发。
我提一点哈，我觉得不建议完全脱离研究性方向，标准化，产业化等这一系列成功是因为OCR研究的取得了有效的进展，paddleocr社区当前维护人员的规模可能变换很大，考虑先集中精力从易用向下手保证社区活跃度是非常正确的选择，但是作为国内头部的ocr社区，其实是有责任维护研究向的工作，不建议设计的时候忽视了这方面考虑。
当然了，如果是应用向的开发与维护的工作，这边伸手报名。
研究性和应用可以都考虑。
研究性负责探索最新算法，提供实现算法baseline，便于研究人员快速在上面做实验。
选取最新有效的算法，整合到应用分支，打造最强工业可落地模型。
1，其实大家都很愿意去支持国产框架以及项目的发展,，要发展好一个生态，其实是很难的，感谢百度的付出。
2，我就提一个意见：不要后劲不足(大众普遍对百度系产品以及开源项目的认知)。要么就彻底放弃该项目，开源档另谋出路，要么就好好维护下去，就算开个账户众筹资金，我相信还是有很多人愿意支持的。
1，其实大家都很愿意去支持国产框架以及项目的发展,，要发展好一个生态，其实是很难的，感谢百度的付出。 2，我就提一个意见：不要后劲不足(大众普遍对百度系产品以及开源项目的认知)。要么就彻底放弃该项目，开源档另谋出路，要么就好好维护下去，就算开个账户众筹资金，我相信还是有很多人愿意支持的。
这个很难评。我个人来看，原先的Paddle在开源这块一直是Paddle牵头投资源在搞的（包括其实现在也很依赖Paddle）。由一个公司发起的项目就一定会背指标，那么新项目来了，一些收益不大的旧项目就被放弃了，这挺正常的。
关于后劲的问题，现在已经准备逐渐把部分开源项目彻底社区化了，现在不单单是钱的问题，更多的是很难找到这么多的开发者愿意一起做这件事儿。
大家好呀，想在这里发起一个小讨论：目前PaddleOCR的issue非常之多，部分难定位、难解决的问题给开发者使用造成了困扰。希望可以靠大家的力量一起解决此类问题，提升PaddleOCR的使用体验。看到 @Liyulingyue 已经整理了非常好的模版：https://github.com/PaddlePaddle/PaddleOCR/issues/11906，不过应该如何高效的记录、处理这些问题呢？
目前想到的一个方案，大家看是否可行：
研发同学值班时，对认为无法在短期解决的Issue打一个TAG(例如HardCase或现在已有的triaged)，我们PMC的同学定期筛选标签，看到后记录在#11906 中，并发动更多人报名解决。
除此之外还有什么更好的办法呢？
大家好呀，想在这里发起一个小讨论：目前PaddleOCR的issue非常之多，部分难定位、难解决的问题给开发者使用造成了困扰。希望可以靠大家的力量一起解决此类问题，提升PaddleOCR的使用体验。
我和 @GreatV @Liyulingyue 筛选了一些需要解决的问题。 并专门标注为 triaged: long standing issues
至少这里的问题，靠社区是很难解决的。比如 M2 芯片上运行不了， 内存泄露，等。
我反而觉得，更清晰的 PaddleOCR 的产品定位，做好基础设施建设，明确项目的未来发展目标，这些应该更优先搞清楚。
BTW: PMC 只是还在筹备中，还没成立。
大家好呀，想在这里发起一个小讨论：目前PaddleOCR的issue非常之多，部分难定位、难解决的问题给开发者使用造成了困扰。希望可以靠大家的力量一起解决此类问题，提升PaddleOCR的使用体验。
我和 @GreatV @Liyulingyue 筛选了一些需要解决的问题。 并专门标注为 triaged: long standing issues
至少这里的问题，靠社区是很难解决的。比如 M2 芯片上运行不了， 内存泄露，等。
我反而觉得，更清晰的 PaddleOCR 的产品定位，做好基础设施建设，明确项目的未来发展目标，这些应该更优先搞清楚。
BTW: PMC 只是还在筹备中，还没成立。
我理想的这个TAG下，只包含高频出现且社区可以解决的问题，例如很多人提到的 pyinstaller 打包失败。像M2芯片无法运行、显存泄漏等，或许归类在其他TAG下，推动Paddle适配更合适。
PaddleOCR由于历史问题，很多算法已经不再维护，确实可以做一个整理将不必要的项目移除。
I am working on a meeting agenda for 2024 Q2 paddlepaddle community meeting, see PaddlePaddle/community#889 or rendered version.
One of the topics in the meeting would be discussing establishment of PaddleOCR PMC.
to @Sunting78 @tink2123 @GreatV @Topdu @SWHL @Liyulingyue (PMC candidates): I will create a wechat group, and coordinate the meeting schedule with you.
To those involved in this discussion, if you are interested, please send an email to ext_paddle_oss@baidu.com. I will send you the meeting schedule and agenda once they are finalized.
In my opinion, this repo cantains something outside of the concept of OCR(optical character recognition), e.g. information extraction, which should be split.
我的一些总结, 供大佬们参考, 请不吝赐教: https://cmb-d3-ocr.feishu.cn/docx/TrohdxrDCoQw9zxGCpLcNuZ3nFb
I really think the packaging should be priority, getting paddleOCR working without random segfaults due to some missing dependency is so difficult. I just started trying to use PPStructure and I do not understand why it randomly crashes.
Prioritizing the memory leak in #11639 should also be a priority