Closed RedFantom closed 7 years ago
So, I'm a bit confused now. Should I turn the SimpleOCR
into a function that builds a OCR
object? Perhaps integrate the advanced functions into the OCR
class itself?
I took some time to see what a merge could look like, pushed to 55c645dcfbd6e946ce1a22fa886f5b0625cb17d0 . The only big change is the functionality is ground-on-train, which I think should be avoided. I've changed ground()
to write the results to the file.
I've also done few changes to the tests in master
so we don't need to hardcode the grounds into the tests - we can use the existing ones.
Can you please take a look and tell me what you think? Feel free to change anything
I've made some slight changes to your changes, specifically on formatting and changing the tests, but to me it looks all good now. Thank you for taking a look at it!
Looks good, thanks for the formatting fixes!
Be careful with the tests, you'll have to merge from master
. The current version doesn't have hardcoded ground data, since the included files are already grounded
The tests complete successfully, so I don't really understand what the problem with the grounding data would be? It completes in Travis and on my Windows 7 PC, so the code works just fine...
Oh, actually, my bad. I forgot to push the master
changes to github!
Alright, let's merge this in and I'll rebase my changes on top, it's easier at this point :)
Ok, I merged the tests refactor and pushed to master
. It succeeds in travis, but please let me know if you find any trouble with cv3/windows
These four commits contain the addition of the
SimpleOCR
class and the tests for it, so that users can use a more straightforward interface to the library, without losing the advanced options if they wish to use them. One class as an interface for segmentation, classification, grounding and performing OCR.