How does this compare to dots.ocr? I got fantastic results when I tested dots. https://github.com/rednote-hilab/dots.ocr
Ocrbase is CUDA only while dots.ocr uses vLLM, so should support ROCm/AMD cards?
How about CPU?
Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
11–20 of 37 posts
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#12This is essentially a (vibe-coded?) wrapper around PaddleOCR: https://github.com/PaddlePaddle/PaddleOCR
The "guts" are here: https://github.com/majcheradam/ocrbase/blob/7706ef79493c47e8...
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#13What matters most is how well OCR and structured data extraction tools handle documents with high variation at production scale. In real workflows like accounting, every invoice, purchase order, or contract can look different. The extraction system must still work reliably across these variations with minimal ongoing tweaks.
Equally important is how easily you can build a human-in-the-loop review layer on top of the tool. This is needed not only to improve accuracy, but also for compliance—especially in regulated industries like insurance.
Other tools in this space:
LLMWhisperer/Unstract(AGPL)
Reducto
Extend Ai
LLamaparse
Docling
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#14This is essentially a (vibe-coded?) wrapper around PaddleOCR: https://github.com/PaddlePaddle/PaddleOCR The "guts" are here: https://github.com/majcheradam/ocrbase/blob/7706ef79493c47e8...
Claude is included in the contributors, so the OP didn’t hide it
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#15This is essentially a (vibe-coded?) wrapper around PaddleOCR: https://github.com/PaddlePaddle/PaddleOCR The "guts" are here: https://github.com/majcheradam/ocrbase/blob/7706ef79493c47e8...
At this point it feels like HN is becoming more like Reddit, most people upvote before actually checking the repo.
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#16Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#17Earlier quoted context omitted.
Sounds like someone needs to run their own test cases and report back on which solution does a better job...
Let me fire up Claude code.
Let me fire up Tesseract.
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#18I have a flow where i extract text from a pdf with pdf-parse and then feed that to an ai for data extraction. If that fails i convert it to a png and send the image for data extraction. This works very well and would presumably be far cheaper as i'm generally sending text to the model instead of relying on images. Isn't just sending the images for ocr significantly more expensive?
I have seen this flow in what people in some startups call "Agentic OCR", its essentially a control flow that is coded that tries pdf-parse first or a similar non expensive approach, and if it fails a threshold then use screenshot to text extraction.
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#19This is essentially a (vibe-coded?) wrapper around PaddleOCR: https://github.com/PaddlePaddle/PaddleOCR The "guts" are here: https://github.com/majcheradam/ocrbase/blob/7706ef79493c47e8...
Most production software is wrappers around existing libraries. The relevant question is whether this wrapper adds operational or usability value, not whether it reimplements OCR. If there are architectural or reliability concerns, it’d be more useful to call those out directly.
Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API
#20Why is 12GB+ VRAM a requirement? The OCR model looks kind of small, https://huggingface.co/PaddlePaddle/PaddleOCR-VL/tree/main, so I'm assuming it is some processing afterwards it would be used for.