我不确定是我的基础设施在做这些奇怪的事情还是 tesseract-ocr 本身。
每当我在单进程环境中使用 image_to_stirng - tesseract-ocr 工作正常。但是当我用 gunicorn 生成多个 worker 并且他们所有人都开始使用 ocr 阅读进行一些工作时 - tesseract-ocr 开始阅读非常差(不是来自性能虎钳，而是来自准确性虎钳)。即使在加载完成后 - tesseract 也永远不会具有相同的准确性。我需要重新启动所有工作人员，以使 tesseract 再次正常工作。
这太奇怪了。也许有人经历过或听说过这个问题？
最佳答案
(注意以下信息是基于对 pytesseract.py 代码的审查，我没有尝试设置多进程测试来检查)
有几个 Python 库与 tesseract-ocr 接口(interface)。您可能正在使用 pytesseract(通过 image_to_string 函数猜测)。
该库将 tesseract-ocr 二进制文件称为子进程，并使用临时文件与其交互。它使用 过时的 tempfile.mktemp() 不保证唯一的文件名 - 此外，它甚至不按原样使用返回的文件名，所以第二次调用到 tempfile.mktemp() 可以轻松返回相同的文件名。
考虑为 tesseract 使用不同的 python 接口(interface)库:例如，来自 Google 的 pip install tesseract-ocr 或 python-tesseract (https://code.google.com/archive/p/python-tesseract/)。
(如果问题实际上出在临时文件上，正如我所怀疑的那样)您可以通过为每个生成的工作进程设置不同的临时目录来解决此问题:
td = tempfile.mkdtemp()
tempfile.tempdir = td
try:
# your-code-calling pytesseract.image_to_string() or similar
finally:
os.rmdir(td)
tempfile.tempdir = None
关于python - Tesseract 3.x 多处理怪异行为，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52046331/