Port to ocrd core version 3.0.0

[MehmedGIT]

Already migrated processors:

• OcropyBinarize
• OcropyClip
• OcropyDenoise
• OcropyDeskew
• OcropyDewarp
• OcropyRecognize
• OcropyResegment
• OcropySegment
• OcropyTrain
• PostCorrector
• CISAligner

[kba]

@bertsky Do we even want to catch these or should we let them explode and let core do the error handling? For page-wide binarization, I think we probably should because that means the page failed. But for region and line, we might have rogue instances of zero size but all the other regions/lines might be fine.

[bertsky]

We will soon catch all exceptions on the page level in core. So this should not be handled here.

Regarding lower-level error handling: We have discussed this before, but partial failures across a page in general mean we also must be able to cope with partial annotation (incremental processors). We have no real solution ATM.

But since this PR just preserves the current behaviour (skipping partial failures regardless of level), and there are also other possible causes to catch in core, let's keep it like this.

[kba]

ocrd-cis-ocropy-binarize with new API LGTM!

[MehmedGIT]

Would you be willing to switch from CircleCI to GithubActions?

Sure, let's try that!

I will push a simple Github Actions workflow to this PR to execute the tests.

[MehmedGIT]

@bertsky, I think the GitHub Actions workflow is not triggered until you have that in your fork's master/main?

[bertsky]

I think the GitHub Actions workflow is not triggered until you have that in your fork's master/main?

No, AFAIK GH Actions must be activated for each GH repo/fork individually. So in this case, it would be your fork. Then once I merged here, I have to enable on my fork. And once fix-alpha-shape gets merged upstream, GHA would need to be activated there.

[bertsky]

Wow. So with that we now know that we will get more problems on Ocrolib starting with Python 3.9:

NameError: name 'NaN' is not defined

But at least 3.8 runs through (and fast!)

[MehmedGIT]

No, AFAIK GH Actions must be activated for each GH repo/fork individually. So in this case, it would be your fork. Then once I merged here, I have to enable on my fork. And once fix-alpha-shape gets merged upstream, GHA would need to be activated there.

It was probably me who messed up a bit and created the workflow folder instead of workflows ... Maybe it was just enough to rename the folder instead of merging branches to the master. To trigger GH Actions on this PR.

[bertsky]

Ok, so what do we do next? Debugging CircleCI seems tiresome, perhaps we should just deactivate that (keeping the config file). But then we should also add a CD to GHA. (The credentials for ocrd on Dockerhub must be added as a Secret in project settings IIRC.)

[MehmedGIT]

Wow. So with that we now know that we will get more problems on Ocrolib starting with Python 3.9

I will see if I can find a fast fix for that. But I will have to modify the ocrolib slightly to make NaN work with higher Python versions.

EDIT: All tests pass now after 224e86f and a397531. Not sure if a397531 was needed since tests pass regardless.

[MehmedGIT]

But then we should also add a CD to GHA. (The credentials for ocrd on Dockerhub must be added as a Secret in project settings IIRC.)

Yes.