Обновить

Комментарии 11

Больше удивляет, что jsQR после фейла первой тройки вообще не пробует следующую. Т.е. правильные ориентиры могут уже быть найдены, но один удачный кусок текста всё равно валит распознавание целиком. Возможно, логичнее было бы проверить ещë хотя бы 2-3 кандидата и уже послеэтого отдавать null. Интересно, насколько это вообще затратно по времени на камере.

Проверил на исходном растре: первые три группы оказались одной и той же тройкой в разном порядке. Перебор всех пяти сформированных групп тоже не помог. Здесь нужно менять ещё и формирование групп, а не только перебирать готовый список. Время на камере не измерял.

Тогда можно попробовать после неудачи уточнить центры исходных кандидатов, пересчитать их score и заново собрать группы. Сейчас recenterLocation работает уже с выбранной тройкой, поэтому отброшенному верхнему левому ориентиру не помогает. В вашем примере настоящий верхний левый ориентир как раз найден со смещённым центром и получил плохую оценку. Возможно, повторный отбор после уточнения центров даст больше, чем перебор прежних групп.

Проверил, на этом примере сработало. После уточнения центров перед оценкой и сборкой групп исходная картинка с подписью прочиталась без изменений. Спасибо за идею. На перспективных искажениях пока не проверял.

Локатор ищет чередования чёрного и белого. Если провести линию через центр углового узора QR, ширины полос должны соотноситься как 1:1:3:1:1

Первый раз слышу про определение QR через линию по центру.

Опорные точки QR помимо угловых квадратов

Речь о сечении большого углового квадрата, не о линии через весь QR. Через его центр чередование чёрного и белого даёт 1:1:3:1:1; jsQR проверяет его по горизонтали, вертикали и диагоналям. На вашей схеме отмечены выравнивающие узоры и синхронизирующие дорожки. Они не отменяют этот этап поиска.

Только вот на самом QR тоже еще может быть несколько паттернов 1:1:3:1:1.
Не хватает поясняющей картинки:

Скрытый текст

Да, такие сочетания встречаются и внутри QR. Поэтому одного совпадения 1:1:3:1:1 недостаточно: jsQR проверяет узор по нескольким направлениям. В нашем случае и эти проверки пропустили фрагмент подписи. Спасибо за картинку.

А почему локатор не смущается тем, что "найденный" им треугольник совсем не равнобедренный, как будто камера смотрит на QR-код откуда-то сбоку под экстремальным углом? В нем никакого sanity check нет?

Проверки есть, но именно форму треугольника при ранжировании групп jsQR 1.4.0 не оценивает: учитывает похожесть узоров и различие их размеров. Жёсткое требование равных сторон отсекало бы и настоящие QR, снятые под углом. Проверка геометрии здесь могла бы помочь, но её допуски нужно проверять на перспективных искажениях.

Вспоминается очень раздражающий момент на кассах самообслуживания с этими QR, когда сканер сканирует что угодно, только не нужный код.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации