История одного бага или как я сделал пул-реквест в PaddleOCR С августа месяца мне приходится активно решать задачи, связанные с оптическим распознаванием символов (OCR): детекция текста, сегментация на слова/линии, распознавание чисел и слов. Как я уже говорил в посте выше, для решения части задач я использую библиотеку PaddleOCR. Меня радует, что там довольно активное сообщество, которое развивает продукт, и оперативно исправляет баги. Однако один из багов заставил потратить меня несколько дней на решение проблемы, которая исправлялась одной строчкой, но обо всём по порядку. Если вы когда-нибудь пытались обучить что-то с помощью этого фреймворка. то могли заметить, что в настройках по умолчанию стоит ограничение на размер выходной последовательности символов (25). Таким образом, вы можете либо производить распознавание отдельных слов, либо модернизировать этот параметр, обучить модель и распознавать уже целые предложения (строчки). Второй вариант в моем случае был более привлекательным, так как это совпадало и с бизнес-требованиями, и с наличием разметки под эту задачу. Я обучил несколько разных моделей с разным входным разрешением и разным количество выходных символов. Затем, каждую из них нужно сконвертировать, без этого инференс работать не будет. Каково было моё удивление, когда вне зависимости от того, что стоит в файле конфигураций модели, на выходе всегда не больше 25 символов. На этом моменте я уже понимал, что дело пахнет исследованием исходников. Разбираться в чужом коде - неизбежность, но всегда пытаешься отложить это на последний момент, потому что процесс может затянуться. Баг оказался в следующем - параметр, отвечающий за длину выходной последовательности, не передавался в конструктор класса, а в конструкторе класса значение по умолчанию равнялось 25. Добавление одной строчки исправило проблему, а я решал сделать пул-реквест, чтобы никому в будущем не пришлось заниматься подобными раскопками. Недавно его смержили, так что в следующем релизе этой ошибки уже не будет.