Я бы добавил, что когда встает задача ускорения программы, дополнительно (и часто до начала сравнительно низкоуровневых оптимизаций) стоит подумать об оптимизации алгоритма. Например, медианную фильтрацию в окне асимптотически можно сделать более эффективно (за где - число пикселей, - размер окна) с помощью двух куч. Разумеется, скрытая в O-нотации константа важна, и может оказаться, что реализация "классического" алгоритма для окна 5x5 шустрее. Но помнить про чисто алгоритмические оптимизации тоже важно
Минимакс совсем не страшен, просто попробуйте реализовать. Цель этого метода — выбрать последовательность ходов бота, которая при самых сильных ходах игрока-соперника приведет к лучшему для бота результату. Достигается эта цель путем «заглядывания в будущее» на некоторое количество ходов вперед и оценки состояния игровой доски в каждом из вариантов будущего. Реализовать минимакс можно рекурсивной функцией, в которой вы перебираете все варианты хода из некоторого набора для бота (копируете состояние поля, делаете ход) и, рекурсивно спускаясь, вызываете эту же функцию, но перебираете ходы игрока. Продолжаете рекурсию… Остается только вовремя остановиться, оценить, используя ваши эвристики, все позиции на нижнем уровне рекурсии и выбрать ход, который привел к наилучшей для бота позиции при любых ходах игрока.
Представляется, что в большинстве сценариев использования было бы здорово на выходе получать ортотрансформированные изображения. В этом случае логичнее использовать ортотрансформированные опорные растровые данные (если нет доступа к Google Maps, то хотя бы снимки от Landsat-8) и проецировать кадры в систему координат опорного изображения. Да, на разновременных снимках связующие точки искать сложнее, но ведь для привязки снимков к опоре точек нужно не так много. А потом уже выполнять межкадровую сшивку.
Ни один детектор блобов / углов на практике не гарантирует, что N характерных объектов с максимальными весами одного снимка предмета и N аналогично взятых объектов второго снимка того же предмета (с измененными параметрами съемки / предмета) будут являться одноименными. Поэтому обычно стремятся обеспечить избыточность координатных пар возможно одноименных объектов и далее найти истинно одноименные статистическими методами и (или) геометрическими методами с привлечением модели съемки
«Стоит отметить, что std::vector является намного более эффективной специализацией» — очень спорное утверждение. Требует меньше памяти — да. Но скорость доступа меньше, чем, например, у vector за счет объекта-провайдера, возвращаемого operator[].
Я бы добавил, что когда встает задача ускорения программы, дополнительно (и часто до начала сравнительно низкоуровневых оптимизаций) стоит подумать об оптимизации алгоритма. Например, медианную фильтрацию в окне асимптотически можно сделать более эффективно (за
где 
- число пикселей, 
- размер окна) с помощью двух куч. Разумеется, скрытая в O-нотации константа важна, и может оказаться, что реализация "классического" алгоритма для окна 5x5 шустрее. Но помнить про чисто алгоритмические оптимизации тоже важно
Не могу не оставить здесь ссылку на miniaicup 3. Посмотрите, возможно заинтересует.
Это верно для состоянии бета-версии (и организаторы явно указывали факт возможных изменений). Теперь правила стабильны, самое время начать.