Add Tesseract training setup scripts and example data

[Penguin2600]

Work In progress, opening for visibility.

Current status:

tessTrain/tessTrain.sh - works and will set up a baseline ubuntu 22.04 wsl / container / etc with the tools and binaries required for training tesseract. It will also run an example training session with the included example training data. Documentation and sources are commented inside the script for further details look there for now.

tessTrain/example_truth/ - Example of what a training data directory needs to look like. Used by tessTrain.sh to confirm that setup was successful.

Ping me on discord for any questions or comments! Thx.

[TwoAbove]

Looks good!

Left a couple of minor comments.

I also have a question about dataScripts/tessTrain/example_truth/97984949.png and similar ones. Would the extra M hinder the training in any way?

[TwoAbove]

I think it would make sense to extract this into the README as a ## training tesseract section.

I would split this script into two parts - a setup.sh script (also mention it in the README in the setup instructions) and a train.sh script that takes in a ground truth path.

[Penguin2600]

Totally, I had the same thought. one will likely run once while the other may need many runs.

[TwoAbove]

Since this script creates artifacts, we'll need to add them to a .gitignore file. Ideally, we would keep the sole .gitignore so it's consolidated in one place.

[Penguin2600]

Good Callout, I'll consider what the new entries might need to be.

[TwoAbove]

These too

[TwoAbove]

Is there a way to not populate paths outside of noitool? It would be great if this would be confined to this directory. It looks like you can use TESSDATA variable to make it local. https://github.com/tesseract-ocr/tesstrain?tab=readme-ov-file#train

[Penguin2600]

Yes, I think that's a great idea, will incorporate.

[Penguin2600]

I also have a question about dataScripts/tessTrain/example_truth/97984949.png and similar ones. Would the extra M hinder the training in any way?

Short Answer:
I don't know.

Long answer:
My best understanding is that if it tags that partial M as a glyph (box generation step) then it may, in the training, try and label it. Which it will almost certainly fail at since it is not present in the corresponding gt.txt file. This will increase the resulting training error due the mismatch which may in a sort of artificial way cause that training data to be ignored in the training. Ideally we should give it perfectly clean images and a perfectly clean matching ground_truth text. In this case depending on the training execution variables I see 90-98% success rates on validation data out of the minimal example training set.