Live data from Hacker News

EasyOCR: Ready-to-use OCR with 40 languages

github.com

41–50 of 73 posts

Re: EasyOCR: Ready-to-use OCR with 40 languages

#41
post #24

Earlier quoted context omitted.

From my experience the algorithms & implementations seem to be pretty good but the caveat is that you the developer need to be aware of all the different approaches and when it is appropriate to apply them. There just doesn't seem to be a good general purpose library that stitches them all together and knows when to use which approach based analyzing the image.

I've found that often for tools related to natural language (ORC, text-to-speech, and speech-to-text) it feels like you need a PhD in the subject just to figure out how to anything done at all. I heartily welcome efforts to package these sort of things up in ready-to-use ways.

This is good news if you have one of these PhD's. Your career probably isn't going anywhere any time soon :)

Re: EasyOCR: Ready-to-use OCR with 40 languages

#42
post #13

From what I can tell (without having read the research papers) it looks like this is just an easy to use package for sparse scene text extraction. It seems to do okay if the scene has sparse text but it falls down for dense text detection. The results are going to be pretty bad if you try and do a task like "extract transactions from a picture of a receipt." Here's an example of input you might get for a production a…

Yes, you're right. I tried with some scanned pages from a Vietnamese book but the result was very bad (say <5% accurate). The scans was pretty OK, though. Probably the model was not trained much for the Vietnamese language but I think it's more likely that it does not do the necessary per-processing steps.

Re: EasyOCR: Ready-to-use OCR with 40 languages

#44
post #3

Looking at the Chinese example, it’s kinda funny it managed to output Traditional Chinese characters when the image contains Simplified Chinese; the SC and TC versions look pretty different (园 vs 園, 东 vs 東).

They're rendering Unicode without any markup for language variant.

No, these are completely different, standalone code points, not variant forms of the same code point.

What's actually happening seems to be that the ch_tra model can recognize simplified too and output the corresponding traditional version if the character isn't in the traditional "alphabet"; it doesn't work so well in the other direction.

Example recognizing a partial screenshot of https://chinese.stackexchange.com/a/38707 (anyone can try this on Google Colab, no hardware required; remember to turn on GPU in Runtime -> Change runtime type):

  import easyocr
  import requests

  zhs_reader = easyocr.Reader(['en', 'ch_sim'])
  zht_reader = easyocr.Reader(['en', 'ch_tra'])
  image = requests.get('https://i.imgur.com/HtrpZCZ.png').content
  print('ch_sim:', ' '.join(text for _, text, _ in zhs_reader.readtext(image)))
  print('ch_tra:', ' '.join(text for _, text, _ in zht_reader.readtext(image)))
Results:

  ch_sim: One simplified character may mapping to multiple traditional ones: 皇后->皇后,後夭->后夭 豌鬟->头发,骏财->发财 As reversed, one traditional character may mapping to multiple simplified ones too: 乾燥->干燥, 乾隆->乾隆 嘹望->嘹望,嘹解->了解
  ch_tra: One simplified character may mapping to multiple traditional ones: 皇后->皇后,後天->后天 頭髮->頭發,發財->發財 As reversed, one traditional character may mapping to multiple simplified ones too: 乾燥->干燥, 乾隆->乾隆 瞭望->瞭望, 瞭解->了解
Compare to the original text:

  One simplified character may mapping to multiple traditional ones:

  - 皇后 -> 皇后,後天 -> 后天
  - 頭髮 -> 头发,發財 -> 发财

  As reversed, one traditional character may mapping to multiple simplified ones too:

  - 乾燥 -> 干燥,乾隆 -> 乾隆
  - 瞭望 -> 瞭望,瞭解 -> 了解
Of course, automatic character-to-character conversion from simplified to traditional can be wrong due to ambiguities; excellent examples from above: 头发 => 頭發 (should be 頭髮), 了解 => 了解 (should be 瞭解).

Re: EasyOCR: Ready-to-use OCR with 40 languages

#45
post #38

What are people using in mobile development (native iOS/native Android/Cross-platform e.g. React-Native) when you want accurate extraction from a fixed format-source? E.g. poor-quality images of ID cards or credit cards, where the position of data is known.

iOS has the Vision framework, can’t say whether it’s accurate enough for your use case.

https://developer.apple.com/documentation/vision/recognizing...

Re: EasyOCR: Ready-to-use OCR with 40 languages

#46
post #14

Does this require a Nvidia GPU? Some modules seem to import PyTorch and Cuda libs: https://github.com/JaidedAI/EasyOCR/blob/master/easyocr/dete...

The CPU fallback taking on the order of tens of seconds on my modest i5-5250U for a few images of street signs I've thrown at it. Good enough for my purposes at least.

Re: EasyOCR: Ready-to-use OCR with 40 languages

#47
post #44

Earlier quoted context omitted.

They're rendering Unicode without any markup for language variant.

No, these are completely different, standalone code points, not variant forms of the same code point. What's actually happening seems to be that the ch_tra model can recognize simplified too and output the corresponding traditional version if the character isn't in the traditional "alphabet"; it doesn't work so well in the other direction. Example recognizing a partial screenshot of https://chinese.stackexchange.com/…

Funny thing, 夭 and 天 are not the same at all.

It doesn't seem to have a dictionary to do word level matching, only character level.

Re: EasyOCR: Ready-to-use OCR with 40 languages

#48
post #13

From what I can tell (without having read the research papers) it looks like this is just an easy to use package for sparse scene text extraction. It seems to do okay if the scene has sparse text but it falls down for dense text detection. The results are going to be pretty bad if you try and do a task like "extract transactions from a picture of a receipt." Here's an example of input you might get for a production a…

I've been very impressed with the OCR on an app called Fetch, which you use to scan your grocery receipts and get points you can use to redeem for gift cards. Even if I pull a receipt out of my pocket and it's wrinkly, it still seems to read it very well.

Re: EasyOCR: Ready-to-use OCR with 40 languages

#49
post #13

From what I can tell (without having read the research papers) it looks like this is just an easy to use package for sparse scene text extraction. It seems to do okay if the scene has sparse text but it falls down for dense text detection. The results are going to be pretty bad if you try and do a task like "extract transactions from a picture of a receipt." Here's an example of input you might get for a production a…

I've been very impressed with the OCR on an app called Fetch, which you use to scan your grocery receipts and get points you can use to redeem for gift cards. Even if I pull a receipt out of my pocket and it's wrinkly, it still seems to read it very well.

Can you get the data from them yourself, or is it purely for them?

I've just tried easyocr on a receipt, and it's pretty bad. I've also just noticed that ASDA have a "mojibake" problem and print ú instead of £ on the entire receipt ...

Re: EasyOCR: Ready-to-use OCR with 40 languages

#50
post #47
post #44

Earlier quoted context omitted.

No, these are completely different, standalone code points, not variant forms of the same code point. What's actually happening seems to be that the ch_tra model can recognize simplified too and output the corresponding traditional version if the character isn't in the traditional "alphabet"; it doesn't work so well in the other direction. Example recognizing a partial screenshot of https://chinese.stackexchange.com/…

Funny thing, 夭 and 天 are not the same at all. It doesn't seem to have a dictionary to do word level matching, only character level.

> Funny thing, 夭 and 天 are not the same at all.

Yes, the simplified model is not that great at recognizing simplified either, at least in this case.

Post reply on HN