docling-project / docling-project/docling

Threaded docling-parse default (2.123.0, #3764) regresses OCR on rasterised page regions vs docling_parse

Open
#4,139 1 comment 0 reactions 1 assignee Claimed by @PeterStaar-IBM View on GitHub
Dominant language
Python
Stars
66.4k
Forks
4.8k
Avg merge
2d 21h
Merged PRs (30d)
84

Description

### Bug

Since docling 2.123.0 made `threaded_docling_parse` the default PDF backend (#3764), OCR text inside **rasterised page regions** is read noticeably worse than with `docling_parse` — characters dropped or substituted in short bitmap text lines — on the same OCR engine, same OCR options, same models.

### Steps to reproduce

Single-page PDF: a CV whose left sidebar (name, email, phone, education, skills) is a rasterised image (rendered at ~150 DPI), the rest is a normal text layer. Converted through **docling-serve** `POST /v1/convert/file` with only the file (all options default), then with `pdf_backend` set explicitly.

| image | request | sidebar email | education line | md5 of `md_content` |
|---|---|---|---|---|
| docling-serve 1.31.0 (docling 2.121.0) | defaults (`pdf_backend=docling_parse`) | `testcandidate @example.org` | `Example Unvrsity,2018` | `ba0817561f…` |
| docling-serve 1.31.0 (docling 2.121.0) | `pdf_backend=threaded_docling_parse` | `testcandidate@exampl.og` | `Example Nniversity, 2018` | `6c8e07f607…` |
| docling-serve 1.32.0 (docling 2.124.0) | defaults (`pdf_backend=threaded_docling_parse`) | `testcandidate@exampl.og` | `Example Nniversity, 2018` | `6c8e07f607…` |
| docling-serve 1.32.0 (docling 2.124.0) | `pdf_backend=docling_parse` | `testcandidate @example.org` | `Example Unvrsity,2018` | `ba0817561f…` |

The output is byte-identical across versions for a given backend, so the difference is entirely the backend, not the model bumps in between. `ocr_engine` (rapidocr / easyocr / tesseract) makes no difference under the threaded backend; `force_ocr=true` (full-page OCR) reads the sidebar correctly under both backends. `images_scale` 1.0 / 2.0 makes no difference.

Observed on Linux x86_64, CPU-only container (`quay.io/docling-project/docling-serve-cpu:v1.32.0`) and on an Intel XPU build of the same version; RapidOCR 3.9.2, EasyOCR 1.7.2, docling-ibm-models 4.0.1, docling-parse 7.16.0.

### Expected behaviour

The threaded backend should hand the OCR engine bitmap crops of the same resolution/quality as `docling_parse` does; a default-backend change should not change OCR results.

### Notes

We are pinning `ConvertDocumentsOptions.pdf_backend` back to `docling_parse` in our images until this is resolved. Happy to share the synthetic fixture PDF (it is generated by a small script — no personal data).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.