[bamit99]

What

Adds Baidu PaddleOCR (PP-OCR) as a selectable OCR provider alongside the existing chandra option. The user picks the model at deploy time via OCR_PROVIDER, and the weights are downloaded on the fly.

Why two lanes

	chandra (existing)	paddleocr (new)
Model	~5B-param vision-language	PP-OCRv6, 34.5M-param det+rec
Hardware	remote vLLM server, GPU host	CPU, in-process, in this image
Languages	90+	50, one checkpoint
Weights	separate server	downloaded on first use into PADDLE_PDX_CACHE_HOME

chandra stays the high-accuracy lane. PaddleOCR is the lane that works on a self-hosted box with no GPU and no external inference server.

Selecting the model

OCR_PROVIDER=paddleocr (aliases paddle, baidu), then:

Variable	Default	Purpose
PADDLEOCR_MODEL	medium	PP-OCRv6 tier (medium / small / tiny), or an explicit <det>,<rec> pair
PADDLEOCR_DET_MODEL / PADDLEOCR_REC_MODEL	''	Explicit model names; win over PADDLEOCR_MODEL
PADDLEOCR_OCR_VERSION	PP-OCRv6	PP-OCRv6 / PP-OCRv5 / PP-OCRv4
PADDLEOCR_LANG	''	Checkpoint language hint (en, ch, dev, ...)
PADDLEOCR_DEVICE	cpu	cpu or gpu / gpu:0
PADDLEOCR_MIN_SCORE	0	Drop recognised lines below this confidence
PADDLEOCR_IMAGE_DPI	192	Page render DPI

The three PP-OCRv6 tiers are all verified working — each resolves to its own checkpoint and OCRs correctly.

On-the-fly model download

The weights are not baked into the image. PaddleX downloads the selected checkpoint on first use into PADDLE_PDX_CACHE_HOME, which docker-compose.yml points at the mounted HF_HOME volume — so the download happens once and survives a container rebuild.

Verified from a completely empty cache: checkpoint downloaded on demand (133M) and the text came back correctly.

Packaging notes

• Dockerfile — installs libgomp1 (paddle core links against it and refuses to import without it: "Can not import paddle core") and libgl1 / libglib2.0-0 (opencv-contrib loads them at import time).
• pyproject.toml — paddleocr / paddlepaddle are gated to linux/amd64 by marker. paddlepaddle publishes no aarch64 wheels, so the arm64 image cannot carry this lane; the marker keeps uv sync resolving on both architectures. The arm64 image keeps working with chandra / mistral unchanged.

Known workaround

PaddlePaddle 3.3 crashes on CPU in the PIR -> oneDNN conversion:

NotImplementedError: (Unimplemented) ConvertPirAttribute2RuntimeAttribute not support
[pir::ArrayAttribute<pir::DoubleAttribute>]

The FLAGS_* env vars do not fix it (PaddleX picks run_mode=mkldnn independently), so the pipeline is constructed with enable_mkldnn=False. Exposed as PADDLEOCR_ENABLE_MKLDNN, default false.

Verification

• uv sync --frozen (the exact CI command) resolves — uv.lock regenerated.
• 726 passed — full suite, including 14 new unit tests.
• ruff check . — clean.
• Image built and a real PDF OCR'd end-to-end from an empty cache:

  Invoice Number 4471
  Total Amount USD 250.00
  PaddleOCR end to end test
  

• All three tiers (medium / small / tiny) verified.

Files

• pipeline/ocr/paddleocr_local.py — new provider (one class per model, per the provider-plugin convention in CONVENTIONS.md)
• pipeline/ocr/base.py — the OcrConfig contract gains the PaddleOCR knobs
• pipeline/ocr/service.py — provider registered + env-var mapping
• pipeline/ocr/__init__.py — export
• Dockerfile, docker-compose.yml, pyproject.toml, uv.lock — packaging
• .env.example, ENV.md — operator-facing docs
• tests/test_ocr_paddleocr.py — 14 new unit tests

Note: I have read access to this repo but not push access, so this is from a fork. Happy to rebase onto main if the branch has drifted.