docling-project / docling-project/docling
Threaded docling-parse default (2.123.0, #3764) regresses OCR on rasterised page regions vs docling_parse
- 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
Assessment
This issue has not been assessed yet.