人工智能深度学习计算机视觉OCR【免费下载链接】doctrdocTR (Document Text Recognition) - a seamless, high-performing accessible library for OCR-related tasks powered by Deep Learning. Ongoing development and maintenance by t2k.项目地址https://gitcode.com/gh_mirrors/do/doctr点击查看免费下载docTRDocument Text Recognition是一个基于深度学习的 OCR 库覆盖文本检测、文本识别、版面分析与 KIE 等任务。本文面向想要向 docTR 贡献代码的开发者完整梳理贡献者需要掌握的知识仓库代码结构、问题与需求反馈渠道、可编辑开发模式安装、提交规范、单元测试、代码质量检查与文档本地构建。读完本文你将能搭建起与官方 CI 一致的本地开发环境并理解每个质量门禁背后的实现细节与仓库证据。仓库代码结构一次看懂各目录职责在动手贡献之前先了解 docTR 的仓库布局。整个仓库由以下核心目录组成贡献代码时通常只涉及其中一个或几个目录职责doctr包主体代码包含模型检测、识别、版面、表格、KIE、数据集、IO、变换、工具等模块testsPython 单元测试按common框架无关与pytorchPyTorch 后端分目录组织docs基于 Sphinx 的库文档工程docs/source存放 RST 源文件docs/images存放文档图片scripts示例脚本如文本检测 detect_text.py、评估脚本 evaluate.py 与环境收集脚本 collect_env.pyreferences参考训练脚本按任务classification、detection、layout、recognition、table分目录demo展示 docTR 能力的小型 Demo 应用FastAPI PyTorch 后端api用 docTR 部署 REST API 的最小模板包含 FastAPI 路由与 docker-compose.yml从 pyproject.toml 的[tool.setuptools.packages.find]配置可以看到api、demo、docs、notebooks、references、scripts、tests均被排除在打包范围之外只有doctr/是真正随包发布的代码——这印证了doctr目录是贡献的核心区域而其余目录更多承担演示、训练与验证的辅助角色。持续集成CI贡献者只需保证测试覆盖docTR 使用如下集成来维护代码库质量GitHub Workflow在推送与 PR 时自动运行构建和覆盖率相关作业Codecov汇总并回报覆盖率结果。对贡献者而言CI 的硬性要求只有一条为你的代码补充合适的单元测试确保覆盖率达标。仓库中实际配置的 CI 工作流可以帮你理解这一要求的具体形态。以 .github/workflows/main.yml 为例测试工作流拆分为两个并行作业pytest-common运行pytest tests/common/ -rs --cov --cov-reportxml:coverage-common.xml对应框架无关的通用测试pytest-torch运行pytest tests/pytorch/ -rs --cov --cov-reportxml:coverage-pt.xml对应 PyTorch 后端测试。两个作业都通过共享的 setup action.github/actions/setup-env/action.yml完成环境准备其中有两点值得注意在 Linux 上会预先安装 CPU-only 版 PyTorchpip install torch torchvision --index-url https://download.pytorch.org/whl/cpu避免拉取 CI 无法使用的多 GB CUDA 版 torch通过actions/cache缓存~/.cache/doctr与~/.cache/huggingface下的预训练模型加速多轮测试。两个测试作业完成后codecov-upload作业下载两份 XML 覆盖率报告并上传至 Codecovmain.yml。这一作业链与 Makefile 中的make test目标在结构上完全对应因此本地跑make test即可获得与 CI 一致的第一手反馈。反馈渠道问题、特性请求与疑问贡献不只是写代码。在动手之前先了解如何把有价值的信息传递给维护者特性请求与 Bug 报告无论遇到问题还是产生特性建议都建议通过仓库的 Issues 反馈。操作步骤是先检查该话题是否已在某个打开或关闭的 issue中被覆盖若没有再新建 issue。新建时尽量使用 issue 模板并提供足够的信息以便其他贡献者参与。仓库在 .github/ISSUE_TEMPLATE 中提供了三类模板bug_report.ymlBug 报告、feature_request.yml特性请求和config.yml配置。其中 Bug 报告模板强制要求填写Bug 描述、可复现的代码片段、完整错误回溯traceback以及环境信息——环境信息通过运行scripts/collect_env.py脚本生成该脚本就在 scripts/collect_env.py 中。疑问解答如果只是想知道如何用 docTR 做某件事这类使用层面的问题则优先到仓库的 Discussions 提问。它的定位是 QA 论坛相当于docTR 专属的 StackOverflow。开发模式安装搭建可编辑的开发环境在本地开发 docTR首先需要以可编辑editable模式安装全部开发依赖python -m pip install --upgrade pip pip install -e .[dev] pre-commit install三步的含义分别是升级 pip 至最新、以可编辑模式安装包并附带dev额外依赖、注册 pre-commit 钩子。dev额外依赖在 pyproject.toml 中有完整定义实际是一组依赖的合集可拆解为四类PyTorch 运行时torch2.0.0,3.0.0、torchvision0.15.0、onnx1.12.0,3.0.0额外能力extrasweasyprint55.0HTML 导出、matplotlib3.1.0与mplcursors0.3可视化测试pytest-cov7.0.0、onnxruntime1.11.0、requests2.20.0、psutil5.9.5、pandas2.0.0质量ruff0.3.0、mypy1.0、pre-commit3.0.0文档sphinx3.0.0,!3.5.0、sphinxemoji、sphinx-copybutton、docutils0.23、recommonmark、sphinx-markdown-tables、sphinx-tabs、furo主题等。需要说明的是docTR 的运行时要求为requires-python 3.11.0,4pyproject.toml因此在 Python 3.11 及以上版本中开发是前提。pre-commit install则依据 .pre-commit-config.yaml 在本地 git 钩子中注册一系列提交前检查包括check-ast、check-yaml、check-toml、check-json配置文件语法校验check-added-large-files阻止提交大文件docs/images/目录除外end-of-file-fixer、trailing-whitespace文件尾与行尾空白规范debug-statements拦截调试断点残留check-merge-conflict检测未解决的合并冲突标记no-commit-to-branch禁止直接向main分支提交--branch main以及基于 Ruff 的ruff --fix自动修复 lint 问题和ruff-format统一格式。提交规范文档字符串与提交信息docTR 对提交有两个明确要求代码文档字符串所有 Python 代码都必须提供 docstring并遵循Google-style风格可参考 Sphinx Napoleon 扩展的 Google 风格示例这样后续能顺畅地接入文档自动构建流程。从 pyproject.toml 的 Ruff 配置也能看到项目开启了 pydocstyle 规则族D101、D103、D300等并由 CI 的 ruff 作业强制执行同时flake8-quotes规定 docstring 使用双引号docstring-quotes double。提交信息遵循Udacity Git 提交信息指南类型化的type(scope): subject结构如feat(detection): ...便于维护清晰的历史。单元测试make test与覆盖率门槛与 CI 工作流保持一致本地运行同样的单元测试只需make test从 Makefile 可以看到该目标的完整实现test: pytest tests/common/ -rs --cov pytest tests/pytorch/ -rs --cov --cov-append coverage report --fail-under80 --show-missing它依次执行tests/common/与tests/pytorch/两批测试并将两次覆盖率累加最后要求总覆盖率不低于 80%--fail-under80否则视为失败。这正是 CI 中codecov-upload的本地等价物。此外Makefile 还提供了分开运行的入口make test-common只跑通用测试make test-torch只跑 PyTorch 测试。对于新增功能你需要补充对应模块的测试文件。测试体系的质量可以从 tests/conftest.py 中一窥端倪——这里定义了覆盖检测、识别、版面、表格、KIE 等任务的各类 fixturemock_vocab、mock_pdf、mock_image_path、mock_image_folder等基础数据 fixture各类数据集标注 fixture如mock_ic13、mock_svt、mock_synthtext_dataset、mock_cord_dataset、mock_funsd_dataset、mock_wildreceipt_dataset等它们将真实数据集的标注格式XML、JSON、MAT 等以最小化样本复现保证测试无需下载完整数据集还有mock_detection_label、mock_recognition_label、mock_layout_label、mock_table_label等标注格式 fixture。这些 fixture 是编写新测试时可复用的现成资产——在新增数据集支持或新模型时参照对应测试文件如 tests/common/test_models_detection.py、tests/pytorch/test_models_detection_pt.py的模式即可快速接入。代码质量make quality与make styledocTR 提供两个互补的质量入口一次性运行全部质量检查make quality对应的实现Makefilequality: ruff check . mypy doctr/即用ruff做 lint 静态检查、用mypy对doctr/包做类型检查。mypy 的严格配置在 pyproject.toml 中开启了warn_unused_ignores、warn_redundant_casts、no_implicit_optional、check_untyped_defs、implicit_reexport false等选项并对第三方库torchvision、onnxruntime、cv2等忽略缺失的导入存根。CI 中对应的作业在 .github/workflows/style.yml 中ruff作业运行ruff check --diff .只展示差异不修改mypy作业运行mypy并缓存.mypy_cache以加速。运行样式检查可能自动修改文件make style对应的实现Makefilestyle: ruff format . ruff check --fix .注意make style会实际修改代码先格式化再自动修复 lint 问题因此适合在提交前作为自动整理步骤运行而make quality只读检查适合在提交后验证。Ruff 的规则集在 pyproject.toml 中配置启用E/W/F/I/N/Q/C4/T10/LOG等规则族与 pydocstyle 规则行宽上限 120并针对模型、数据集、测试等目录做了 per-file 豁免如tests/**、scripts/**忽略 pydocstyle 规则D。Ruff 的isort配置还指定了doctr、app、utils为一等方模块torch、fastapi、onnxruntime等为第三方模块。修改文档本地构建 Sphinx 文档docTR 的文档由 Sphinx 构建CI 负责自动构建并部署。在本地验证文档修改make docs-single-version其实现Makefiledocs-single-version: sphinx-build docs/source docs/_build -a即用sphinx-build从 docs/source 构建到docs/_build目录-a参数表示全量重建。需要注意的是未修改过的文件不会重建如需强制完整重建可以删除_build目录后重新构建。此外浏览器可能有缓存必要时需要清除浏览器缓存才能看到修改效果。构建完成后用浏览器打开本地文档入口文件docs/_build/index.html即可预览。如果只是做最终发布前的完整构建多版本/带部署逻辑Makefile 还提供了docs目标cd docs bash build.sh这也是 CI 中 .github/workflows/docs.yml 实际执行的命令——CI 构建成功后会把docs/build部署到gh-pages分支。日常文档小改动验证使用make docs-single-version即可。小结一份可执行的贡献清单综合仓库中的实际配置一次规范的 docTR 贡献流程可以归纳为反馈先行通过 Issues 报告 Bug使用模板并附带collect_env.py输出或提出特性请求使用 Discussions 提出疑问搭建环境pip install -e .[dev]pre-commit install在 Python ≥ 3.11 环境下手动安装 PyTorch编写代码为公共接口补充 Google-style docstring提交信息遵循 Udacity 风格补充测试在 tests 的common/或pytorch/对应位置新增测试复用 tests/conftest.py 的 fixture本地验证make test覆盖率 ≥ 80%、make style自动整理、make qualitylint 类型检查、make docs-single-version文档可构建提交 PR推送分支并创建 PR等待 CI.github/workflows/main.yml 的 pytest 作业、.github/workflows/style.yml 的 ruff/mypy 作业全部通过。这套流程的所有环节都能在仓库中找到对应的源码或配置文件依据照着执行即可让本地开发体验与 CI 保持严格一致避免本地通过、CI 挂掉的反复。赞分享人工智能深度学习计算机视觉OCR【免费下载链接】doctrdocTR (Document Text Recognition) - a seamless, high-performing accessible library for OCR-related tasks powered by Deep Learning. Ongoing development and maintenance by t2k.项目地址https://gitcode.com/gh_mirrors/do/doctr点击查看免费下载相关推荐Scrapling 贡献指南从开发环境搭建到 CI 质量门禁的完整实战流程Scrapling 贡献指南从开发环境搭建到 CI 质量门禁的完整实战流程 本文基于 Scrapling 官方贡献文档 CONTRIBUTING.md htt网页爬虫Diem Core 贡献指南从开发环境搭建到高质量 Pull Request 的完整工作流Diem Core 贡献指南从开发环境搭建到高质量 Pull Request 的完整工作流 本篇技术指南以 Diem 官方贡献文档 CONTRIBUTING区块链金融科技IronClaw 贡献指南从开发环境搭建、TDD 工作流到质量门禁的完整实践IronClaw 贡献指南从开发环境搭建、TDD 工作流到质量门禁的完整实践 IronClaw 是一个以隐私、安全与可扩展性为核心的个人 AI 助手操作系统人工智能AI 应用交互助手AI Agent上一篇CoffeeScript 与 let/const块级作用域变量为何未被采纳及其替代方案下一篇Fine_tunning_dr_suggestion实战教程构建智能医疗建议系统的10个步骤创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考