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

121–130 of 252 posts

Re: DeepSeek OCR

#121

Post by wahnfrieden »

hakunin wrote: post #116
breadislove wrote: post #98

For everyone wondering how good this and other benchmarks are: - the OmniAI benchmark is bad - Instead check OmniDocBench[1] out - Mistral OCR is far far behind most Open Source OCR models and even further behind then Gemini - End to End OCR is still extremely tricky - composed pipelines work better (layout detection -> reading order -> OCR every element) - complex table parsing is still extremely difficult [1]: http…

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.

Re: DeepSeek OCR

#122

Post by CaptainOfCoit »

hakunin wrote: post #116
breadislove wrote: post #98

For everyone wondering how good this and other benchmarks are: - the OmniAI benchmark is bad - Instead check OmniDocBench[1] out - Mistral OCR is far far behind most Open Source OCR models and even further behind then Gemini - End to End OCR is still extremely tricky - composed pipelines work better (layout detection -> reading order -> OCR every element) - complex table parsing is still extremely difficult [1]: http…

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.

Yeah, if it was cross-platform maybe more people would be curious about it, but something that can only run on ~10% of the hardware people have doesn't make it very attractive to even begin to spend time on Apple-exclusive stuff.

Re: DeepSeek OCR

#123

Post by wahnfrieden »

jakewins wrote: post #54
raincole wrote: post #47

Earlier quoted context omitted.

If you can accept that the machine just make up what it doesn't recognize instead of saying "I don't know," then yes it's solved. (I'm not being snarky. It's acceptable in some cases.)

But this was very much the case with existing OCR software as well? I guess the LLMs will end up making up plausible looking text instead of text riddled with errors, which makes it much harder to catch the mistakes, in fairness

Existing ocr doesn’t skip over entire (legible) paragraphs or hallucinate entire sentences

Re: DeepSeek OCR

#124

Post by wahnfrieden »

raincole wrote: post #47
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…

If you can accept that the machine just make up what it doesn't recognize instead of saying "I don't know," then yes it's solved. (I'm not being snarky. It's acceptable in some cases.)

Do any LLM OCRs give bounding boxes anyway? Per character and per block.

Re: DeepSeek OCR

#125

Post by hank2000 »

Have yall seen tensorlake? I’m curious how this compares to a model custom built for the problem. My guess is it can be as good. But can it be as efficient?

disclaimer: I do not work for tensorlake—but i know the folks behind it.

Re: DeepSeek OCR

#126

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. But saying it's "not OCR" do doesn't seem meaningful from a technical perspective.

Re: DeepSeek OCR

#128

Post by Davidzheng »

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…

I think it'll be good to have an end-to-end pdf to latex converter for old math papers. For commutative diagrams almost all models still struggle. especially very complicated commutative diagrams.

Re: DeepSeek OCR

#129

Post by Davidzheng »

wahnfrieden wrote: post #123
jakewins wrote: post #54

Earlier quoted context omitted.

But this was very much the case with existing OCR software as well? I guess the LLMs will end up making up plausible looking text instead of text riddled with errors, which makes it much harder to catch the mistakes, in fairness

Existing ocr doesn’t skip over entire (legible) paragraphs or hallucinate entire sentences

rarely happens to me using LLMs to transcribe pdfs

Re: DeepSeek OCR

#130

Post by hank2000 »

jdthedisciple wrote: post #108
numpad0 wrote: post #75

Earlier quoted context omitted.

a) 后天下之乐而乐 b) 後天下之樂而樂 c) 後天下之楽而楽 a) is clearly Simplified Chinese from a sibling comment, b) is Traditional copied from your comment, and c) is as I just typed in my own language. Unicode Hanzi/Kanji are a mess and there are characters same or different, in appearance or in binary, depending on intended variants, languages, fonts, systems, keyboard, distance between Earth and Alpha Centauri, etc.

Fascinating! That's exactly why I asked, so thank you. Do people usually recognize all variants as valid and legible? Or does any particular set of letters/symbols prevail in practice?

Very location dependent. But when you learn to write the characters you understand the variants differently. They look like random strokes to an untrained eye. But they’re not. I’m not sure if that makes sense.

Take a lowercase a in English for example. This font writes it differently than a child. Or in cursive. Or probably than you would write it. But you recognize all of them and don’t really think about it.

Post reply on HN