Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for OCR confidence data? #19

Open
hdevalence opened this issue May 26, 2020 · 7 comments
Open

Support for OCR confidence data? #19

hdevalence opened this issue May 26, 2020 · 7 comments

Comments

@hdevalence
Copy link

It would be great to be able to access data on the confidence of some OCR result. I'm not super familiar with the C++ API but it looks like this can be obtained by this API.

Would it make sense to adapt this to an impl Iterator? One difficulty is that the next, etc. functions in the C++ API are all parameterized by a level parameter, while Iterator::next doesn't take any parameters. One way to get around this would be to have an internal Iter struct that wraps a C++ ResultIterator with a set level, and provide multiple functions like iter_blocks() -> impl Iterator<Item = ...>, iter_words() -> impl Iterator<Item = ...> that internally construct an Iter with the appropriate level.

The Item would need to be some type, say OcrResult, that exposes all of the result data to be passed through. The C++ functions are on the iterator itself, meaning that they can only be called for the current item. Because the Iterator trait doesn't impose any lifetime constraints on the Items, I think that this means that all the data in OcrResult has to be populated upfront when it's constructed in the next() call, because it can't be retrieved later. But the upshot would be that the OcrResult could just be a plain struct that people can pattern match on and destructure. For a start maybe just the confidence value, the text, and the rect would be enough.

@ccouzens
Copy link
Collaborator

I'll stick it on the radar, but for now I'm focussed on improving what's already here.

@hdevalence
Copy link
Author

I'd be happy to implement it, as long as something like that design sounds OK to you and you would have time to review it.

@ccouzens
Copy link
Collaborator

That sounds good to me.

Do you mind if I get my refactor merged in before you start though?
I've got a free evening tomorrow, so I'm hoping to open a pull request then.

@ccouzens
Copy link
Collaborator

I've got a free evening tomorrow, so I'm hoping to open a pull request then.

Not tonight, I'm falling asleep. Soon though, all that's left is finishing error types, the builder pattern and a git history cleanup.

@ccouzens
Copy link
Collaborator

ccouzens commented Jun 5, 2020

The refactor has been merged in. You're good to start whenever you're free.

@Gearme
Copy link

Gearme commented Dec 27, 2020

Any progress on this?

@ccouzens
Copy link
Collaborator

@Gearme no progress as far as I'm aware.

Would you like to pick this up?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants