Соревнования Kaggle привлекают тысячи энтузиастов науки о данных и машинного обучения, предоставляя доступ к различным наборам данных и инфраструктуре с наличием GPU и дискуссионными форумами для обмена идеями; это очень важно для практиков, ищущих отправную точку.

Здесь, в XmartLabs, мы всегда ищем способы внести свой вклад в решение реальных проблем, которые действительно влияют на людей. Kaggle — отличный пример этого, потому что он предоставляет организациям платформу для представления своих проблем, чтобы подкованные технические специалисты могли их решить.

Для этого соревнования НФЛ хотела найти решение критической проблемы, которая у них есть: Здоровье и безопасность игрока. Это не первый раз, когда они сотрудничают с Kaggle; они намеревались определить удары шлема в предыдущем соревновании. На этот раз они хотели определить, какой шлем принадлежит каждому игроку, и отслеживать их столкновения во время матча. В настоящее время отслеживание выполняется вручную, но автоматизированный алгоритм значительно сократит время, необходимое для этого вручную, высвободив больше ресурсов для проведения сложных исследований о том, как обеспечить безопасность игроков на поле. В этом сообщении в блоге НФЛ делает заявление о важности этого соревнования.

Соревнование

Набор данных имеет два источника информации: видео и информацию об отслеживании. Цель состоит в том, чтобы сопоставить обнаруженные шлемы в каждом видеокадре с меткой соответствующего игрока, который идентифицируется по номеру футболки и тому, принадлежит ли он к домашней или гостевой команде; некоторые примеры этикеток плееров: «H67» или «V9».

Наборы обучающих видео состоят из 60 коротких воспроизведений (около 10 секунд видео с частотой 60 кадров в секунду). Каждая игра снимается с двух синхронизированных камер, одна из которых находится в конечной зоне, а другая — у боковой линии, что в сумме составляет 120 видео в наборе обучающих данных.

Информация об отслеживании поступает с устройства, расположенного в наплечнике игрока. Он дает относительное положение каждого игрока на поле с другой информацией о движении игрока с частотой 10 Гц. Отслеживание имеет позиции «x» и «y», описанные на изображении ниже.

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

Еще одним файлом, предоставленным в начале соревнований, было расположение шлемов в заданном кадре, предсказанное базовой моделью. Эти предсказания не идеальны; причина их предоставления состоит в том, чтобы предоставить участникам отправную точку независимо от обнаружения шлемов, чтобы сосредоточиться на реальной проблеме. Учебные изображения даны для того, чтобы вы могли обучить свой собственный детектор шлемов, и хотя мы не использовали этот подход, некоторые команды, набравшие наибольшее количество очков, сделали это. На эту тему идет интересная дискуссия, потому что участники, набравшие наибольшее количество очков, попробовали то же решение, но с базовым детектором шлема и обнаружили снижение результата на 10%.

Наше решение

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

1. Сопоставление 2D:

Центральная часть этой проблемы — отображение положения шлема в заданном кадре с координатами отслеживания. Поскольку оба источника информации находятся в двумерном пространстве, отображение должно быть выполнено соответствующим образом; то, что мы называем «2D Matching». Как бы просто для человека ни было сопоставить два облака точек (с разумным сходством), существует несколько способов сделать это автоматически на компьютере. Различные алгоритмы пытались решить эту проблему оптимизации, где оптимизируемое значение — это расстояние между совпавшими парами.

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

При передаче двух нормализованных облаков точек алгоритм может вернуть соответствие между этими точками облака. Есть некоторые проблемы; например, когда оба набора имеют 22 точки, алгоритм работает очень хорошо, но когда в видео есть кадр с меньшим количеством шлемов, результаты могут иметь некоторые ошибки. Из-за этого мы решили выполнять 2D-сопоставление только тогда, когда в кадре изображения 15 или более шлемов. Позже мы объясним, как распространять метки на фреймы, у которых недостаточно шлемов. Кроме того, мы не проводили сопоставление на всех кадрах, так как вариаций в последовательных кадрах практически не было.

2. Глубокая сортировка:

После сопоставления мы передаем эти промежуточные результаты в модуль DeepSORT. Используя DeepSORT, мы добавляем временную зависимость между кадрами видео. Этот алгоритм обычно используется в задачах отслеживания объектов; он пытается не отставать от шлема на протяжении всего видео, присваивая ему идентификатор. Наконец, основываясь на результатах сопоставления 2D, он ищет наиболее подходящую метку для этого шлема и назначает ее окончательной меткой.

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

3. Глубокая сортировка:

В нашем выводе deepSORT были ошибки, поэтому мы хотели придумать творческое решение. Одной из основных проблем были дублированные метки и метки «Нет» (когда этому шлему не были назначены действительные метки). Эти ошибки проявлялись не на всех кадрах, поэтому мы использовали кадры со всеми совпадающими шлемами, чтобы исправить другие. Мы решили сделать двухэтапное решение, сначала исправив простые повторяющиеся ошибки, а затем более серьезные проблемы.

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

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

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

4. Поворот изображения:

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

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

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

Вращение выполняется с помощью фиолетовой линии, а угол с зеленой — это угол поворота.

5. Полевые игроки:

Еще одна проблема, которую мы заметили и решили, — это наличие игроков/шлемов вне поля. Базовый детектор шлемов не различал эти два типа шлемов, поэтому некоторые метки были присвоены полевым игрокам. Это означало, что эти метки не были назначены правильному игроку, что привело к смещению, которое переместило все метки на другой шлем.

Чтобы решить эту проблему, мы обнаружили боковые линии, чтобы различать эти два типа шлемов. Одно отличие от поворота изображения заключается в том, что в этом случае мы искали более широкие линии, как показано на изображении.

Большинство обнаруженных шлемов являются полевыми игроками, поэтому рассмотрение всех шлемов как игроков дает точность 0,983. С нашим детектором точность была улучшена до 0,994.

6. Обнаружение угла камеры:

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

В начале каждого видео мы видели, что образования были очень узнаваемы и легко соотносились с отслеживанием. Другими словами, при правильном представлении 2D-сопоставление должно иметь высокий уровень совпадений. Таким образом, реализация занимает пять кадров, распределенных по первым 100 кадрам. В этих выбранных кадрах сопоставление 2D выполняется для каждого возможного случая; тот, у которого больше совпадений, выбирается как правильный; после этого для всех пяти кадров правильная сторона выбирается и сохраняется.

Идеи, не вошедшие в окончательное решение

По разным причинам не все, что мы пробовали, попадало в окончательное решение. Здесь мы представляем две идеи, которые этого не сделали.

Кластеризация команд — это идея разделения шлемов каждой командой. Идея заключалась в том, что алгоритм 2D-сопоставления работал лучше, если ему приходилось сопоставлять 11 шлемов с 11 метками дважды, а не 22 с 22 один раз. Нашей первой идеей было использовать цвет шлема, так как в большинстве случаев цвета очень разные. Мы запускаем тесты, пробуя три цветовых пространства: RGB, HSV и CIELAB.

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

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

Рассчитав размер и количество шлемов в кадре, мы можем получить хорошее представление о том, как происходит масштабирование:

Однако объединить эту информацию с нашим пайплайном было непросто, так как нужно было выполнить дополнительную обработку, а в то время это казалось неуместным.

Решения других конкурентов

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

Глядя на другие команды, мы можем с уверенностью сказать, что наши идеи были не так уж далеки от топовых решений. На наш взгляд, самым креативным решением оказалось то, что оказалось на первом месте (блокнот и объяснение общедоступны). На этом коде, как и на многих других, обучался нашлемный детектор. Большинство этих детекторов представляют собой архитектуры YoloV5, обученные на данных соревнований. Однако здесь используется двухэтапный детектор, при этом первая модель изменяет размеры изображений, а вторая обучается предсказывать это изображение с измененным размером.

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

  • Конвертер изображения в карту: сверточная нейронная сеть (на основе U-Net), обученная преобразовывать обнаруженные позиции шлема в пространство отслеживания.
  • Командная классификация. В другом CNN шлемы в кадре обрабатываются, а затем разделяются на две команды. Эта классификация не предсказывает, являются ли команды дома или посетителями.
  • Регистрация точек за точками. Используя Итеративные ближайшие точки, выбирается наилучшее преобразование для минимизации расстояний между обеими точками облака.
  • Трекер: с помощью трекера IoU он накапливает результаты назначения игроков по всем кадрам и повторно назначает игроков ограничивающим рамкам.
  • Ансамбль. Применяя обучение ансамблем с четырьмя моделями, окончательный прогноз зависит от нескольких мнений.

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

Заключение

Мы хотим поблагодарить организаторов Kaggle и НФЛ за это фантастическое соревнование. Хотя наше решение было среди 50 лучших, мы хотели бы проявить себя дальше. Тем не менее, мы по-прежнему весело проводили время, пробуя новые вещи и многому учась на этом пути. Kaggle — отличное место для работы над вашими навыками машинного обучения, и сообщество всегда готово протянуть руку помощи. Мы знаем, что в следующий раз у нас получится намного лучше, если мы применим то, что узнали из этого опыта участия в соревнованиях Kaggle (вы можете прочитать об этом здесь).

Техническая экспертиза для отличных продуктов.

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

Узнайте больше о наших услугах и о том, как мы можем вам помочь на xmartlabs.com.

Первоначально опубликовано на https://blog.xmartlabs.com 30 ноября 2021 г.