update modules (missing dockerhub key)

[bertsky]

You may also want to include

• Processor: allow empty output file grp core#1321 (or v3.3.1)
• V3 api qurator-spk/dinglehopper#128
• port to v3 ocrd_olahd_client#12
• migrate to OCR-D v3 ocrd_keraslm#23

– once they are merged, respectively.

[MehmedGIT]

Looks great!

[mikegerber]

Please don't include the linked PR for dinglehopper and wait for a release. The PR currently contains a change of CER calculation that needs discussion. Otherwise we'd end up with a dinglehopper in ocrd_all that gives different results ...

I also wish if ocrd_all would start using the versioned releases - I specifically started doing those releases for OCR-D, but they don't seem to be used.

[stweil]

I also wish if ocrd_all would start using the versioned releases - I specifically started doing those releases for OCR-D, but they don't seem to be used.

Yes, please, and not only for dinglehopper, but for all submodules.

[mikegerber]

Please don't include the linked PR for dinglehopper and wait for a release. The PR currently contains a change of CER calculation that needs discussion. Otherwise we'd end up with a dinglehopper in ocrd_all that gives different results ...

I've released dinglehopper v0.10.0 with the V3 update (but not the proposed change to using normalized CER. (For the latter there is a separate PR now.)

[bertsky]

@mikegerber The dinglehopper update was originally (the last remaining submodule) scheduled for this PR as our last release of the ocrd/all fat container images. For that, it must still support Python 3.8, which all our base stages are currently built on (because some module still rely on Tensorflow 1.x, which is only available prebuilt via nvidia-tensorflow for Py38). That can only be overcome by the slim containers (where every module can have its own base version of Python etc). So can we please get a version that does not rely on uniseg>=0.9? See here for how this fails our ocrd/all builds. It all hinges on this module now.

I cannot speak to whether or not my normalized-cer branch should have been included. We had a frenzy of PRs and updates on our hands for v3 and related updates. So I guess combining this was to save time (as we also depend on usable results without Infinity or averages over CER results above 100%).

[bertsky]

superseded by #462

[mikegerber]

@mikegerber The dinglehopper update was originally (the last remaining submodule) scheduled for this PR as our last release of the ocrd/all fat container images. For that, it must still support Python 3.8, which all our base stages are currently built on (because some module still rely on Tensorflow 1.x, which is only available prebuilt via nvidia-tensorflow for Py38). That can only be overcome by the slim containers (where every module can have its own base version of Python etc). So can we please get a version that does not rely on uniseg>=0.9? See here for how this fails our ocrd/all builds. It all hinges on this module now.

Ah, that's good context to know, I wasn't aware of this (and only checked EOLness of Python 3.8 after it broke). I will release 0.10.1 shortly with the patch!

[mikegerber]

I cannot speak to whether or not my normalized-cer branch should have been included. We had a frenzy of PRs and updates on our hands for v3 and related updates. So I guess combining this was to save time (as we also depend on usable results without Infinity or averages over CER results above 100%).

I can say it definitely didn't save ME time. It's a rather intrusive change because it redefines CER and this needs much more thought w.r.t. proper integration. It gives different results for users! To be me it's clear that it needs more love than sneaking it in with a PR that was just supposed to update to OCR-D's V3 API.