-
Notifications
You must be signed in to change notification settings - Fork 16
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
add Docker and GHA CD via Dockerhub #70
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I am aware that it has been deprecated for a while but until we have the binarization functionality in eynollah available via OCR-D interface, this is still one of the best binarizers out there and we should support it as a slim container in ocrd_all.
Py3.9 and 3.10 failures are extremely strange: >>> import sbb_binarize.cli
>>> type(sbb_binarize.cli)
>>> sbb_binarize.cli is None
>>> import inspect
>>> inspect.ismodule(sbb_binarize.cli)
>>> So it seems that Python has some kind of |
Migrating from setup.py to pyproject.toml did not help. |
I'll also relax TF requirement slightly (to be in line with eynollah) – tested: no different between 2.11 and 2.12. |
oh, wow – relaxing the TF requirements also magically fixed the problem with Py3.9 and 3.10! (I wonder why we did not receive a build-time error saying that no such TF version is available, though...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The dockerimage does not work for me without these changes. I testet ocrd-sbb-binarize --help
and a simple binarization, which took quite long (72 secs for a single image).
Maybe it would also be good to include one ore more models into the dockerimage, because I had to download one by myself with resmgr, but I am not sure if this should be included.
Co-authored-by: joschrew <91774427+joschrew@users.noreply.github.com>
Co-authored-by: joschrew <91774427+joschrew@users.noreply.github.com>
yes, without a GPU this is slow, and even with it is not efficient. But that's well known and not the issue here.
No, that would just bloat the image. Downloading models in advance of using is the normal procedure for OCR-D. We don't want to reign in the admin's decision where to store persistent data (like models, which should not change as often as code).
In principle, yes. But since here, TF is pinned to But we should at least switch to |
So this is ready IMO. Fixes #67 and also brings support for Python 3.9 and 3.10. |
Dear all, thx - I can merge this today but would have 2 more small requests:
|
@cneud done!
let's see if it works
IMO it would make sense now to relax Eynollah's current pin (2.12.1) as well (2.12.x) – so we don't reintroduce the conflict if some TF 2.12.2 should be published |
Will do and thanks again! Ready to merge in 3, 2, 1... |
No description provided.