Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

github.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#21

Post by Jimmc414 »

sixtyj wrote: post #17
kspacewalk2 wrote: post #16

Earlier quoted context omitted.

Let me fire up Claude code.

Let me fire up Tesseract. https://github.com/tesseract-ocr

I fought with Tesseract for quite a while. Its good if high accuracy doesn't matter. Transcribing a book from clean, consistent non-skewed data its fine and an LLM might even be able to clean it up. But for legal or accounting data from hand scanned documents, the error rate made it untenable. Even clean, scanned documents of the same category have all sorts of density and skew anomalies that get misinterpreted. You'll pull your hair out trying to account for edge cases and never get the results you need even with numerous adjustments and model retraining on errors.

Flash 2.5 or 3 with thinking gave the best results.

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#22

Post by tuwtuwtuwtuw »

M4R5H4LL wrote: post #19
sync wrote: post #12

This 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.

Sure. The self host guide tells me to enter my github secret, in plain-text, in an env file. But it doesn't tell me why I should do that.

Do people actually store their secrets in plain text on the file system in production environments? Just seems a bit wild to me.

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#23

Post by binalpatel »

This is admittedly dated but even back in December 2023 GPT-4 with it's Vision preview was able to very reliably do structured extraction, and I'd imagine Gemini 3 Flash is much better than back then.

https://binal.pub/2023/12/structured-ocr-with-gpt-vision/

Back of the napkin math (which I could be messing up completely) but I think you could process a 100 page PDF for ~$0.50 or less using Gemini 3 Flash?

>560 input tokens per page * 100 pages = 56000 tokens = $0.028 input ($0.5/m input tokens) >~1000 output tokens per page * 100 pages = $0.30 output ($3/m output tokens)

(https://ai.google.dev/gemini-api/docs/gemini-3#media_resolut...)

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#24

Post by adammajcher »

binalpatel wrote: post #23

This is admittedly dated but even back in December 2023 GPT-4 with it's Vision preview was able to very reliably do structured extraction, and I'd imagine Gemini 3 Flash is much better than back then. https://binal.pub/2023/12/structured-ocr-with-gpt-vision/ Back of the napkin math (which I could be messing up completely) but I think you could process a 100 page PDF for ~$0.50 or less using Gemini 3 Flash? >560 input…

sure, in some small projects I recommend my friends to use gemini 3 flash. ocrbase is aimed more at scale and self-hosting: fixed infra cost, high throughput, and no data leaving your environment. at large volumes, that tradeoff starts to matter more than per-100-page pricing

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#25

Post by adammajcher »

tuwtuwtuwtuw wrote: post #22
M4R5H4LL wrote: post #19

Earlier quoted context omitted.

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.

Sure. The self host guide tells me to enter my github secret, in plain-text, in an env file. But it doesn't tell me why I should do that. Do people actually store their secrets in plain text on the file system in production environments? Just seems a bit wild to me.

well, you can use secrets manager as well

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#28

Post by sixtyj »

Jimmc414 wrote: post #21
sixtyj wrote: post #17

Earlier quoted context omitted.

Let me fire up Tesseract. https://github.com/tesseract-ocr

I fought with Tesseract for quite a while. Its good if high accuracy doesn't matter. Transcribing a book from clean, consistent non-skewed data its fine and an LLM might even be able to clean it up. But for legal or accounting data from hand scanned documents, the error rate made it untenable. Even clean, scanned documents of the same category have all sorts of density and skew anomalies that get misinterpreted. You'…

Thanks. I was surprised that Tesseract had recognized poorly scanned magazines and with some Python library I was able to transcribe two-columns layout with almost no errors.

Tesseract is a cheap solution as it doesn’t touch any LLM.

For invoices, Gemini flash is really good, for sure, and you receive “sorted” data as well. So definitely thumbs up. I use it for transcription of difficult magazine layout.

I think that for such legally problematic usage as companies don’t like to share financial data with Google, it is be better to use a local model.

Ollama or HuggingFace has a lot of them.

Re: Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

#29

Post by cess11 »

adammajcher wrote: post #27
cess11 wrote: post #20

Why 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.

fixed

OK, thanks, so it runs on a couple GB of CUDA?
Post reply on HN