Skip to content

Task02 Роберт Смайт СПбГУ#31

Closed
RSMT98 wants to merge 3 commits intoPhotogrammetryCourse:task02from
RSMT98:task02
Closed

Task02 Роберт Смайт СПбГУ#31
RSMT98 wants to merge 3 commits intoPhotogrammetryCourse:task02from
RSMT98:task02

Conversation

@RSMT98
Copy link

@RSMT98 RSMT98 commented Mar 10, 2026

Перечислите идеи и коротко обозначьте мысли которые у вас возникали по мере выполнения задания, в частности попробуйте ответить на вопросы:

  1. Зачем фильтровать матчи, если потом мы запускаем устойчивый к выбросам RANSAC и отфильтровываем шумные сопоставления?

Для гомографии нужно хотя бы 4 матча.
Если доля хороших матчей равна w, то вероятность того, что случайно выбранные 4 точки будут инлаерами: w^4.
Получается, чем больше шумных матчей, тем меньше вероятность на конкретно итерации RANSAC-а получить хороший набор точек, а значит, тем больше этих самых итераций RANSAC-а понадобится.

  1. Cluster filtering довольно хорошо работает и без Ratio test. Однако, если оставить только Cluster filtering, некоторые тесты начнут падать. Почему так происходит? В каких случаях наоборот, не хватает Ratio test и необходима дополнительная фильтрация?

На большинстве картинок плохие матчи разбросаны случайно и не образуют никаких кластеров, поэтому то cluster filtering их хорошо и отсеивает.
Проблемы проявляются, когда на картинках есть близко расположенные повторяющиеся структуры. Например, дроном летали и фоткали аллею деревьев, которые расположены в один ряд на одинаковом расстоянии друг от друга и с высоты выглядят одинаково; или же сфоткали не особо текстурированную плитку, квадратики которой почти не отличаются друг от друга. Тогда если матч будет между не одними и теми же деревьями аллеи, а, например, между рядом стоящими, то такой матч будет невалиден. Но cluster filtering скажет "ну они же близко расположены, значит всё норм".
Такая "замусоренность" локальных окрестностей особенно заметно проявляется при сильном изменении масштаба, когда плотность точек и локальная структура заметно меняются. Так, тест MATCHING.Scale50 выдаёт good_clusters = 0, т.е. cluster filtering тут вообще разваливается.
Ratio test в таких случаях спасает, ибо дескрипторы похожих объектов "внезапно" похожи, и он отсеят матчи вида tree -> same tree; tree -> neighbor tree, ибо L2-норма у этих двух матчей будет достаточно похожа.
Но ratio test же наоборот геометрию вообще не видит, а проверяет только дескрипторы. Т.е. на условных листиках деревьев он будет работать хорошо, но геометрическая близость не гарантируется, и у нас запросто может листик берёзы из СПб сматчиться с листиком берёзы из Магадана.

  1. С какой проблемой можно столкнуться при приравнивании единице элемента H33 матрицы гомографии? Как ее решить?

Представьте гомографию, которая представляет собой масштаб x2 + сдвиг на (3, 3) пикселей. А теперь представьте, что к соответствующей фотке добавили какую-то мега-супер-дупер перспективу так, что теперь соответствующая гомография выглядела бы как-то так: (2, 0, 3, 0, 2, 3, 4, 4, <что-то очень маленькое/большое>). А задавая элемент H33 равным единице, после соответствующей нормировки остальные элементы этой гомографии могут взорваться.
Решается проблема нахождением гомографии с помощью SVD. Там H33 не фиксируется.

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

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

  1. Как можно автоматически построить граф для построения панорамы, чтобы на вход метод принимал только список картинок?

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

  1. Если с вашей реализацией SIFT пройти тесты не получилось, напишите (если пробовали дебажить), где, как вам кажется, проблема и как вы пробовали ее решать.

Всё получилось)

  1. Если есть, фидбек по заданию: какая часть больше всего понравилась, где-то слишком сложно/просто (что именно), где-то слишком мало ссылок и тд.

Давать всего 1 балл за реализацию A contrario RANSAC - это просто ограбление☹️
По ощущению это задачка баллов так на 5.
Может, я, конечно, сам виноват, что так глубоко полез в статью, которая была предоставлена как источник для этого доп. задания, и даже вон реализовал пару фичей оттуда.. но блин имхо как будто работа, которую нужно проделать для корректной реализации A contrario RANSAC (поизучать статью как минимум), энивей не сопоставима с реализацией Brute-force матчера на GPU, которая у меня заняла всего ~18 строк...
...но при этом баллов за A contrario RANSAC даётся столько же, сколько и за GPU матчер☹️☹️☹️
В остальном в принципе прикольное ДЗ.
Спать, правда, хочется...😴

Github Actions CI

TBD (как только OpenCL появится в CI, так сразу xd)

@simiyutin
Copy link
Contributor

Очень круто! Самое полное решение этой домашки за историю)
По поводу разбалловки - спасибо за фидбек, думаю можно больше баллов накинуть за пункт с a contrario

@simiyutin
Copy link
Contributor

simiyutin commented Mar 11, 2026

Итого, задача зачтена, 12/8 баллов 🔥

@simiyutin simiyutin closed this Mar 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants