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.
EasyOCR: Ready-to-use OCR with 40 languages
41–50 of 73 posts
Re: EasyOCR: Ready-to-use OCR with 40 languages
#42From 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…
Re: EasyOCR: Ready-to-use OCR with 40 languages
#43Does this require a Nvidia GPU? Some modules seem to import PyTorch and Cuda libs: https://github.com/JaidedAI/EasyOCR/blob/master/easyocr/dete...
Re: EasyOCR: Ready-to-use OCR with 40 languages
#44Looking 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.
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
#45What 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.
https://developer.apple.com/documentation/vision/recognizing...
Re: EasyOCR: Ready-to-use OCR with 40 languages
#46Does this require a Nvidia GPU? Some modules seem to import PyTorch and Cuda libs: https://github.com/JaidedAI/EasyOCR/blob/master/easyocr/dete...
Re: EasyOCR: Ready-to-use OCR with 40 languages
#47Earlier 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/…
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
#48From 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…
Re: EasyOCR: Ready-to-use OCR with 40 languages
#49From 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.
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
#50Earlier 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.
Yes, the simplified model is not that great at recognizing simplified either, at least in this case.