1) При конвертации A4 PDF я использовала DPI = 200. Этого достаточно для большинства документов.
2) 960×960 пикселей - это вход модели детекции, а не ограничение на исходное изображение.
Исходное изображение (включая большие форматы) масштабируется до 960 × 960 перед подачей в детектор. (Пробовала ещё 640, 1280 пикселей, для 960 - лучшее качество детекции).
После того как детектор нашёл прямоугольники на уменьшенной картинке, координаты bbox обратно масштабируются к исходному размеру.
Текст вырезается из оригинального изображения (не из уменьшенного).
3) Распознаватель rec работает с одной строкой текста (с фиксированной высотой). Хорошая модель детекции, на предыдущем шаге, должна найти каждую строку отдельно. Поэтому целый абзац на вход rec не попадёт.
4) Да, smart_resize это правильный подход. Но я использовала OpenCV библиотеку, там эту логику я писала вручную:
scale = target_size / max(h, w) new_h, new_w = int(h х scale), int(w х scale) new_h = int(round((new_h / 32) х 32)) new_w = int(round((new_w / 32) х 32))
cv2.resize(image, (new_w, new_h))
5) Инференс за 5 секунд на 8 vCPU И 16 ГБ RAM - вполне реально. На такой конфигурации latency для скана А4 с умеренной плотностью текста составляет 3-4 секунды.
Теперь кажется поняла суть. Спасибо, что поделились — очень интересный кейс!
На таких тонких местах я Paddle не тестировала. Вероятно, такие махинации с картинками реальны, и FineReader от ABBYY ‘без самодеятельности’ в таких сценариях действительно выигрывает.
Забавно, что потребность в разработке нового быстрого OCR как раз возникла из желания заменить решение от ABBYY.
В чём FineReader оказался слабее:
коммерческий, платная лицензия
инференс примерно в два раза медленнее, чем у Paddle решение
качество распознавания хуже: там, где FR распознаёт 50–60% текста, Paddle выжимает 85% и больше.
Но это замеры на ‘чистых’ данных, без намеренных искажений.
Спасибо за крутой вопрос - он намного фундаментальнее и шире темы статьи, постараюсь всё же прокомментировать.
При подаче на вход в OCR изображения (JPEG, PNG, BMP, TIFF), оно представляется как матрица пикселей, в которой нет ничего тайного. Поэтому OCR видит картинку примерно так же, как и человек, и детектирует только те символы, на которых обучалась модель. Управляющие символы (например, tab, конец строки) не могут быть прочитаны, так как у них нет графического представления. Нелегитимные техники вроде ‘белым по белому’ тоже потеряют контраст и станут невидимы как для глаза, так и для OCR.
При оцифровке возможна подмена букв визуально схожими символами (как в слове P@ssw0rd). Тогда можно в исходном файле словаря в ручном режиме заменить спорные символы на более приоритетные. Например, заменить греческие символы на латиницу.
А вот риски, связанные с data poisoning, могут возникнуть на этапе конвертации PDF в картинку. Если в pdf есть скрытые слои, они могут проявиться: в исходном pdf не видны, а на изображении уже есть. Тогда OCR читает их как обычную картинку. Если в результате схлопывания слоёв после pdf на картинке возникло много шума, можно попытаться очистить его, повысить контраст... Но серебряной пули словно нет.
В данном алгоритме никаких мер защиты не предусмотрено - просто читаем текст с картинки. Но есть о чём задуматься, спасибо!
Спасибо за вопросы, с удовольствием отвечу:
1) При конвертации A4 PDF я использовала DPI = 200. Этого достаточно для большинства документов.
2) 960×960 пикселей - это вход модели детекции, а не ограничение на исходное изображение.
Исходное изображение (включая большие форматы) масштабируется до 960 × 960 перед подачей в детектор. (Пробовала ещё 640, 1280 пикселей, для 960 - лучшее качество детекции).
После того как детектор нашёл прямоугольники на уменьшенной картинке, координаты bbox обратно масштабируются к исходному размеру.
Текст вырезается из оригинального изображения (не из уменьшенного).
3) Распознаватель rec работает с одной строкой текста (с фиксированной высотой). Хорошая модель детекции, на предыдущем шаге, должна найти каждую строку отдельно. Поэтому целый абзац на вход rec не попадёт.
4) Да, smart_resize это правильный подход. Но я использовала OpenCV библиотеку, там эту логику я писала вручную:
scale = target_size / max(h, w)
new_h, new_w = int(h х scale), int(w х scale)
new_h = int(round((new_h / 32) х 32))
new_w = int(round((new_w / 32) х 32))
cv2.resize(image, (new_w, new_h))
5) Инференс за 5 секунд на 8 vCPU И 16 ГБ RAM - вполне реально. На такой конфигурации latency для скана А4 с умеренной плотностью текста составляет 3-4 секунды.
Теперь кажется поняла суть. Спасибо, что поделились — очень интересный кейс!
На таких тонких местах я Paddle не тестировала. Вероятно, такие махинации с картинками реальны, и FineReader от ABBYY ‘без самодеятельности’ в таких сценариях действительно выигрывает.
Забавно, что потребность в разработке нового быстрого OCR как раз возникла из желания заменить решение от ABBYY.
В чём FineReader оказался слабее:
коммерческий, платная лицензия
инференс примерно в два раза медленнее, чем у Paddle решение
качество распознавания хуже: там, где FR распознаёт 50–60% текста, Paddle выжимает 85% и больше.
Но это замеры на ‘чистых’ данных, без намеренных искажений.
Спасибо за крутой вопрос - он намного фундаментальнее и шире темы статьи, постараюсь всё же прокомментировать.
При подаче на вход в OCR изображения (JPEG, PNG, BMP, TIFF), оно представляется как матрица пикселей, в которой нет ничего тайного. Поэтому OCR видит картинку примерно так же, как и человек, и детектирует только те символы, на которых обучалась модель. Управляющие символы (например, tab, конец строки) не могут быть прочитаны, так как у них нет графического представления. Нелегитимные техники вроде ‘белым по белому’ тоже потеряют контраст и станут невидимы как для глаза, так и для OCR.
При оцифровке возможна подмена букв визуально схожими символами (как в слове P@ssw0rd). Тогда можно в исходном файле словаря в ручном режиме заменить спорные символы на более приоритетные. Например, заменить греческие символы на латиницу.
А вот риски, связанные с data poisoning, могут возникнуть на этапе конвертации PDF в картинку. Если в pdf есть скрытые слои, они могут проявиться: в исходном pdf не видны, а на изображении уже есть. Тогда OCR читает их как обычную картинку. Если в результате схлопывания слоёв после pdf на картинке возникло много шума, можно попытаться очистить его, повысить контраст... Но серебряной пули словно нет.
В данном алгоритме никаких мер защиты не предусмотрено - просто читаем текст с картинки. Но есть о чём задуматься, спасибо!