Open krzysiekj94 opened 2 years ago
Are you using the same traineddata file with 4.1.1?
Are you using the same traineddata file with 4.1.1?
Hello @Shreeshrii,
exactly the same. If that helps, here's my tessdata folder.
1). Today I started doing tests combined with another language - ie. "pol+eng", "pol+deu". Surprisingly, for this case, the '@' sign started to be properly recognized in the first example. See below:
2). However, not always strings with '@' are correctly recognized for 'pol+eng', especially if they are smaller -> example below.
File:
Result for only 'pol' language:
Result for 'pol+eng' languages:
Result for 'pol+deu' languages:
Here, 'pol' + 'deu' is doing best here, but the problem is that some Polish letters, ie "ó", are recognized as German "ö", so I would have to think about another solution. Do you have any ideas what could be done to make the special characters correctly recognized?
Hello @krzysiekj94. You could try the Latin model. At first glance it seems to produce good results, but maybe you need to finetune some character to get proper results for all polish character.
Hello @JKamlah,
Thanx for your reply.
1). in the case Latin I found some mistakes by ocr process with PL letters - model "pl+Latin". Sometimes engine returns "t" instead of "ł".
2). in the case combined pl and eng model I found less mistakes by ocr process with PL letters - model "pl+eng". There are no problems with PL characters here, but latin is better at dealing with email addresses. Next problem is that "pl+latin" is slower than "pl+eng". For example, for a 30 page tiff, OCR time for Latin takes about 3 minutes, while for "pl + eng" 2 times less. I think here the "pl + eng" model wins a bit.
Do you have any other ideas what I could try?
You could try: Finetuning This technique will work best if you want to work with a small set of font types and fix glyph ranges, which you want to detect properly. So it depends on your task.
To find the best workflow, you could use some tooling to get proper values and more insights:
You could try: Finetuning This technique will work best if you want to work with a small set of font types and fix glyph ranges, which you want to detect properly. So it depends on your task.
1. Use "latin" model only and not "pl+latin" (it seems you work with mixed languages all based on latin script?) 2. Extend the dictionary with polish words (or just get rid of the existing one). If you have some fix keywords, add these to the dict(!). -> use [combine_tessdata](https://digi.bib.uni-mannheim.de/tesseract/manuals/combine_tessdata.1.html) to (un-)pack the model and [dawg2wordlist](https://digi.bib.uni-mannheim.de/tesseract/manuals/dawg2wordlist.1.html)/ [wordlist2dawg](https://digi.bib.uni-mannheim.de/tesseract/manuals/wordlist2dawg.1.html) to convert dawg to wordlist and vice versa. The wordlist can be edit with a simple texteditor. 3. Find the characters which get most often confused ("t" instead of "ł" etc. ) 4. Generate artificial or transcribe some ground truth and finetune the latin model Or find [some polish GT](http://dl.psnc.pl/activities/projekty/impact/results/).. 5. Finetune the latin model (you can only train best-models) with [tesstrain](https://github.com/tesseract-ocr/tesstrain) -> You can find some examples in the [tesstrain-wiki](https://github.com/tesseract-ocr/tesstrain/wiki)
To find the best workflow, you could use some tooling to get proper values and more insights:
1. Generate a ground truth set for validation 2. Evaluate the OCR result with [ocreval](https://github.com/eddieantonio/ocreval)
Thanx for your suggestions. I will try it.
Environment
Current Behavior:
I have the following problem..
Expected Behavior:
I expect special characters such as '@' to be recognized regardless of the language selected (especially for pol version, but maybe for another langugage problem still exist). For example in german version problem isn't reproducible.
Suggested Fix:
Is there any workaround to this behavior? If this is not the correct place, please give me info, but on the other hand, if something worked in 4.1.1 and now doesn't work, it should be treated as a bug.