OCR optimization

[udnp]

I've worked on OCR optimization for GoIV_JP(as known as unofficial GoIV for Japanese),
because it needed not only to be replaced with OCR trained data for Japanese, but also to be improved OCR accuracy and performance, like following.

Left: GoIV_JP v0.0.8 v.s. Right: v0.0.7

Now I'm trying to optimize official GoIV, with same ways I had done for GoIV_JP.

Actually, I'm not an expert on OCR, tesseract-ocr or tess-two.
So I wish I would discuss and get more advice, questions, and know-how for this issue.

Until it has enough accuracy and performance to be replaced to current official GoIV,
I'll commit it to my ocr-improvement branch in this GoIV_JP repo.
So please check that branch's history if it is interesting.
https://github.com/udnp/GoIV_JP/tree/ocr-improvement

[udnp]

Currently I'm planing it generally as following flow.

• 1st step
  to create English OCR data with the same way as my Japanese data

• 2nd
  to release tester build for checking English OCR accuracy and performance

• 3rd
  to create OCR data for other Latin character languages(es/fr/de/it/etc..) supported by official GoIV currently

• Goal
  to send PR to official repo for new GoIV release

• Future Work
  add support for Japanese OCR to GoIV (also Chinese if many users request)

[udnp]

commit 211dde8 included langdata for tessdata(*.traineddata file) from
https://github.com/tesseract-ocr/langdata.git with git subtree.

commit c1daca3 trained and created new OCR trained data eng.traineddata file,
with langdata which was cleared for optional langdata files and replace training text to that appears in Pokemon Go game app.

[udnp]

Comparison on the duration of OcrHelper.scanPokemon()

This compares following 2 builds.

• [A] commit aea9efd
  which includes optimizd eng.traineddata
• [B] commit 38e0fae
  which includes not optimized one as same as GoIV v5.2.6

And this compares folloing 2 cases using 2 build above.

• continuous quick preview for 10 pokemons not nicknamed by user
  this case is the simplest OCR detection
• continuous quick preview for 10 Alolan pokemons nicknamed by user
  this case is one of the most complex OCR detection

Note: continuous quick preview means like the gif animation image in the top comment of this issue
#32 (comment)

From this comparison, it seems that the optimization in commit aea9efd reduces about 1/2 duration on OcrHelper.scanPokemon() for current GoIV release version.

Following results are measured with ARM64 CPU device(Sony Xperia X compact) and Android Studio 3.1 Profiler.

continuous quick preview for 10 pokemons not nicknamed by user

[A] aea9efd	[B] 38e0fae
AVG. 401.114 msec.	AVG. 993.127 msec.
267.12	785.35
310.77	1880
309.99	1030
378.58	1020
526.72	1020
559.38	723.87
398.31	837.22
449.89	859.79
403.07	855.76
407.31	919.28

continuous quick preview for 10 Alolan pokemons nicknamed by user

[A] aea9efd	[B] 38e0fae
AVG. 575.797 msec.	AVG. 1045.397 msec.
802.12	873.76
286.64	592.24
356.38	604.35
378.94	793.52
299.84	548.07
344.26	635.03
1350	2070
530.18	1540
1080	2290
329.61	507

[udnp]

If interested, you can get the apk including optimized eng.traineddata with commit aea9efd from https://github.com/udnp/GoIV_JP/releases/tag/ocr_r1