Problem with accuracy on very good input

[CanadianHusky]

Environment

Windows 64bit.
Tesseract version v5.2.0.20220708 clean install from binaries [tesseract-ocr-w64-setup-v5.2.0.20220708.exe]

Current Behavior:

Command Line to Reproduce Problem:

C:\Program Files\Tesseract-OCR>tesseract --tessdata-dir "C:\Program Files\Tesseract-OCR\tessdata" "d:\temp\input.png" "d:\temp\output" --psm 3 -l eng

Input image attached inline

output.txt :
12/2/7 12174 /AH

Expected Behavior:

On such a clean Input I would expect the output to be
12/2/7 /2174 /AH

The inconsistent spacing is something that can be lived with, but the digit 1 instead of / is causing a serious problem

I tried all available --psm modes. No luck.

Suggested Fix:

Improve accuracy when digits, letters and special characters are involved

Thank you for the work on the new release

[stweil]

I'd expect 12 / 2 / 7 /2174 /AH. If you have lots of such images, training on the real images would help to get best results.

[CanadianHusky]

Thank you for the tip.
I lack a good and simple tutorial how to do proper training for images and fonts.

Also extra information, when the -l language parameter above is changed to -l deu with German text installed, the results get even worse. Extra 7's start to appear.
I have a hard time understanding why English and German letters cause such a difference on clean input. Also the / is recognized correct on some spots but not on others.
There are thousands of images with similar content and the sample above was representative.
In some cases the lead space on the left, or the white space at the top or bottom of the image effect the result...which is also a mystery to me why, but it must have something to do with the internal layout engine

[wollmers]

In this case you get better results with (deu or eng doesn't matter):

$ tesseract img.png img.deu.oem0.psm6 -l t5data/deu --psm 6 --oem 0 --tessdata-dir  /usr/local/share/tessdata txt; 
$ cat img.deu.oem0.psm6.txt
12/2/7/2174/AH

With --oem 0 you can get nice bounding boxes and detect spaces with a heuristic. Or if the numbers have a system, format them with spaces.

[CanadianHusky]

Very good and interesting tip indeed.
With --oem 0 the legacy engine gives far better results for these files. However the default eng.traineddata (4,017kb) and deu.traineddata (1,490kb) do not have the required legacy character models defined and without them this error happens.

Error: Tesseract (legacy) engine requested, but components are not present in C:/Program Files/Tesseract-OCR/tessdata/eng.traineddata!!
Failed loading language 'eng'
Tesseract couldn't load any languages!
Could not initialize tesseract.

When I load the older character models using another eng.traineddata (22,917kb) I get correct results at 240dpi (and higher) input resolution. Not only on the provided sample, but on the whole batch.

However at 200dpi input resolution --oem 0 fails at different, multiple other spots. Here some examples that should not fail in my opinion

50/1/4/2733[AP

[ detected instead of / but no mistakes on digits anymore

12/2/10/2178lAH

I detected instead of /

so while --oem 0 fixes the results for many files and digits for 240 and 300dpi input , it introduces other problems elsewhere if the input is 200dpi, which is still acceptable in my opinion

It would still be very nice if the newer LSTM Engine is tuned properly to handle such content correctly at 200dpi input quality