Clemens Neudecker

Other @OCR-D users also reported issues with `anybaseocr-crop`. But if the expected results can in fact be achieved with https://github.com/mikegerber/my_ocrd_workflow/, this rather hints at a problem in the OCR-D workflow...

Possibly relates to https://github.com/qurator-spk/sbb_textline_detection/pull/48

Since the situation with modules still requiring tf1 is indeed a nightmare, could we "soft" migrate those modules to tf2 using [`tf.compat.v1`](https://www.tensorflow.org/api_docs/python/tf/compat) and thoroughly test that for regressions?

> It's still not entirely clear to me under which circumstances the other steps apply Indeed, this is mainly what I also wonder about - how can we better assess...

> we'll just have to start trying – and back every step of the way up Exactly, those conflicts and workarounds require discussion, fixes, testing as well and thereby more...

I think thar for target group an AppImage could indeed have a lot to offer, since it does not require superuser rights on the host (contrary to Docker).

Also https://github.com/OCR-D/ocrd-website/issues/78

IIUC this will be fixed by https://github.com/OCR-D/core/pull/966 when OCR-D is used through the [Web API](https://ocr-d.de/en/spec/web_api).

Closing here as https://github.com/OCR-D/core/pull/966 has now been merged.

> BTW, is there a particular reason for keeping the TF1-style session management? I found that if I remove it completely (including the explicit GC calls), **and** avoid repeating `load_model`...