Use Tesseract's Orientation detection #111
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit fb4bbb7)
|
To clarify, is the 63% accuracy the completion accuracy from running |
|
That is correct: all the tests were run using the |
|
@tylermaran your question made me realize that it'll be more helpful to know the exact count of misclassifications across both approaches, and if've now added that to the PR's description. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR replaces the orientation correction mechanism with Tesseract's. It resulted in ~60-70% reduction in time taken by the orientation correction step (1.862s -> 756.95ms).
The confidence returned by the Tesseract is based on the number of glyphs detected and can result in extremely low scores (<1) even for correct detections. This is why this PR doesn't have a confidence threshold, as finding a score that works universally is a hard problem.
This is how both approaches fared on our test data set of 47 randomly rotated pages:
Before this change, the test resulted in ~63% accuracy. The dataset was randomly rotated to either 0, 90, 180, or 270 degrees, indicated as "randomly rotated" in the table below. This dataset was then used to compare Tesseract OSD and the chunking strategy. Tesseract OSD produced almost perfect results (61%) coming in close to the original Zerox performance of 63% (This 3% step down is discussed later on). On the other hand, the chunking strategy produced 47.10% accuracy (25% down).
This randomly rotated dataset can be found here.
Why the 2% step down?
Well, Tesseract failed to identify orientation for two images with the message "Too few characters. Skipping this page". For one of the image, cropping in to the receipt fixed this problem.
Tesseract has a configuration
min_characters_to_try, which was set to 0 but got the same result.And...
This PR also adds the image correction (trimming and orientation correction) if the image (PNG) is passed, which were bypassed before. This required in change in the
tempdirectory folder structure which is expected to have no user facing impact.Note:
When running this for the first time, tesseract downloads a file
osd.traineddatasized 10.6MB