Mike Gerber

> (The situation is different for @mikegerber's [solution](https://github.com/mikegerber/my_ocrd_workflow/) IIUC, because its outer layer is native, not Docker.) Yes, the containers are intended to provide dependency-isolated processors to the native/host-side workflow...

Related: qurator-spk/ocrd_repair_inconsistencies#2

Documentation from https://ocr-d.de/en/workflows: * plausibilize = Remove redundant (almost equal or almost contained) regions, and merge overlapping regions * sanitize = Shrink and/or expand a region in such a way...

There's the wrong CUDA Toolkit version for the TF version in the image: https://github.com/OCR-D/ocrd_calamari/issues/68#issuecomment-951998665

→ https://github.com/OCR-D/ocrd_all/issues/263

TensorFlow and CUDA, the endless joy: ~~~ (headless-tf2) root@29b1f018638e:/usr/local/sub-venv/headless-tf2# pip list | grep tensorflow tensorflow 2.6.0 (headless-tf2) root@29b1f018638e:/usr/local/sub-venv/headless-tf2# find /usr/ -name "libcuda.so*" /usr/local/cuda-10.0/compat/libcuda.so.1 /usr/local/cuda-10.0/compat/libcuda.so /usr/local/cuda-10.0/compat/libcuda.so.410.129 ~~~ So this is CUDA...

Now using docker's `--mount type=tmpfs,destination=/tmp`. This may be a problem if any user switching is going on (not only here from root to some other user).

Without knowing anything about processing server: Is a default global file-writable logfile a good idea? If this were optional, user could enable one of their choosing? How about workspace-local or...

Yeah, this happens with a workspace built with `ocrd workspace` itself... `add` seems to make, for example, this: ``` ```

1. Removing the FLocats with `LOCTYPE="URL"` 2. and making the image filename referenced in the PAGE XML consistent (I imported the XML) fixes the validation at least (in the sense...