Live data from Hacker News

Show HN: OCR Arena – A playground for OCR models

ocrarena.ai

41–50 of 65 posts

Re: Show HN: OCR Arena – A playground for OCR models

#41
post #29

I suggest you make explicit the assumption that this website is specifically about English text. Otherwise the leaderboard is pretty meaningless, with extreme differences in performance across other scripts - and potentially even languages such as Vietnamese or Czech which use Latin but have lots of accents.

Hey! I'm the dev who made this:) I think that you are right, data will bias towards english because we have a dataset that people can use that is in english. But you can also upload non-english docs into the battle mode as well as the playground!

LMArena splits their leaderboard by language: maybe you should consider doing the same thing

I assume to do that you’d need another model to do language detection on the inputs and/or outputs; but a language detection model can be a lot cheaper than an OCR model or an LLM

Re: Show HN: OCR Arena – A playground for OCR models

#42

I've been really impressed with this model specifically because of how insanely cheap it is: https://replicate.com/ibm-granite/granite-vision-3.3-2b I didn't expect IBM to be making relevant AI models but this thing is priced at $1 per 4,000,000 output tokens... I'm using it to transcribe handwritten input text and it works very well and super fast.

English only :( . it seems only 2 orders of magnitude larger models have support for ie greek :/

Re: Show HN: OCR Arena – A playground for OCR models

#43
Offtopic, but what's the best OCR that can run offline on browsers with js/wasm with reasonable CPU/memory cost?

Working on a hobby project that interacts with user handwriting on . Tried some CNN models for digits but had trouble with characters.

Re: Show HN: OCR Arena – A playground for OCR models

#44
post #29

I suggest you make explicit the assumption that this website is specifically about English text. Otherwise the leaderboard is pretty meaningless, with extreme differences in performance across other scripts - and potentially even languages such as Vietnamese or Czech which use Latin but have lots of accents.

That's unfortunate because I have a bunch of photos with handwritten German on the back that I need to transcribe, and seeing as that I can't read German I can't really do it by myself either.

I reckon performance on German will be similar to English, the only real difference is the umlauts and those are very consistent. Not sure how it will do on the ß.

Re: Show HN: OCR Arena – A playground for OCR models

#45
post #29

I suggest you make explicit the assumption that this website is specifically about English text. Otherwise the leaderboard is pretty meaningless, with extreme differences in performance across other scripts - and potentially even languages such as Vietnamese or Czech which use Latin but have lots of accents.

That's unfortunate because I have a bunch of photos with handwritten German on the back that I need to transcribe, and seeing as that I can't read German I can't really do it by myself either.

qwen 3.5 vl instruct on openrouter is damn cheap - and works quite well with non english stuff.

i have it verify some stamps which are quite messy and sometimes obscured and honestly some i could not even read.

Re: Show HN: OCR Arena – A playground for OCR models

#47
post #43

Offtopic, but what's the best OCR that can run offline on browsers with js/wasm with reasonable CPU/memory cost? Working on a hobby project that interacts with user handwriting on . Tried some CNN models for digits but had trouble with characters.

If the text is written interactively on the canvas (as opposed to extraction from pixels) this task is known as "online handwriting recognition" ("online" because you can watch the text being formed incrementally, which makes it easier to e.g. distinguish individual strokes.)

I don't know what the state of the art is, but an old model for digitizer pens might not do so bad either.

Re: Show HN: OCR Arena – A playground for OCR models

#50
What is needed to evaluate OCR for most business applications (above everything else) is accuracy.

Some results look plausible but are just plain wrong. That is worse than useless.

Example: the "Table" sample document contains chemical substances and their properties. How many numbers did the LLM output and associate correctly? That is all that matters. There is no "preference" aspect that is relevant until the data is correct. Nicely formatted incorrect data is still incorrect.

I reviewed the output from Qwen3-VL-8B on this document. It mixes up the rows, resulting in many values associated with the wrong substance. I presume using its output for any real purpose would be incredibly dangerous. This model should not be used for such a purpose. There is no winning aspect to it. Does another model produce worse results? Then both models should be avoided at all costs.

Are there models available that are accurate enough for this purpose? I don't know. It is very time consuming to evaluate. This particular table seems pretty legible. A real production grade OCR solution should probably need a 100% score on this example before it can be adopted. The output of such a table is not something humans are good at reviewing. It is difficult to spot errors. It either needs to be entirely correct, or the OCR has failed completely.

I am confident we'll reach a point where a mix of traditional OCR and LLM models can produce correct and usable output. I would welcome a benchmark where (objective) correctness is rated separately from of the (subjective) output structure.

Edit: Just checked a few other models for errors on this example.

* GPT 5.1 is confused by the column labelled "C4" and mismatches the last 4 columns entirely. And almost all of the numbers in the last column are wrong.

* olmOCR 2 omits the single value in column "C4" from the table.

* Gemini 3 produces "1.001E-04" instead of "1.001E-11" as viscosity at T_max for Argon. Off by 7 orders of magnitude! There is zero ambiguity in the original table. On the second try it got it right. Which is interesting! I want to see this in a benchmark!

There might be more errors! I don't know, I'd like to see them!

Post reply on HN