Pull to refresh
165
0
Leonid Evdokimov @darkk

Пользователь

Send message

Частично как раз интересность в том, что освещение постоянно меняется (и будет меняться как минимум до 22 декабря), поэтому может быть плохо предсказывать "прошлое", обучаясь на данных из "будущего". По крайней мере на простой линейной модели я попадал на эту граблю.

более простые алгоритмы будут работать на ура

Ох. Спасибо, я б точно не дождался, если б прогон одного цила обучение-валидация занимал 10 минут на GPU (которого у меня нет). Простым задачам — простые решения. :)


Стоит мне, конечно, посмотреть и по этой теме какой-нибудь курс и книжку и освежить понимание топологий, т.к., кажется, тут что-то сложнее MLP. А не только кроп+параметры подбирать на валидации, сидя в обнимку с бокалом сидра и ноутом на коленке =)


Что-то я промазал тредом и написал ответ вместо комментария. Видать, сидр хороший. :)

Есть вот такой сборник jpeg-ов: http://darkk.net.ru/garbage/dataset-for-mittov.tar.torrent Kaiser сказал, что вечером может посидить.


"Всего и побольше" — мне выкладывать некуда пока.

Да, обещали развести с 11-30 до 13-30. В 11-30 и развели, но где-то в 12-40 уже начали сводить, а потом камера выключилась.

если его через 10 минут разводить будут

Обычно въезд на мост закрывают аккурат по расписанию. Польза робота только в ночной сводке.


перекрыт, но сведён (как было, когда его ремонтировали)

Об этом обычно есть оперативные данные, которые навигаторы публикуют. Вот, например, сейчас ремонтируют Тучков мост и на мосту в Яндекс.Картах нарисовано одностороннее движение:


стильно, модно, молодёжно

Так речь как раз о том, что можно обойтись простейшей линейной моделью, которая "нейронная сеть" лишь формально (один нейрон).


преобразование Хафа

Я о таком слове попросту не знал, никогда не занимался обработкой изображений, в этом и был посыл статьи — можно сделать ненулевую пользу почти не разбираясь, абсолютно "на коленке" :-)


Но да, когда прикручивал мост Александра Невского, я думал об извлечении более сложных фич, собирался начать как раз с угла наклона — но тот же способ с canny(rgb2blue(crop(raw))) успел дать пристойные результаты попросту на большем количестве данных раньше, чем я в режиме "по вечерам" успел разобраться в вопросе получше.

Спасибо за информацию, я vpiter.tv в коде для читаемости оставлял, ещё думал, почему же в вёрстке IP-адрес напрямую зашит.

Кстати, нет планов у вас робота моего забанить по какой-либо причине? :-) Я писал о нём на info at vpiter.com, но ответа там никакого не получил, и решил, «если баннер не вырезать и ссылку оставить, то, наверное, пока ок, а там видно будет».
С Дворцовым мостом всё было ровно так, как я написал, первая же попытка дала пристойный классификатор, который показывал 0.99+ по F-мере. Там выборка была не сбалансированная, собранная за рабочую неделю и у меня, если честно, она уже потерялась. :-)

С мостом Александра Невского с наскоку не получилось, там качество картинки на голову хуже. Там я составлял выборку следующим образом: захватывал видеопоток с 0:00 до 8:00, нарезал его на блоки по 5 минут, размечал блоки на UP/DOWN/MOV, где в MOV попадали два блока соответствующие началу и концу движения моста. Проще говоря, факт разводки порождал такую последовательность блоков …, down, down, down, mov, mov, up, up, up, …. После этого из всех блоков одного класса я брал ~1000 кадров за кажду ночь и превращал их в фичи.
Качество оценивал разделяя выборку по времени, первые 20 дней в train, 5 в test и 5 в валидационную выборку. По валидации настраивал кроп. Полагаю, разный кроп даёт заметно разные результаты, т.к. рядом с мостом стоит фонарь, который светит прямо в камеру, и из-за этого пороги у `canny` могут получаться бестолковые. Наверное, вместо кропа можно было точно так же пороги подбирать. Когда делал кросс-валидацию по дням, оценка качества получалась завышенной. С одной стороны это понятно (мы учимся на данных «из будущего»), с другой — не очень (чем данные «из будущего» отличаются-то). Этот процесс тоже дал F-меру 0.99+.

Блоки mov я для обучения текущей модели не использовал, а использовал их только для рисования графика «процесс разводки глазами классификатора», чтоб визуально оценить скорость реакции модели на изменение моста. По этому графику я настраивал размер «кворума». Робот отсылает сообщение в telegram только тогда, когда в последних N кадрах было больше двух третей голосов за одно из двух состояний. Этим действием я сглаживал возможный шум в момент переходного процесса — спамящий о своей неуверенности робот мне довольно быстро показался весьма неприятным.

Про датасеты. Размеченных руками у меня сейчас только 3 Gb jpeg-ов Александра Невского, с 2016-06-19 по 2016-07-24. Можно породить ещё разметку классификатором для Ал.Не. и Дворцового за последние две недели, там flv-шки и их сильно больше: 28G с Дворвоцого и 53G с Александра Невского. Есть ещё поворотная камера, которая смотрит на мост лейтенанта Шмидта (две задачи по цене одной — понять, что сейчас на камере нужный мост и понять его состояние) и Литейный, по которому машины ездят, а разводной секци не видно. Что из этого интересно?
Чтобы не тратить время на составление правил :-)
Машины должны работать. Люди должны думать.

В статье, там примерно четыре строчки кода :-) Вся содержательная часть — это преобразование картинки в вектор фич, которыми потом кормится классификатор с дефолтными параметрами. Но несложно продублировать:


def load_dvorcovy_vpiter_admiral(fname):
    feat = feature.canny(color.rgb2gray(io.imread(fname)[40:360, 110:630]), sigma=2)
    feat = transform.downscale_local_mean(feat, (20, 20))
    assert feat.shape == (16, 26)
    return feat.reshape((np.prod(feat.shape), ))
Я ни с одним из этих утверждений не спорил. Более того, именно так я и планировал решать задачу с Литейным мостом, если не получится найти более пристойного источника данных, чем следы от стоп-сигналов :)

Со следами от стоп-сигналов вот ещё какая беда есть: если машина ошибается (а я не слишком высокого мнения о своих умениях в задачах распознавания), то по контуру моста человек может перепроверить машину. По следам стоп-сигналов это сложнее.
Я хотел сказать, что Гаусс в коробке с `feature.canny`. А из-за каких свойств взяли бы именно median?
Практически это мне кажется более сложной задачей, т.к. надо смотреть на динамику изображений и анализировать, наверное, каждый кадр (а не каждый 50-ый). Если есть интерес, могу предложить неразмеченный датасет с видео Литейного моста, там как раз камера смотрит на участок дороги сбоку, а разводной секции не видно.
Гаусс лежал готовый в коробке и оказался достаточно хорош :-)
Да, в Мостотресте по телефону теоретически что-то можно узнать. По крайней мере на сайте телефон есть.
С рацией есть тонкость — если мосты не разводят из-за непогоды, то бот об этом может принять решение и сказать, «что-то мост не развели по расписанию», а в радиоэфире будет, наверное, тишина.
Про яркость у меня есть смешная картинка «Рассвет над мостом Александра Невского». Когда я разбирался с качеством камеры, которая смотрела на этот мост, я заметил, что она имеет два режима: ночной и дневной. Эти два режима хорошо видны на следующей картинке:

Я взял RGB значения цвета неба над мостом в разные моменты времени за всю ночь и нарисовал их точками на диаграмме. Хорошо видно, что цвет неба имеет разрыв — в какой-то момент он меняется скачком. Кажется, этот момент соответствует выключению городского освещения :-)
2. Если нет желания смотреть датасет, то качество на мосту Александра Невского можно посмотреть ещё в истории Telegram канала.
1. Нет, на linode живёт робот, который пишет в канал, на ноутбуке жила только часть подготовки данных. Сбор данных жил, конечно, на кусочке отдельной железки с достаточным местом на диске, но и там пришлось думать о том, чтоб весь диск не забить видеопотоком :-)
2. Плохо, но обычно видно. Если очень интерено, могу поделиться датасетом.
Синий график показывает вероятность третьего класса «мост в движении». Потом я отказался от данного класса, т.к. в интерфейсе его всё равно не существует. Мусор с камеры оказалось проще всего отслеживать по баннеру, т.к. обычно мусор связан с развалившимся видеопотоком.
По-честному ещё стоит, конечно, отслеживать, что камеру не повернули, и что она смотрит в тот же ракурс, на котором бот обучался.

Вопрос про запас и вероятность я не понял. Глюки видеокамеры обычно выражаются либо в нескольких мусорных кадрах либо в полной её недоступности.
Более сложные тесты приводят к использованию scapy Automaton, из которого у меня не получалось выжать больше нескольких тысяч PPS, дальше программа упирается в CPU, поэтому вопрос производительности вполне может стоять.
Частично ситуация улучшается при использовании BPF-фильтра: например, если тестируется UDP-сервис, то разделение ответного трафика по нескольким процессам и CPU можно проводить по src-port, но не для всех протоколов есть такая возможность.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity