После того как найден регион происходит его классификация нейронной сетью. Точность классификатора 96%.
Другими словами Mask R-CNN находит номера и др артефакты, потом классификатор c точностью 96% отбраковывает не номера и поэтому вероятность что в профильтрованых результатах остались артефакты 4%. (В примере выше если regionId == 0 зона с регионом уже отбракована, ее можно распознать для интереса, а можно и отбросить)
Сам классификатор легко и относительно недолго тренируется. Об этом расказывать долговато, поэтому оставил для будущих статей.
Конечно все расчитывалось по нашей обучающей выборке, где нету номеров РФ, так что для того чтоб наверняка померять точность для вашего случая, нужно разметить примеры номеров РФ и добавить их общую обучающую выборку и дотренировать модель, потом в классификатор добавить еще один выход (назовем его 'ru') и повторно натренировать классификатор, тогда точность можно померять на заданной тестовой выборке.

Да, конечно, просто мы до этого этапа еще не дошли, т.к. для наших задач получили приемлемую точность.

Спасибо за статью! Шикарный материал для ознакомления с возможностями Mask R-CNN. Поправьте, пожалуйста, ссылку на файл requirements.txt, указанную в статье — сейчас там 404.

Спасибо что написали — пофиксим, когда я сформировал этот файл у себя на компе туда повписывало все модули, которые у меня установлены, а их очень много. Тогда я решил в docer-е поставить все по минимому чтоб все заработало, но закрутился и забыл. Сегодня сделаем, проапдейтим и выложим.

Вопрос: есть ли возможность в Вашем решении дообучать модели, «докидывая» новые фото, но не стартуя обучения с нуля?

Если речь идет о самом нахождении границ номера с помощью Mask R-CNN, там только дообучать. Мы и сами дообучали модель из coco dataset.
Если речь идет о классификаторе, с помощью которого получать тип номера, то там дообучать можно, но по времени и качеству это не сильно будет отличаться от «обучения с нуля»

Границы определило правильно и класcифицировало номер правильно [eu], значит плохо отработал tesseract. Думаю для данного типа номеров нужно применять другой модуль для распознавания, либо писать собственную реализацию.

Ну прям 100% не будет, конечно. Нейронка ищет что-то похожее на номера, мы тренировали на базе 1 125 фото, а рекомендуют 5 000, так что потенциально точность можно улучшить. Кроме того, в нашей выборке не было номеров РФ :). Размечать выборку это очень монотонная и неинтересная работа, поэтому мы ограничились минимумом, с которым у нас все заработало довольно неплохо для украинских номеров.

Точное распознавание такого знака требует:

• После нормализации, зная структуру номера разбить на зоны, в которых 1 позиция 1 символ, вам следует искать предполагаемый центр каждого символа.
• Далее вырезаем предполагаемый участок с символом и классифицируем его согласно возможных вариантов, которые там могут встречаться. Тут следует не сильно боятся зацепить часть рядом стоящего символа, хорошо натренированный классификатор это не остановит :)
• Ну и в конце постобработка, по вероятности сочетания тех или иных символов в номерных знаках РФ. Вероятность комбинаций можно получить проанализировав базу с реестром номерных знаков. Украинские данные открыты с 2013 года — там уже более 9 млн записей, достаточно точно можно прогнозировать вероятность сочетания той или иной комбинации букв/кодов

Ограничения, конечно есть:

• Разрешение фото должно быть не меньше 300x300
• Максимальное разрешение ограничено производительностью вашего компа, если использовать GPU Nvidia, то при разрешении FullHD будет распознавать около 500ms/фото, если на обычном CPU, то это будет уже 5 сек на фото.
• Большой плюс если размер найденного номерного знака на фото по вертикали имеет 64 и более точек
• Границы номера будут находиться даже при сильном повороте или даже на перевернутой фотографии, а вот распознаваться они будут только если можно сказать что номер в большей читается слева направо чем сверху вниз или снизу вверх. Эту проблему тоже можно решить, если будет смысл на это тратить процессорное время. Другими словами углы наклона ограничены читаемостью номера.
• Естественно, размытая или зашумленная фото будет распознаваться плохо.

Справедливости ради надо сказать, что основную часть по «выравниванию» текста для дальнейшего распознавания делает алгоритм перспективной трансформации из библиотеки openCV, но в тоже время достаточно нелинейной является задача определения «опорных» точек, которые подаются на вход этому алгоритму. Вот тут пришлось вспомнить многое из школьного курса геометрии :)

я имею в виду то, что он принял участие в программе и согласился с её правилами. И публикацией их нарушил.

Цитирую начальника:

Действительно благодарен серчеру за то что не слил сенсетив информацию и сообщил нам об утечке, и сожалею, что программа не предусматривает большее вознаграждение за подобную информацию.

Другими словами информация которую передал хакер не подпадает под условия «Bug Bounty Киевстара», значит и обязательств никаких по этой программе у него нет. Нельзя нарушить правила тем что не подпадает под правила. Ну в смысле хакер думал что подпадает, а начальник считает что нет.

Кроме того, весь сыр-бор тут из-за денег, а деятельность за деньги — это как раз та самая профессиональная деятельность.

Странное утверждение. Не все что делается за деньги — профессиональная деятельность.

Генераторы есть во многих языках, зачем от них отказываться?

Если речь идет о библиотеке co, то она была создана до того как async/await был добавлены в nodejs и реализовывала возможность писать код без callback hell-а.

После появления async/await необходимость в co отпала, самым популярным фреймворком, который популяризировал использование co был koajs v1.x. Новая версия koajs v2.x на использование генераторов выдает «warning» с «deprecated».

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

Человеку можно рекомендовать то что покупали другие пользователи с этими товарами. Эти выборки можно делать с помощью SQL.

Напишите хоть один пример, когда так делать лучше чем:

var a = Number(10)

?

Так делать плохо:

var a = new Number(10)

потому что

var a = new Number(10)
var b = new Number(10)
console.log(a != b)
// true

Но если не хочется полагаться на «автоматическое поведение системы», то лучше так

var a = Number(10)

Когда речь идет о малом количестве файлов и папок, то разницы не будет. Но когда файлов очень много и винт не быстрый, т.е. есть ощутимый iowait то загрузка в ОЗУ может помочь.

Простой эксперимент:
Берем папку 100 000 файлов, для того чтоб ее сгенерить используем скрипт, например такой:

#!/bin/bash

# Init variables
EXAMPLEFILE=./example.png
FILESCOUNT=100000
CACHE_DIR=/home/cache
URL="http://imagerequests"

for i in `seq 0 $FILESCOUNT`; do
    let "X = i % 100"
    let "D = i - X"
    let "L1 = D/100"

    let "X = i % 1000"
    let "D = i - X"
    let "L2 = D/1000"

    TARGET_DIR=$CACHE_DIR/$L2/$L1
....
    if [ ! -d $TARGET_DIR ]; then
       mkdir -p $TARGET_DIR
    fi
    if [ ! -f $TARGET_DIR/$i.png ]; then
       cp $EXAMPLEFILE $TARGET_DIR/$i.png
    fi
    echo "$URL/$L2/$L1/$i.png"
done

При этом на стандартном выводе формируется список URL-ов, кладем его в /etc/siedge/urls.txt.

У меня вся папка получилась окло 70M, полный размер на FS около 400M

Примонтировал так

mount -t tmpfs -o size=1G,noatime,async tmpfs /home/ram

Запускаем sedge:

siege -c 1000 -t 10s -i -b

Для диска
Transactions: 52106 hits
Availability: 100.00 %
Elapsed time: 9.40 secs
Data transferred: 38.69 MB
Response time: 0.02 secs
Transaction rate: 5543.19 trans/sec
Throughput: 4.12 MB/sec
Concurrency: 134.60
Successful transactions: 52341
Failed transactions: 0
Longest transaction: 2.10
Shortest transaction: 0.00


Для RAM:
Transactions: 102892 hits
Availability: 100.00 %
Elapsed time: 9.04 secs
Data transferred: 76.22 MB
Response time: 0.00 secs
Transaction rate: 11381.86 trans/sec
Throughput: 8.43 MB/sec
Concurrency: 15.30
Successful transactions: 103132
Failed transactions: 0
Longest transaction: 0.32
Shortest transaction: 0.00


Понятно, что когда все файлы загрузятся в RAM из fs то время сравниться. Ну а если файлов будет пару миллионов, то с файловой системы все может и не взлететь, а рам задосить невозможно.

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

Понятно, что стоимость потребительских SSD ниже, как и их скорость, тоже ниже, однако со стороны бизнеса должны быть требования по скорости загрузки файлов и т.п., действительно ли они не выполнялись на 8xINTEL SSDSC2BB480G4 480G

Не выполнялись, по нескольким причинам:
1. Это старый сервер, который постепенно апгрейдили, на разных этапах пробовали разные конфигурации. Вначале было 4 SSD в stripped raid без RAID-контроллера. Это работает плохо, так как RAID-контроллер с батарейкой это снижение рисков развала RAID-масива (с такой проблемой столнулись).
2. Потом собрали то что есть но пожалели денег на быстрий RAID-контроллер и, возможно, небольшие iops-ы отчасти и его рук дело.
3. Нету аппаратного шифрования, это тоже проблема, держать прожорливые процы только чтоб шифровать трафик — неоптимально и если дать на них большую нагрузку то и процы начнут тормозить и iowait поползет вверх. (Процессоры можно озадачить более полезной нагрузкой, например, предпорезкой разных форматов фоток)
4. Возможно можно было бы компенсировать добавлением RAM-а, так там уже нету свободных слотов.
5. Есть еще одна неприятная особенность, система начинает тормозить не линейно, например нагрузка возросла на 5% а скорость отдачи снизилась на 50% (я кончно, утрирую, но суть, я надеюсь, понятна)
6. На сервере всегда должен быть резерв, на случай выхода из строя друго-го кеш-сервера.

Или выполнялись, но было бабло? :)

Очень быстро никогда не бывает, если у Вас iowai не 0 значит диск иногда тормозит.

Я бы еще вспомнил что контроллер ARC-1882 сам по себе является узким местом, он малопроизводительный для такой конфигурации, превращает в ssd с 100к iops каждая в RAID с масксимум 60к iops всего, да и латенси его довольно велик. Еще бы через адаптек 6805 ssd подключили.

Да тут спору нет, почему ставили Araca я уже писал, просто NVMe дискам не нужен RAID-контроллер и это прекрасно!

Там javascript тормозил :)

Telegram это островок свободы, неподконтрольный спец. службам. Посмотите в какое посмешище превлатилась эта кампания по блокировке всеми любимого месенджера. Мне кажется, сила каждого пользоваться telegram заключается в том, чтоб научиться пользоваться тем что Вам нравиться несмотря на чужое желание Вас ограничить.

Вы сами то пример смотрели? Вечный цикл в котором инициируются «асинхронные» запросы и тут же постоянно идет проверка синхронным кодом или они все выполнились. Тут нету самого главного, события о том что что-то произошло. Надо постоянно синхронно что-то опрашивать. Конечно же это лучше чем ничего, но до полноценной асинхронной модели программирования еще очень далеко.
Это все равно что на машине кузов мерседеса с двигателем от таврии.

Вы уверены, что на php нельзя сделать асинхронный запрос к базе / кэшу? нельзя сделать банальный http-запрос (либо каким либо еще протоколом, благо сокеты доступны и для всего более менее стандартного есть реализации) и не дожидаться его исполнения?

Напришите пример кода на PHP ассинхронного запроса к MySQL