Hardcoded scale in TesseractOcrCliModel may not be appropropriate for every image

[raghuraman1]

First of all Docling is great. Thanks.
Now let me describe what made me think there is a bug.

I was using a pdf acro form and populating it with data, flattening it and extracting the image.
This was my image that i was using with docling.
Its a very clean image.
I have to use images as my source.

I figured out that Docling can be configured with mulgtiple OCR engines.
I tried all of them and found that Tesseract was the better for my purpose.
Strangley docling was having some OCR issues even on my clean good quality images.
I tried using same version of tessrecat directly on the images and I did not have the OCR accuracy issues any more.

I used "tesseract -l eng .\imagename.png stdout tsv" directly after copying from my Temp folder and I got same OCR issues.
I noticed that the image had been enlarged when it was copied to the Temp folder.
I tried "tesseract -l eng .\original-image.png stdout tsv" and the errors were gone.

Bug

...
I edited this code-
https://github.com/docling-project/docling/blob/9b51f4f857176cdd95cef53e2ec7f5f32ffbc6a5/docling/models/stages/ocr/tesseract_ocr_cli_model.py

I changed the line "self.scale = 3" to "self.scale = 1" and the OCR issues were gone.
The layout logic did shift a bit but was manageable.

I dont suppose we should be hardcoding the scale factor to 3.
Maybe it should be configurable.
Even better would be to have a logic that checks the image and figures out the effective resolution, image quality and figures out the scale more dynamically

Steps to reproduce

...

Docling version

docling-serve --version
Docling Serve version: 1.26.0
Docling Jobkit version: 2.1.0
Docling version: 2.113.0
Docling Core version: 2.87.1
Docling IBM Models version: 3.13.3
Docling Parse version: 7.8.0
Python: cpython-311 (3.11.9)
Platform: Windows-10-10.0.26200-SP0

docling --version
Docling version: 2.113.0
Docling Core version: 2.87.1
Docling IBM Models version: 3.13.3
Docling Parse version: 7.8.0
Python: cpython-311 (3.11.9)
Platform: Windows-10-10.0.26200-SP0
...

Python version

...

[dosubot]

Hi @raghuraman1! I'm Dosu and I'm helping the IBM Docling team.

You're right — self.scale = 3 is hardcoded in TesseractOcrCliModel [1] and is not exposed as a configurable option in TesseractCliOcrOptions. That options class only exposes lang, tesseract_cmd, path, and psm — no scale parameter [2].

The hardcoded scale=3 converts the 72 DPI base to 216 DPI for OCR, and is passed to page._backend.get_page_image(scale=self.scale, ...) [3]. For already-clean, high-resolution images like yours, this upscaling can actually degrade Tesseract's accuracy — which matches exactly the behavior you observed.

It's worth noting there's a closely related open issue and PR (#3803) addressing a different scaling layer — the PDFium backend's 1.5× supersample-then-downsample behavior that also degrades OCR on raster/scanned pages [4]. That PR adds a configurable PdfBackendOptions.supersample_factor [5], but it operates at the PDF rendering level, not the OCR model level. The two scale parameters are independent — fixing one doesn't address the other.

Your suggestion to make the Tesseract OCR scale configurable (or even dynamic based on image resolution) is a reasonable enhancement request. Other OCR engines in Docling already expose a scale parameter — for example, KserveV2OcrOptions has scale: float = 2.0 [6]. Adding a similar option to TesseractCliOcrOptions would be consistent with that pattern.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.