Threaded docling-parse default (2.123.0, #3764) regresses OCR on rasterised page regions vs docling_parse
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 |
[email protected] |
Example Nniversity, 2018 |
6c8e07f607… |
| docling-serve 1.32.0 (docling 2.124.0) | defaults (pdf_backend=threaded_docling_parse) |
[email protected] |
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).
Source: docling-project/docling