Task02 Михаил Митрофанов ИТМО#32
Conversation
Вообще, отличил бы (даже если есть всего 10% инлаеров, то они все равно подчиняются одной гомографии, и почти всегда победят любую шумную гипотезу) |
гомография работает в однородных координатах и ее можно спокойно умножать на ненулевую константу и ничего не изменится. но вот что если элемент H33 нулевой? |
|
Здравствуйте, все хорошо, но нет ответов на вопросы 4, 5 |
Будет проблема с тем, что при нормировке значения матрицы просто взорвутся? Можно брать H33 как норму матрицы. |
Извиняюсь, я их почему-то просто проигнорировал. Сейчас добавил ответы. Прошу не давать штраф за дедлайн |
не очень понял, матрица же как раз взорвется, если взять за норму нулевой H33 |
Я бред какой то написал просто) Мы будем нормировать матрицу по H33, если он не близко к нулю, получая 1. Иначе можно делить на евклидову норму матрицы, чтобы избежать взрыва |
а как это поможет в решении системы методом гаусса? |
2 participants
Перечислите идеи и коротко обозначьте мысли которые у вас возникали по мере выполнения задания, в частности попробуйте ответить на вопросы:
Потому что RANSAC нуждается в том, чтобы настоящие матчи преобладают над шумными. Если бы мы не фильтровали, то рансак не отличил бы настоящую гомографию от фейковой, потому что шумные матчи ей не подчиняются.
Cluster filtering, как я заметил, вообще не справляется с сильным изменением скейла. Видимо проблема в том, что кластеры матчей на большем изображении сжимаются в меньшее количество на другом и фильтр считает их ложными.
Ratio показался мне более стабильным, но я думаю он может сломаться на каких нибудь изображениях с повторяющимся паттерном, типо кирпичной стены с одинаковыми кирпичами. Он может просто отбросить почти все хорошие матчи, потому что у них наверняка будут похожие.
Мы перестанем учитывать масштаб картинок друг относительно друга? Решить можно будет нормированием большей матрицы, чтобы их H33 стали равны.
Во первых, наверное, ошибка будет накапливаться, особенно если есть много каких то поверхностей с повторяющейся геометрией. Мы же считаем гомографию для каждых двух картинок отдельно. Еще, если посмотреть, что будет, если сделать корнем 3 картинку, то можно увидеть, что из за неидеального угла обзора камеры картинка сверху начинает прилично вытягиваться и сжиматься. Думаю, что при больших панорамах этот эффект будет усиливаться, накапливая деформацию изображения.
Ну кажется можно просто попробовать поматчить каждую картинку с каждой, например, нашим матчером, и сделать ребрами графа пары картинок с каким то приемлемым числом матчей
Получилось
Как работает матрица гомографии не очень понятно из-за не очень хорошего понимания линала (а хотелось бы понимать), но в целом дз можно написать без этого. В этой дз, в отличие от прошлой, как будто не обязательно понимать весь код, чтобы его выполнить. Местами мне было просто лень разбираться (например, код метода гаусса), а дз не обязывает это делать (для меня это скорее минус).
С другой стороны, дебаг был очень мучительным и занял у меня несколько дней. Я не всегда вообще понимал, что от меня хочет тест из за запутанности кода. Например, очень долго пытался починить тест на scale50 и думал что проблема в кластер фильтре (он выдавал очень мало матчей (да, я не прочитал 2 вопрос и не думал о том что он сам по себе работает плохо)), чтобы потом обнаружить что надо просто поменять константу в ratio тесте на 0.05.
// Создайте PR.
// Дождитесь отработки Github Actions CI, после чего нажмите на зеленую галочку -> Details -> The build -> скопируйте весь лог тестирования.
// Откройте PR на редактирование (сверху справа три точки->Edit) и добавьте сюда скопированный лог тестирования внутри тега