Calamari2

[bertsky]

(also based on #117)

[mikegerber]

Are the licensing issues with Calamari 2.x resolved?

[bertsky]

CI failure: ValueError: bad marshal data (unknown type code) – this is wild! Happens on Python 3.8, where the models still used to work, and I cannot reproduce locally. We can go for SavedModel format (model version 5→6) which has been merged in Calamari master (but not on PyPI), but I feel I am missing something here...

Are the licensing issues with Calamari 2.x resolved?

Like I said elsewhere: we have to go for GPL3 all the way, all we need is your consent here (and @andbue's and @chreul's for Calamari itself).

[bertsky]

use C2 deep3_fraktur19 model for testing 260f184

note: I will still try to convert your qurator-gt4histocr-1.0 model, but at the moment this is blocked by Calamari-OCR/calamari#362

[mikegerber]

Like I said elsewhere: we have to go for GPL3 all the way, all we need is your consent here (and @andbue's and @chreul's for Calamari itself).

Yeah OK. Just so we are on the same page: until then we can't merge this IMHO.

IIUC, it's also may not be possible for Calamari to go GPL3 so easily, see first comments of Calamari-OCR/calamari#3.

[bertsky]

IIUC, it's also may not be possible for Calamari to go GPL3 so easily, see first comments of Calamari-OCR/calamari#3.

Like I said there, I disagree with that assessment. To the extent that Calamari borrows from Ocropy it shared the same license, but with Calamari 2 all the machinery was implemented by tfaip (i.e. rewritten). The only shared components are things like the line dewarper (aka. center normalizer) which have to be included merely to provide backwards data compatibility, and could be argued to be part of the models (data), not the runtime (code).

Yeah OK. Just so we are on the same page: until then we can't merge this IMHO.

I'll try to get them to do it for C2.

So can I change the license here within this PR?

[bertsky]

Oh, btw, this PR does still not achieve what we want in terms of GPU efficiency – we are still as peaky as in #116 even with core v3's page parallelism. I'm afraid we have to switch from multithreading to multiprocessing model in core...

(this is with 6 parallel pages – no benefit at all over single-page processing!)

[bertsky]

CI failure: ValueError: bad marshal data (unknown type code) – this is wild! Happens on Python 3.8, where the models still used to work, and I cannot reproduce locally. We can go for SavedModel format (model version 5→6) which has been merged in Calamari master (but not on PyPI), but I feel I am missing something here...

Since we have to move in that direction anyway, I converted everything in calamari_models and calamari_models_experimental and created new releases with all the tarballs as assets, and referenced them here. Now we just need a new release 2.3 of Calamari master on PyPI to make that work with our CI...

[bertsky]

For some reason, CircleCI does not trigger anymore (and I have no permission to). I did fix it with the last commit, though – see CI on my branch.

BTW, there's a branch looming which I will eventually merge here: https://github.com/bertsky/ocrd_calamari/tree/calamari2-subprocess – that depends on bertsky/core#23 and finally solves our performance bottleneck. I'll open the PR and document everything as soon as I can add the dependency on the core version.

[bertsky]

So for comparison:

• same as before (predict_pipeline), but with multiprocessing instead of multithreading:
  

• the same with predict_on_batch:
  

• the same in a continous (infinite) generator only set up once and fed via queue; batches need to be filled up with empty images as long as any consumers remain