a76yyyy/ddddocr repository overview

⁠ddddocr Docker 镜像（Alpine）

基于 Alpine 的 ddddocr⁠ 运行环境：ddddocr 与它依赖的 OpenCV、onnxruntime 一并预编译，容器内 import ddddocr 即可使用，不需要在目标机器上准备 编译工具链，也不需要自行处理 musl 下的依赖。

• Docker Hub：https://hub.docker.com/r/a76yyyy/ddddocr⁠
• 源码：qd-today/ddddocr-docker⁠

⁠快速开始

docker pull a76yyyy/ddddocr:latest

识别一张本地图片，结果打印到标准输出：

docker run --rm -v "$PWD/captcha.png:/c.png" a76yyyy/ddddocr:latest \
  python3 -c "import ddddocr; print(ddddocr.DdddOcr(show_ad=False).classification(open('/c.png','rb').read()))"

作为基础镜像使用：

FROM a76yyyy/ddddocr:latest

镜像内已有 ddddocr、cv2 与 onnxruntime，直接 import 即可：

import ddddocr

ocr = ddddocr.DdddOcr(show_ad=False)
text = ocr.classification(image_bytes)        # 验证码分类

det = ddddocr.DdddOcr(det=True, show_ad=False)
boxes = det.detection(image_bytes)            # 目标检测

⁠镜像内容

⁠支持的平台

⁠不提供 OCR 的三个平台

linux/386、linux/arm/v6、linux/s390x 的镜像里只有 python3 与 libprotobuf-lite， 既没有 OpenCV，也没有 ddddocr 包本身——import ddddocr 会直接抛 ModuleNotFoundError。 docker pull 在这些架构上会成功，但拉到的镜像无法做验证码识别。

保留它们是为了让 latest 的多架构 manifest 覆盖完整，使以本镜像为基础的项目 （如 pycurl-docker 的 FROM a76yyyy/ddddocr:latest）在这些架构上仍能构建——那些场景 只需要 python3 与 libprotobuf-lite。要在这些架构上识别验证码，需自行编译 onnxruntime 的 Python 绑定。

三个平台缺失的环节并不相同：

⁠loong64 的基础镜像

Docker Hub 的官方 alpine 镜像不提供 loong64 架构，因此 loong64 使用龙芯社区维护的 loong64/docker-library⁠（ghcr.io/loong64/alpine， 源码来自 docker-library）。这是第三方依赖，若其停止维护，需回退到 FROM scratch 加 minirootfs 的方案。loong64 由独立 Dockerfile 构建后合并进主 tag 的 manifest，同时保留 latest-loong64 这类后缀 tag 可直接拉取。

⁠镜像体积

体积构成：

多架构镜像只下载你所在架构的那一份；无 OCR 的三个平台约 25 MB，只有 python3 与 libprotobuf-lite。

⁠标签

发布新版本：把 ddddocr.version 更新为目标 commit，推对应版本号 tag，CI 构建并推送。 默认分支的普通推送不触发构建，仅同步 Docker Hub 上的说明；latest 的日常更新走 workflow_dispatch（勾选 push）。

⁠构建

• OpenCV 源码编译：apk 的 py3-opencv 会带入 Qt / OpenGL / FFmpeg 依赖链（约 236 MB）， ddddocr 用不到；PyPI 也没有 musllinux wheel，因此改为自编最小化版本。
• 镜像精简（去掉约 50 MB 无用内容，不影响功能）：不安装 file 的 magic.mgc 特征库；git 归入构建期 临时依赖，用完即卸；删除 OpenCV 的 haarcascades / lbpcascades 与 /usr/include/opencv4 头文件（/usr/include 的其余内容必须保留——Alpine 3.24 起 pyconfig.h 由 python3 包提供， 是上层镜像编译 C 扩展的前提）；清理 sympy / mpmath 元数据残留与 numpy 测试套件。
• 剥离符号：构建产物经 strip --strip-unneeded 处理。
• 本地构建加速：三个参数留空即与 CI 一致——APK_MIRROR（apk 源）、PIP_MIRROR （pip 索引）、GIT_DOMAIN（ddddocr 源码 clone 的 GitHub 前缀）。 例：docker build --build-arg APK_MIRROR=https://mirrors.tuna.tsinghua.edu.cn .

⁠ARMv7 的 CPU 基线（OPENCV_CPU_BASELINE）

--build-arg OPENCV_CPU_BASELINE=NEON 让自编的 OpenCV 以 NEON 为基线；默认留空，即 ARM32 上不设基线、走标量路径。该参数只影响 OpenCV，也只对 ARM32 有意义——其余架构由 OpenCV 自行检测并启用 SSE2 / NEON 等基线。

默认关闭的原因：

• 收益落不到端到端：验证码图片在 120×40 量级，预处理合计不到 1 ms，而识别时间几乎 都在 onnxruntime 推理上。
• 兼容性：以 NEON 为基线后，import cv2 及任何 OpenCV 调用在无 NEON 的 ARMv7 （如 Marvell Armada 370/XP、部分 Cortex-A5）上会触发 SIGILL。本镜像同时被用作不含 OCR 的 Python 基座，那类用法不需要 NEON。
• 构建耗时明显增加：NEON 基线会把所有向量化分支实例化编译。

onnxruntime 无需为 NEON 自编：上游 cmake/onnxruntime_mlas.cmake 对 CMAKE_SYSTEM_PROCESSOR 匹配 ^arm.* 的情况无条件追加 -mfpu=neon 并编译 NEON 内核， 与发行版的编译参数无关，因此 Alpine 的 armv7 py3-onnxruntime 本身就是 NEON 版本 （readelf -A 可见 Tag_Advanced_SIMD_arch: NEONv1）。这也意味着仅用于 OCR 时，armv7 本来就要求 CPU 支持 NEON：MLAS 只在 ARM64 上做运行时特性检测，ARM32 没有回退路径。

plan    计算架构分组（按 dispatch 的 platforms 输入裁剪）
  ├─ build x86      (ubuntu-latest)     amd64(原生) + 386
  ├─ build arm      (ubuntu-24.04-arm)  arm64(原生) + armv7 + armv6   ← GitHub 原生 arm64 runner
  ├─ build ppc64le  (ubuntu-latest)     ppc64le + s390x
  ├─ build riscv64  (ubuntu-latest)     riscv64
  └─ build loong64  (ubuntu-latest)     loong64（独立 Dockerfile）
        ↓ 全部构建成功
  smoke（9 个平台各一个 job）  复用构建层缓存重建镜像后逐平台实跑（6 个 OCR + 3 个降级检查）
        ↓ 全部冒烟通过
  publish  各架构组按 digest 合并成正式 tag → 校验 manifest 平台完整性