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

DeepSeek OCR

github.com

Post reply on HN
Print view View original

131–140 of 252 posts

Re: DeepSeek OCR

#131

Post by simlevesque »

pietz wrote: post #42

My impression is that OCR is basically solved at this point. The OmniAI benchmark that's also referenced here wasn't updated with new models since February 2025. I assume that's because general purpose LLMs have gotten better at OCR than their own OCR product. I've been able to solve a broad range of OCR tasks by simply sending each page as an image to Gemini 2.5 Flash Lite and asking it nicely to extract the content…

> That will cost you around $0.20 for 1000 pages in batch mode and the results have been great.

Can you explain more about your setup ? I have a quarter million pages I want to OCR.

Re: DeepSeek OCR

#132

Post by kmacdough »

CaptainOfCoit wrote: post #71
cahaya wrote: post #60

Earlier quoted context omitted.

Lot's of OCR/ LLM's (Even Gemini Pro 2.5) still struggle converting complex tables to markdown or HTML: Tables with multiple headers and merged cells that get mixed up, multiple columns with tick boxes get mixed up, multi page tables that are not understood correctly. Also Llamaindex fails miserably on those things. Curious to hear which OCR/ LLM excels with these specific issues? Example complex table: https://cdn.a…

> Lot's of OCR/ LLM's (Even Gemini Pro 2.5) still struggle converting complex tables to markdown or HTML: But that's something else, that's no longer just OCR ("Optical Character Recognition"). If the goal suddenly changes from "Can take letters in images and make into digital text" to "Can replicate anything seen on a screen", the problem-space gets too big. For those images you have, I'd use something like Magistra…

> But that's something else, that's no longer just OCR ("Optical Character Recognition").

Lines often blur for technologies under such rapid evolution. Not sure it's helpful to nitpick the verbal semantics.

It is a fair question whether the OCR-inspired approach is the correct approach for more complex structured documents where wider context may be important. But saying it's "not OCR" doesn't seem meaningful from a technical perspective. It's an extension of the same goal to convert images of documents into the most accurate and useful digitized form with the least manual intervention.

Re: DeepSeek OCR

#133

Post by fluoridation »

numpad0 wrote: post #76
yoran wrote: post #19

How does an LLM approach to OCR compare to say Azure AI Document Intelligence ( https://learn.microsoft.com/en-us/azure/ai-services/document... ) or Google's Vision API ( https://cloud.google.com/vision?hl=en )?

Classical OCR still probably make undesirable su6stıtutìons in CJK from there being far too many of similar ones, even some absurd ones that are only distinguishable under microscope or by looking at binary representations. LLMs are better constrained to valid sequences of characters, and so they would be more accurate. Or at least that kind of thing would motivate them to re-implement OCR with LLM.

Huh... Would it work to have some kind of error checking model that corrected common OCR errors? That seems like it should be relatively easy.

Re: DeepSeek OCR

#134

Post by thekid314 »

wahnfrieden wrote: post #121
hakunin wrote: post #116

Earlier quoted context omitted.

Wish someone benchmarked Apple Vision Framework against these others. It's built into most Apple devices, but people don't know you can actually harness it to do fast, good quality OCR for you (and go a few extra steps to produce searchable pdfs, which is my typical use case). I'm very curious where it would fall in the benchmarks.

It is unusable trash for languages with any vertical writing such as Japanese. It simply doesn’t work.

Yeah, and fails quickly at anything handwritten.

Re: DeepSeek OCR

#135

Post by utopiah »

foofoo12 wrote: post #103

How does it compare to Tesseract? https://github.com/tesseract-ocr/tesseract I use ocrmypdf (which uses Tesseract). Runs locally and is absolutely fantastic. https://ocrmypdf.readthedocs.io/en/latest/

Indeed, seems the default benchmark is LLM/VLM based alternatives as if they somehow "solved" the problem but IMHO even if it goes from (totally made up numbers) 80% with tesseract to 95% with this or Qwen or whatever but it takes 100x harddisk with containers or a CUDA stack, dedicated hardware, e.g. GPU with 16GB or VRAM, etc then it's such a trade of it should be considered.

Re: DeepSeek OCR

#136

Post by daemonologist »

yoran wrote: post #19

How does an LLM approach to OCR compare to say Azure AI Document Intelligence ( https://learn.microsoft.com/en-us/azure/ai-services/document... ) or Google's Vision API ( https://cloud.google.com/vision?hl=en )?

My base expectation is that the proprietary OCR models will continue to win on real-world documents, and my guess is that this is because they have access to a lot of good private training data. These public models are trained on arxiv and e-books and stuff, which doesn't necessarily translate to typical business documents.

As mentioned though, the LLMs are usually better at avoiding character substitutions, but worse at consistency across the entire page. (Just like a non-OCR LLM, they can and will go completely off the rails.)

Re: DeepSeek OCR

#137

Post by CaptainOfCoit »

kmacdough wrote: post #132
CaptainOfCoit wrote: post #71

Earlier quoted context omitted.

> Lot's of OCR/ LLM's (Even Gemini Pro 2.5) still struggle converting complex tables to markdown or HTML: But that's something else, that's no longer just OCR ("Optical Character Recognition"). If the goal suddenly changes from "Can take letters in images and make into digital text" to "Can replicate anything seen on a screen", the problem-space gets too big. For those images you have, I'd use something like Magistra…

> But that's something else, that's no longer just OCR ("Optical Character Recognition"). Lines often blur for technologies under such rapid evolution. Not sure it's helpful to nitpick the verbal semantics. It is a fair question whether the OCR-inspired approach is the correct approach for more complex structured documents where wider context may be important. But saying it's "not OCR" doesn't seem meaningful from a…

Personally I think it's a meaningful distinction between "Can extract text" VS "Can extract text and structure". It is true that some OCR systems can handle trying to replicate the structure, but still today I think that's the exception, not the norm.

Not to mention it's helpful to separate the two because there is such a big difference in the difficulty of the tasks.

Re: DeepSeek OCR

#138

Post by _vqpz »

JohnLocke4 wrote: post #105
_vqpz wrote: post #93

Earlier quoted context omitted.

Why do they need to grant access for people to use copies of books they don’t own?

Not to rationalize it, but it appears that they're gatekeeping the dataset to get access to the OCR-scans from the people they choose to share it with. This is to improve their existing service by making the content of books (and not just their title/tags) searchable. As per the blog post: >What does Anna’s Archive get out of it? Full-text search of the books for its users.

Fair enough, it just seems like they're painting an even bigger target on their backs by restricting access to copyrighted material they don't own the rights to

Re: DeepSeek OCR

#139

Post by daemonologist »

pietz wrote: post #65
coulix wrote: post #46

Earlier quoted context omitted.

This. Any complex parent table span cell relationship still has low accuracy. Try the reverse, take a complex picture table and ask Chatgpt5, claude Opus 3.1, Gemini Pro 2.5 to produce a HTML table. They will fail.

Maybe my imagination is limited or our documents aren't complex enough, but are we talking about realistic written documents? I'm sure you can take a screenshot of a very complex spreadsheet and it fails, but in that case you already have the data in structured form anyway, no?

Now if someone mails or faxes you that spreadsheet? You're screwed.

Spreadsheets are not the biggest problem though, as they have a reliable 2-dimensional grid - at worst some cells will be combined. The form layouts and n-dimensional table structures you can find on medical and insurance documents are truly unhinged. I've seen documents that I struggled to interpret.

Re: DeepSeek OCR

#140

Post by modeless »

Hmm, at first I was thinking "why OCR?", but maybe the reason is to ingest more types of training data for LLM improvement, e.g. scanned academic papers? I imagine all the frontier labs have a solution for this due to the value of academic papers as a data source.

Edit: Oh I see the paper abstract says this explicitly: "In production, DeepSeek-OCR can generate training data for LLMs/VLMs at a scale of 200k+ pages per day (a single A100-40G)". This is just part of the training data ingestion pipeline for their real models. Explains why the architecture is not using all of their latest tricks: it's already good enough for their use case and it's not the main focus.

Post reply on HN