Многопроцессорное поведение Tesseract 3.x - PullRequest
0 голосов
/ 27 августа 2018

Я не уверен, что эта странная штука делает моя инфраструктура или сам tesseract-ocr.

Всякий раз, когда я использую image_to_stirng в однопроцессной среде - tesseract-ocr работает отлично. Но когда я порождаю нескольких рабочих с помощью gunicorn, и все они выполняют некоторую работу с чтением ocr - tesseract-ocr начинает читать очень плохо (и не с точки зрения производительности, а с точки зрения точности). Даже после того, как нагрузка завершена - тессеракт никогда не будет иметь одинаковую точность. Мне нужно перезапустить всех рабочих, чтобы снова заставить работать тессеракт.

Это супер странно. Может быть, кто-то опыт или слышал об этой проблеме?

1 Ответ

0 голосов
/ 28 августа 2018

(ПРИМЕЧАНИЕ. Приведенная ниже информация основана на обзоре кода pytesseract.py, я не пытался настроить многопроцессный тест для проверки)

Существует несколько библиотек Python, которые взаимодействуют с tesseract-ocr. Возможно, вы используете pytesseract (угадывание по функции image_to_string).

Эта библиотека вызывает двоичный файл tesseract-ocr как подпроцесс и использует временные файлы для взаимодействия с ним. Он использует устаревший tempfile.mktemp(), который не гарантирует уникальные имена файлов - кроме того, он даже не использует возвращенное имя файла как есть, поэтому второй вызов tempfile.mktemp() может легко вернуть тот же файл имя.

Рассмотрите возможность использования другой библиотеки интерфейса Python для Tesseract: например, pip install tesseract-ocr или python-tesseract от Google (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
...