Task01 Евгений Новокшанов ИТМО ПОВС#14
Open
NovokshanovE wants to merge 3 commits intoPhotogrammetryCourse:task01from
Open
Task01 Евгений Новокшанов ИТМО ПОВС#14NovokshanovE wants to merge 3 commits intoPhotogrammetryCourse:task01from
NovokshanovE wants to merge 3 commits intoPhotogrammetryCourse:task01from
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1) Почему SIFT менее точно угадывает средний угол отклонения? изменяется ли ситуация если выкрутить параметр ORIENTATION_VOTES_PEAK_RATIO=0.999? почему?
Как я это понял, SIFT определяет угол по локальной гистограмме градиентов в некоторой окрестности точки. То есть он смотрит не на настоящий геометрический угол поворота картинки, а на то, какое направление градиентов оказалось самым "сильным" в этой небольшой области. Из-за этого появляется ошибка.
Мне кажется, основная причина в том, что:
Также как я понял SIFT выбирает доминирующее направление локальной структуры, а оно не всегда совпадает с реальным глобальным поворотом всей картинки, особенно если текстура асимметричная или в окрестности несколько сильных направлений.
Если поставить
ORIENTATION_VOTES_PEAK_RATIO = 0.999, ситуация может немного измениться, но не потому, что угол станет сам по себе точнее, а потому что SIFT начнёт брать почти только самый высокий пик гистограммы. При более мягком пороге могут появляться дополнительные ориентации для одной точки, если рядом есть второй достаточно сильный пик. При очень высоком пороге таких дубликатов будет меньше.Т.е. иногда это может чуть улучшить стабильность, если вторые пики были “лишними”, но я бы сказал что это скорее влияет на то, сколько альтернативных углов мы разрешаем, а не напрямую на математическую точность оценки угла поворота.
2) Как надежно замерить во сколько раз распараллеливание через OpenMP ускоряет ваш вариант SIFT? Попробуйте сделать это на вашем компьютере, какое ускорение относительно однопоточной версии оказалось? Сколько у вашего процессора ядер и сколько потоков?
Как мне кажется, надёжно это надо мерить так:
OMP_NUM_THREADS=1иOMP_NUM_THREADS=N;Не уверен, что нужно распаралеливать тесты, думаю, что достаточно добавления параллелизации на тяжлые циклы.
То есть идея такая:
OMP_NUM_THREADS=1;OMP_NUM_THREADS=<число потоков>;S = T_p/T_1
где:
На моём компьютере:
AMD Ryzen AI 9 HX 370;12;24.При подключении параллелизма получаю ускорение в 1.46x.
3) Правда ли можно строить каждый слой в Gaussian пирамиде из самого первого слоя этой октавы? Или нужно обязательно делать так как предложено в статье - дополняя размытие предыдущего слоя этой октавы? Совпадают ли пирамиды визуально?
Как я понял, так делать можно, если правильно посчитать итоговую сигму. Я у себя как раз строил слои от первого слоя октавы, и это работает.
Разница в том, что строить от предыдущего слоя обычно быстрее, потому что там нужно меньшее дополнительное размытие.
Получается так:
Если всё посчитано правильно, визуально пирамиды должны быть почти одинаковые)
4) Какие ожидания от картинок в Gaussian пирамиде можно придумать? Как проверить что работает корректно? С какой другой картинкой предыдущей октавы должна визуально совпадать конкретная картинка конкретной октавы? Как их визуально сравнить, ведь они разного размера?
Я бы ожидал, что внутри одной октавы каждая следующая картинка всё более размытая, а между октавами размер уменьшается в 2 раза.
Проверять проще всего визуально:
Базовый слой новой октавы должен быть похож на один из слоёв прошлой октавы после уменьшения в 2 раза. Если размеры разные, можно просто привести их к одному размеру и сравнить глазами.
5) Почему в октаве Gaussian пирамиды s+3 картинки а не s+2 например?
Потому что DoG строится как разность соседних Gaussian-слоёв. Если Gaussian-слоёв
N, то DoG-слоёв будетN-1.Для поиска экстремумов нужны не просто
sполезных DoG-слоёв, а ещё соседи сверху и снизу по масштабу. Поэтому нужен запас.Из-за этого и берут
s+3Gaussian-картинки, чтобы после вычитания хватило слоёв для нормальной проверки максимумов и минимумов.6) Какие ожидания от картинок в DoG пирамиде можно придумать?
Я бы ожидал, что DoG выглядит не как обычная картинка, а как карта "неровностей".
То есть:
7) Почему порог контрастности должен уменьшаться при увеличении числа слоев в октаве?
Если слоёв в октаве больше, то соседние масштабы становятся ближе друг к другу. Значит и разница между соседними Gaussian-слоями меньше.
А DoG как раз строится из этой разницы. Поэтому значения DoG тоже становятся слабее.
Если не уменьшить порог, можно случайно отсеять хорошие точки. Поэтому при увеличении числа слоёв порог логично делать меньше.
8) Какая строка ответственна за определение сигмы (или что почти то же самое - радиуса) которая задает окрестность по которой определяется ориентация ключевой точки?
По смыслу главная строка вот эта:
А уже из неё считается радиус окна:
9) За какой строки вашего кода дескриптор инвариантен к повороту картинки?
Эта строка:
float angle_invariant = angle - kp_angle_rad;Здесь угол градиента пересчитывается относительно угла самой ключевой точки. Из-за этого дескриптор уже меньше зависит от общего поворота картинки.
Github Actions CI