Task01 Дмитрий Чучин ITMO #5
Conversation
почему он уменьшает количество точек? и точно ли он не влияет на точность определения угла? если например у меня будет ключевая точка (красный центр, см. ниже) вокруг которой окрестность такова что много градиентов смотрящих вверх и много градиентов смотрящих влево - какой угол направления будет определен?
не должны быть похожи, разные частоты - разные слои DoG
хорошо что сказали :) а вот представьте что вы знаете в общих чертах алгоритм SIFT и вам подсунули чужой код, и в задании сказано что нужно найти строку где достигается инвариантность по повороту - как эту строку найти чисто технически не включая мозг? например до чего она должна быть (т.е. на каикх логических этапах она используется уж точно)? и после каких логических этапов она должна быть? все хорошо, осталось ответить на вопросы 1 и 9 |
Если я правильно понял, то низкий ORIENTATION_VOTES_PEAK_RATIO приведет к тому, что мы будем строить дополнительные дескрипторы ключевых точек для тех же координат. Разве строчка
Заметил сейчас, что в тестах берется ближайшая к эталонной ключевая точка по расстоянию в пикселях (а не по дескриптору как я сначала подумал) . То есть мы можем сматчить с одной ключевой точкой трансформированного изображения много ключевых точек с одинаковой координатой, но разным ориентациями с изначального изображения. То есть как минимум в тестах угол все-таки должен определяться точнее (сейчас перепроверил, вроде так и есть, в первый раз возможно накосячил где-то), поскольку у нас будет меньше направлений для одних и тех же координат и в следствии меньше неправильных сопоставлений. Но мне не понятно почему идейно с точки зрения алгоритма такой параметр должен что-то улучшать, у нас ведь в хорошем случае на преобразованной картинке также будет несколько дескрипторов с разными направлениями? А то что мы отсеиваем более слабые просто будет влиять на количество дескрипторов? То есть вопрос в том, если бы мы в тестах использовали и близость дескрипторов и близость по пикселям (в каком-то хорошо подобранном соотношении) как критерий для сопоставления точек, влиял бы на точность определения угла ORIENTATION_VOTES_PEAK_RATIO?
Если голос за синее и за зеленое направление будет примерно одинаковый, то даже при высоком ORIENTATION_VOTES_PEAK_RATIO мы определим две ключевые точки, насколько я понимаю. Если голоса достаточно разные, то мы определим одну ключевую точку с направлением с большим голосом
Аа, просто я интерпретировал подсказку в коде "подумайте с чем должна визуально совпадать картинка из октавы DoG? может быть с какой-то из картинок с предыдущей октавы?", как то что у разных октав мы ожидаем одинаковые пятна на каких-то слоях
Также такая строчка должна быть до того как мы прибавим силу градиента в наш итоговый вектор-дескриптор, поскольку поправка на этот угол может поменять соотношения различных компонент вектора |
да, все так
да, его увеличение "увеличивает" точность только из-за методики измерения точности и т.п., по-хорошему конечно более качественный результат достигается если делать дубликаты точки (дубликат для каждого из мажорирующих направлений - мажорирующих почти так же как самое сильное направление)
ага, все так
ага, т.е. довольно забавно что можно прокачать навык Шерлок-Холмса-Робота и находить нужные куски кода идя по логической причино-следственной цепочке, тем сам сильно наловчиться читать не только свой код, но и чужой без проблем |
|
все очень здорово, 8/8 👍 |
Перечислите идеи и коротко обозначьте мысли которые у вас возникали по мере выполнения задания, в частности попробуйте ответить на вопросы:
Потому что мы ограничены тем как именно мы считаем угол в данном алгоритме. Мы приравниваем все углы в бине и даже с учетом приближения параболой угол нельзя посчитать точно. Так, увеличение ORIENTATION_NHISTS до 72 улучшило качество определения угла во всех преобразованиях с поворотом (не всегда значительно, но местами до 10 градусов). При этом ORIENTATION_VOTES_PEAK_RATIO=0.999 уменьшит количество детектируемых ключевых точек, при этом не повлияет на точность определения угла.
4 ядра, по 2 потока. Точный замер можно было бы сделать запустив много раз каждый тест в однопоточном и многопоточном варианте замерив время, затем усреднить по тесту и сравнить на картинках с разным размером и количеством ключевых точек. Однако я не успел провести хорошее сравнение. При проверке с помощью утилиты time однопоточный код локально работал примерно 9 минут, а многопоточный - 5.
Нет, не обязательно, поскольку, как приведено в коде, есть явная формула для вычисления сигмы для размытия уже частично размытого изображения до нужного значения сигмы. Визуально пирамиды совпали
Возможно с картинкой, имеющей ту же дисперсию при фактическом применении cv::GaussianBlur. Для такого сравнения можно было бы оценить увеличение сигмы от даунскейла и размыть дополнительно большую картинку соответствующим ядром, а затем сделать уменьшение с INTER_NEAREST. (попробовать не успел)
Поскольку один слой при переходе к DoG теряется
Не знаю. Кажется у всех слоев должны быть разные дисперсии и как следствие разные пятна показывающие ключевые объекты. Разве не в этом вся суть DoG? Почему они вообще должны быть похожи у разных слоев?
Потому что в этом случае у нас уменьшается шаг между дисперсиями слоев, из-за этого ядра становятся более похожи друг на друга и отклик станет меньше.
Строчка 281: int oriRadius = (int) (ORIENTATION_WINDOW_R * (1.0 + k * (layer - 1)));
Строчка 409: orientation = (orientation + 90.0 + angle);
(догадался если честно не сам)
Github Actions CI