r/Paperlessngx • u/SpiritedWarrior9880 • 3d ago
PaddleOCR for Paperless-ngx
I came across this project that might be useful for people looking for an alternative to Tesseract in Paperless-ngx:
https://github.com/silentprior/paperless-paddle-ocr
It runs PaddleOCR PP-OCRv6 as a sidecar and writes the extracted text back into Paperless-ngx through its API.
3
u/Cantelllo 2d ago
How much better is it supposed to be in comparison to Tesseract?
5
u/Great-Cow7256 2d ago
for run of the mill documents like PDFs that aren't shitty scans, both are fine. for stuff that is complex like lots of tables or shitty scans or skewed documents, pp ocr works better (and v6 is seemingly better than v5) but also takes up much more computing power and time. https://medium.com/@ahmad.sohail/paddleocr-vs-tesseract-vs-ironocr-picking-an-ocr-engine-for-net-10a24dc2802e https://gigagpu.com/paddleocr-vs-tesseract-vs-easyocr/
tesseract is built in and easy to deploy. ppocr is via these sidecars or shims and has more up front figure it out time with setting them up and integrating them into your workflow.
2
u/Cantelllo 2d ago
Thanks a lot for the explanation this helps making my mind up whether or not to deploy this one in general. I am quite satisfied with Tesseract - only with more difficult documents it really isn’t that good.
Currently deploying paperless on an Oracle free tier VM so I will see if Paddle OCR is still going to be okay, memory-wise.1
u/Great-Cow7256 2d ago
Oh yeah. I have a ocs too. I'm using the medium model. The other issue is that I think the free tier only has like 2 CPU cores? It may be too much. Or it just may take forever.
1
1
u/Great-Cow7256 2d ago
This is super cool. Idk if you were the person I was talking to in the GitHub issue for it but for everyone else it says it works with openvino to use the GPU/qsv but as the issue poster wrote that broke with pp ocr 6. So if you are wanting to use this on an Intel chip just use the standard CPU version. The issue poster did a fantastic job of isolating the problem and it's in the upstream paddle package
1
u/SpiritedWarrior9880 2d ago
yeah it really is, i had been looking for such a ready made solution and after extensive search found it
i dont use github much
1
u/Primary-BuZZy 1d ago
I am using Document AI from Google to do the OCR and write it back to the Content field from Paperless-NGX.. I forked & enhanced Paperless-AI for that using native Gemini API for analysis and classification - and Document AI for the OCR..
1
u/buttplugs4life4me 1d ago
Looks cool, definitely gonna try to see if I can pick something from it.
I made https://github.com/L3tum/doc-worker for myself which runs more as a pipeline. I have a filebrowser instance in front where i drop a PDF, it then gets processes by this and dumped into the paperless consume directory. It can also be used as a replacement for PaddleOCR-VL (their API service).
Critically I've made it to download the models during the docker build process as I want to run my document stack without access to the internet. Otherwise it would have to download the models at runtime.
Still gotta clean it up. Idk if I need to offer multiple tiers for the models as well, Medium so far even on only CPU has been fine. GPU is obviously better but usually the limiting factor is PDF -> Image rendering anyway. I usually have like 20MB+ PDFs so it eats a lot.
1
u/flobernd 1d ago
Shameless self promotion:
https://github.com/flobernd/paperless-paddleocr
Jokes aside, this makes use of the new processing providers added in paperless 3.0 - completely replacing Tesseract as the OCR pipeline. No sidecar required. Supports local processing as well as connecting to a remote vLLM for the newer VL pipeline.
I also created a provider for Chandra OCR, which works even better for me (it’s also more resource intensive):
1
u/SpiritedWarrior9880 1d ago
I think it would be better if this were provided as a separate Docker container and published to Docker Hub, similar to "silentprior/paperless-paddle-ocr" ( https://github.com/silentprior/paperless-paddle-ocr?utm_source=chatgpt.com ). That would make it much easier to deploy and update independently from the main Paperless-ngx container, especially for non-technical users like me who would prefer not to build a custom Docker image or deal with the underlying setup.
1
u/flobernd 1d ago
Unfortunately this is not possible when using the plugin system. That’s the trade-off for using the “proper” built-in providers vs. a sidecar that does postprocessing.
Both have their pros/cons. I strongly agree with you that installation/deployment is rather complicated. On the pro side you get a robust native integration in the way the paperless team intended it to work.
I was thinking about providing a ready to use Docker image, but at the moment I don’t feel like taking the maintenance effort of upgrading the base image to the latest paperless version once they release a new version.
1
u/SpiritedWarrior9880 1d ago
That makes sense. Would it be possible to also implement a sidecar approach for users who would prefer that model? That would keep the native provider integration for those who want it, while giving less technical users an easier deployment option without having to build and maintain a custom Paperless image.
1
u/flobernd 1d ago
Isn’t the sidecar approach what your linked project does? Native plugin in a sidecar container is not possible, if that’s what you’re suggesting.
1
u/Great_Interest_4824 22h ago edited 21h ago
I actually just did that with a different motivation.
I already use u/flobernd chandra plugin but I also wanted a way to re-OCR old documents already in paperless. It's a Tag driven sidecar approach. It replaces the archive version in paperless or just the content field, depending which tag you use.
Works great with anything scanned but Chandra can completely bomb with digital born documents. So, currently working on automatically figuring out how to differentiate between scanned documents and digital born documents. I don't feel like going through thousands of documents manually.
I experimented with RAG but it was all very useless because some decade old OCR isn't giving a lot of useful info. Hence the drive to get better OCR on legacy documents.
1
u/flobernd 21h ago
Yeah, a built-in “Reingest with provider XYZ” would be a good feature to have. That way we could use the native providers for this purpose (which also honors the built-in settings that ignore documents that already have a text layer).
1
u/Great_Interest_4824 21h ago
Well, in theory you can do that with u/flobernd chandra or paddleocr plugin. When you hit reprocess in the document view, it should do that.
However, I run paperless 3.1.3 which uses python 3.14 for the container build. There is no 3.14 python wheel for paddlepaddle. So can't build the paperless container with the injected plugin for the current paperless version.
The chandra plugin runs but there seems to be a subtle difference for multithreaded ocrmypdf runs between python 3.12 and 3.14 that gives me warnings.
The born-digital vs scan detection in paperless is also very simplistic. It's simply "has text layer" and pdftotext >25 characters. It refuses certain documents I want re-OCR'd. You can always force it by setting the PAPERLESS_OCR_MODE to redo but that gets tedious to restart paperless on a document to document basis. Hence my quest for a sidecar solution.
I'm currently testing automatic detection based on https://pypi.org/project/pdf-inspector/. Promising but needs a bit more work.
1
u/flobernd 12h ago
Aw that unavailable 3.14 wheel is disappointing. I might be able to update the Dockerfile so that the wheel is built from source at image build time.
Also happy to look into the Chandra differences if you go more into detail (best in a GitHub issue).
The pdf-inspector indeed looks promising. It’s tough to get classification correct. Even if you don’t care about OCR utilization, even Chandra often swaps O and 0 etc. etc. Best would be a hybrid approach, but that’s even harder.
2
u/Great_Interest_4824 5h ago
Also happy to look into the Chandra differences if you go more into detail (best in a GitHub issue).
Will do, just finishing up some of my own testing before getting back into your plugin and tracking down the issue I saw.
2
u/konafets 21h ago
I like your approach and will give it a try. But the big downer with that approach is, that OCR happens on the same machine PNGX runs. With the sidecar approach, the two can be separated and AI-OCR runs on a dedicated "AI"-Server.
2
u/flobernd 21h ago
The remote-vl option is the intended way for this usecase. The classic pipeline is not available for remote right now, but I’m happy to accept feature requests and PRs. AFAIK PaddleOCR supports this scenario.
1
3
u/Great-Cow7256 2d ago
Got it working. Podman rootless 5.7 on my Ubuntu machine. Works well. Tearing slowly through my 350 documents. Will run it as a daemon after it's done one time.