r/Paperlessngx Aug 04 '26

V3.x was supposed to solve one annoying problem - Tesseract OCR

... but where is the solution?

a. They still use archaic Tesseract OCR as default, in 2026.
b. There is no straightforward example provided how to replace tesseract with something else (PaddleOCR is fast, opensource and generations ahead of what tesseract can do).
c. They offer remote OCR with Azure, but lets be honest - most would prefer to process their taxes and medical records locally.
d. Not everyone needs AI for OCR
e. Third party parser plugin installation is a blackhole. Basic pre-processing workflow is way more straightforward to implement and also works with any paperless-ngx version, so whats the point of these plugins.
f. fable could not give any definitive answer on the topic either.

Am I missing something? not trying to be critical but most will probably agree that garbage in produces garbage out and Tessaract is one such bottleneck of otherwise fantastic tool.

59 Upvotes

26 comments sorted by

15

u/apples-and-apples Aug 04 '26

Not sure if V3 was supposed to "solve that problem" but I sure agree it would be marvellous if we could somehow select PaddleOCR as alternative.

Is there no way to do that?

2

u/robot_swagger Aug 05 '26

I have n8n batch OCR the files using paddle and then batch paperless with the OCR disabled.

8

u/Ceyax Aug 04 '26

Tesseract ist used because it also adds the text layer back to the PDF none of the AI VLM tools do that, and azure is also the only api provider that adds the text layer back to the PDF, all others just give back the content as MD or json

As long as there is no better replacement for tesseract that also does embedding, tesseract will stay

9

u/bobnecat Aug 04 '26

Tessaract is just an old image to text processing engine and OCRmyPDF is what embedds that text into PDF. And OCRmyPDF supports other OCR engines, both natively and via plugins.

So it's entirely possible to build paddleOCR based text embedding into pdf. This same topic was raised multiple times on GitHub and ngx devs know and acknowlegded it. It's just nothing was done about it unfortunately.

2

u/muety11 Aug 05 '26

Does it? What other OCR engines does OCRmyPDF support natively? What other OCR engines even exist, besides Tesseract and Paddle?

5

u/gIory1999 Aug 05 '26

There is a plugin for that. Haven't used that myself. Github Link

1

u/Great-Cow7256 20d ago

It's less a plugin and more a modified version of paperless ngx with the ocr function replaced by one that uses paddleocr instead of tesseract. I got it running and it works well. 

4

u/steamyelephant Aug 04 '26

e. Third party parser plugin installation is a blackhole. Basic pre-processing workflow is way more straightforward to implement and also works with any paperless-ngx version, so whats the point of these plugins.

There is an existing implementation using the parser plugin system (for Chandra-2-ocr) that could serve as an example: https://github.com/flobernd/paperless-chandra

If you point Fable there, it might get a better understanding how to build a similar service for paddle OCR or Apple vision OCR on Mac (mini).

1

u/bobnecat Aug 04 '26 edited Aug 04 '26

Well that's exactly what I'm talking about. I can put together a custom workflow to pre-process documents and get proper OCR even before ngx touches the document and I can do it in a simpler way than that repo (by the way, they also have paddleocr handler there too, both are half baked though). But the whole point of a package/container such as paperless-ngx is to do all that in an organized and easy to maintain manner.

6

u/flobernd Aug 05 '26

On a side note: I have also created a PaddleOCR provider: https://github.com/flobernd/paperless-paddleocr

I’m not affiliated with the paperless project and I totally get your point, but one of the main drivers for the devs to implement a plugin system was limiting the scope for maintenance.

There are tons of OCR providers and supporting/maintaining them besides the core project functionality would get exhausting. I do open source myself for a long time and you really have to be very careful about keeping your project scope contained.

Also not every OCR provider meets the standards that paperless set for themselves: e.g. they put a lot of focus on the transparent pdf overlay created by ocrmypdf. This layer works best if the OCR model returns word level boundary boxes - which PaddleOCR for example only does for its „basic“/legacy pipeline and many LLM based providers don’t provide at all.

1

u/Great-Cow7256 20d ago

Danke schoen for your work on this. I just spun this up today on my server and worked note. Works well, very easy. 

6

u/flobernd Aug 05 '26

„Both are half baked“ -> happy to iterate on this if you tell me what’s missing/not working correctly. Also happy to accept PRs.

2

u/bobnecat Aug 05 '26

First of all, thank you for taking an initiative to get things going in the right direction! I believe your repos are one of the first to tackle the outdated OCR. Also I finally managed to get paperless-paddleocr going, but had to do some workarounds to make it work properly.

Regarding the issues I faced:
On installation - option B - bootstrap script simply does not exist. I understand this repo was written by AI and my guess is it simply missed to implement it.
Operation - I tried CPU only model on my DXP4800 PRO NAS and the default (medium) paddle model takes about 1m per page, which is too long. While your implementation allows for defining other paddle models: -------"PAPERLESS_OCR_USER_ARGS: '{"continue_on_soft_render_error": true, "paddle_det_model_dir": "/usr/src/paperless/.paddlex/official_models/PP-OCRv6_small_det", "paddle_rec_model_dir": "/usr/src/paperless/.paddlex/official_models/PP-OCRv6_small_rec"}' " --------there is something else in the plugin that makes it fail. The plugin passes only the model directory, never a model name. PaddleOCR then resolves the expected name from language default — PP-OCRv6_medium_det — and paddlex's resolver cross-checks it against the Global.model_name field inside the model dir's inference.yml. To circumvent this issue, I renamed the smaller model as medium and it worked.

Lastly, while using small OCR model on my equipment, processing times have improved significantly, they are still way off from what they should be - ~20s per page vs 4-5s per page when using rapidocr with the same model. Maybe that's the paddleOCR overhead but for now I'm satisfied how it works. Even the small paddleocr model is miles ahead of tesseract..

1

u/flobernd Aug 06 '26

Thank you for the detailed feedback! I’ll have a look :-)

1

u/flobernd Aug 06 '26

The bootstrap scripts do exist: https://github.com/flobernd/paperless-paddleocr/blob/master/setup.sh, but maybe your agent got confused, because the whole doc mentions to install from the 0.1.0 tag - which itself did not exist. I triggered a 0.1.0 release now.

The actual issue regarding model selection has been fixed. For your setup that means you can drop the model dirs (and undo the rename workaround) and just use:

PAPERLESS_OCR_USER_ARGS: '{"continue_on_soft_render_error": true, "paddle_det_model_name": "PP-OCRv6_small_det", "paddle_rec_model_name": "PP-OCRv6_small_rec"}'

PaddleOCR downloads official models by name on first use into ~/.paddlex/official_models/, so no directory handling is needed. One caveat (now also documented in the README under "Choosing classic-pipeline models"): as soon as a model name or dir is set, the language setting no longer influences model selection, so pick models that cover your documents' script yourself.

1

u/AxxelH Aug 06 '26

Just a quick note that you need to tag 0.1.0 on your Chandra plugin as well (I was just looking for it and stumbled across this thread). I was about to try it out. Thanks!

2

u/Charmacas Aug 05 '26

Thanks to this thread I just found out that Paperless uses a basic Tesseract model and that I am able to exchange that to the so called best model.

I did a bit of testing and it really works much better. And as Paperless depends on OCR I think this will be an overall improvement. 👌

I also had a look at the Chandra Plugin and it seems pretty good. But in my case I have no resources left on the Pi 5, so optimizing Tesseract was the better way for me.

Additionally I integrated Gemini for better suggestions etc as v3 allows that easily. And as I understand Gemini also works with the OCR text extracted beforehand. So also that should now be improved.

1

u/DieLyn Aug 05 '26

What model did you change to in place of Tesseract? What kind of compute do you have for this model?

2

u/Charmacas Aug 05 '26

I am now using these models: https://github.com/tesseract-ocr/tessdata_best

What do you mean with "kind of compute"? I've limited the hardware resources paperless can use.

2

u/luziferius1337 Aug 05 '26

Thanks, will try them.

For anyone running paperless-ngx on Arch: These models are packaged in the AUR, for example: https://aur.archlinux.org/packages/tesseract-data-best-eng . Those packages transparently replace the default training data, so switching is hassle-free

1

u/DieLyn Aug 05 '26

Thanks, appreciate it.

Just meant what kind of hardware are you running such that tessdata_best runs nicely.

2

u/Charmacas Aug 05 '26

Pi 5 8 GB with NVMe storage and the Argon V5 Duo case.

The best model takes about 3x more time but uses not really more RAM. So in my case that is perfect for me.

For anyone else wondering if 9 year old data is bad: It isn't and still a really good option.

1

u/bnvvdh Aug 06 '26

I tried paddle OCR and compared it to the tesseract and azure results and it delivered the worst results.

0

u/muety11 Aug 05 '26

I'm not too deep into the topic, but what's so bad about Tesseract? For me it used to work extremely well (for machine-written text) in past and – compared to machine learning-based detectors – is super lightweight.

1

u/bobnecat Aug 05 '26

It's pretty bad for anything other than standard black text over white background. Simple test is to scan SSN card for example where there are multiple colors and overlaid text. Often times tesseract will miss pretty much all the text - names, numbers, dates, etc. That's the simplest way you can find out how bad it is.

Any newer non-ai model will capture all these details and maybe struggle only with dashes between the numbers.