Мы делаем ПО для систем видеонаблюдения с функциями видеоанализа, и это — коробочный продукт. А коробочный продукт в одинаковом виде предоставляется сразу многим пользователям и используется всеми ими таким, какой он есть.

Имеет ли значение, делаем мы универсальный продукт для многих или разрабатываем индивидуально для конкретного пользователя? Когда речь идет о видеоанализе, это имеет просто принципиальное значение.

Давайте разбираться

Возьмем две компании: N и M. Пусть компания N разрабатывает «индивидуальный» программный продукт, а M – коробочный. Компания N разрабатывает продукт по заказу, для использования в одном конкретном месте. И делает так, чтобы все работало в условиях, для которых продукт разрабатывается. А компания M, которая делает коробочный продукт, должна разрабатывать так, чтобы он обеспечивал целевые параметры (по точности, например) у самых разных пользователей в самых разных условиях.

Для коробочного программного продукта видеоанализа справедливы два фактора:

1. Самые разные условия применимости;
2. Невозможность каждый раз у нового пользователя регулировать и подстраивать алгоритм.

Соответственно, и при его разработке необходимо удовлетворить два условия:

1. Алгоритм должен работать в автоматическом режиме. То есть без участия человека, который может что-то «подкрутить» и настроить в конкретном месте.
2. Условия могут быть самыми разными. И при всех параметрах продукт должен обеспечивать целевые значения, например, по точности.

А применительно к условиям съемки и видеоанализу спектр возможных параметров очень широк: это резкость, контрастность, цветовая насыщенность, уровень оптического шума, уровень структуры и пространственно-временное распределение шумового движения, угол установки камеры, параметры цветопередачи, сложность фона (сцены) и т.д.

Что пишут в умных книгах?

Если взять научные статьи, то в них можно увидеть, например, вот такие иллюстрации для детектирования движущегося объекта:



Посмотрите! Это же просто что-то стерильное: вот две картинки — вот движущийся объект. И, конечно, в такой ситуации мы всё прекрасно продетектируем.
Но это нереальные, идеальные условия.

Если все в тех же научных работах взять более приближенные к реальности иллюстрации, вот что они из себя представляют:



Это уже кадр с настоящей камеры. Но условия по-прежнему очень хорошие.

А как на самом деле?

Но с чем мы сталкиваемся по факту? Мы сталкиваемся с тем, что наши алгоритмы должны работать вот в таких условиях:



и в таких



и даже в таких



Это реальность применения алгоритмов видеоанализа в коробочном продукте: условия совершенно разные. К тому же, они могут меняться с течением времени. Но тем не менее каждый алгоритм должен хорошо работать во всех таких условиях и обеспечивать целевые показатели по точности.

И поэтому при разработке коробочного продукта надо искать специальный нетривиальный подход.

И это еще не все

Есть еще одна очень сложная задача в нашей специфике разработки.
Когда разрабатывается какой-то алгоритм, для него создается выборка кадров или видео: готовятся видеоролики, на которых отслеживается работа. Разработчики стараются подготовить очень разные ролики, с очень разными условиями съемки и параметрами. Но по факту оказывается, что эти видеоролики так или иначе попадают в какую-то достаточно узкую область входных условий.



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

Но еще большая проблема состоит в том, что на самом деле это «пространство условий» не двумерное как на графике выше. Оно многомерное. И все параметры могут меняться в самых широких пределах. А ввиду того, что мы рассматриваем коробочный продукт, его алгоритмы должны корректно и точно работать во всех границах.



Итак, мы получаем огромное многомерное пространство условий и параметров. И наша задача при разработке алгоритма разместить входные точки более-менее равномерно в этом пространстве и, не упустить никакую область.

Как это сделать?

Универсального метода нет. Единственное, что здесь можно порекомендовать – идти и брать в выборку реальные видеоролики реальных камер с реальных объектов. И пытаться сделать так, чтобы ими максимально покрывалось все пространство параметров.
При этом алгоритм все равно так или иначе будет подстраиваться под конкретные условия этих входных роликов выборки.

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

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

Как вырваться из этой нескончаемой череды подстроек?

1 способ — все время тестировать на новых видеороликах.

Он очень действенный, но очень трудоемкий. Поверьте, собирать с реальных объектов ролики для входной выборки и тестов очень сложно (в том числе потому что речь идет о видеосистемах безопасности). А ввиду того, что иногда тестирование алгоритма может проходить по несколько раз в день, надо запастись каким-то нереальным количеством видео.
Такой подход повышает шансы успеха, снижает риски подстройки, но является очень ресурсоемким.

2 способ — делать так, чтобы разработчики не видели, почему не срабатывает при тестах

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

Но в таком случае разработчики должны дорабатывать алгоритм, не понимая, почему у них что-то не работает…

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

И это та реальность, в которой мы разрабатываем.

Но и это еще не все

В разработке есть понятие деградации: когда разработчик что-то улучшает в алгоритме, в то же время в нем что-то ухудшается. Это нормальное, реальное явление. Поэтому любое изменение алгоритма должно проходить тест на внесение деградации в иные параметры.

Это требует безумного количества усилий. Можно делать это вручную и потратить много времени и сил, а можно автоматизировать процесс. Но это вновь запускает проблему подстройки: когда автоматизируешь, все подстраиваешь под какой-то конечный набор роликов. «Автоматически» — это когда все размечено: сказано, что на этом ролике такие условия и параметры, а на этом такие.
И вновь нужно искать баланс при тестировании деградации…

Загнать в рамки не себя, а пользователя?

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

Кажется, есть один простой выход из этой ситуации (забегая вперед, скажем, что никакой он не простой, и никакой это не выход:)).

Когда есть широкий спектр параметров, можно четко сформулировать пользователю условия, при которых данный алгоритм должен работать. У любой программы, модуля или алгоритма видеоанализа есть рекомендуемые условия работы, при которых они выдают заявленную точность.

Однако, при таком подходе нужно понимать вот что:

1. Можно рассказывать пользователям, что они должны обеспечить те или иные параметры, но часто в реалиях соблюсти все параметры просто невозможно. А когда речь идет о коробочном продукте, он должен работать в реальных условиях…

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

Например, контрастность можно описать (хотя и контрастность для всего изображения может быть одной, а в конкретной области, где ты ведется анализ- другой). Но как формализовать, например, сложность фона? Как сказать пользователю, какие условия он должны соблюсти в отношении таких плохо оцифровываемых вещей?

«Не так страшен черт...»

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

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