Task01 Дмитрий Оводок#158
Closed
dmitrio95 wants to merge 1 commit into
Closed
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.
Решение первой задачи (решение второй — в пулл-реквесте #157).
Перечислите идеи и коротко обозначьте мысли которые у вас возникали по мере выполнения задания, в частности попробуйте ответить на вопросы:
1) Почему SIFT менее точно угадывает средний угол отклонения? изменяется ли ситуация если выкрутить параметр ORIENTATION_VOTES_PEAK_RATIO=0.999? почему?
В целом, есть как минимум два возможных источника проблем с вычислением угла отклонения.
Во-первых сам алгоритм оценки угла у ключевой точки подразумевает разбиение значений углов на несколько бинов, что уже приводит к погрешности угла. В конце производится интерполяция, призванная снизить погрешность оценки угла, но всё равно вряд ли она может полностью компенсировать погрешность от разбиения.
Во-вторых, каждая контрольная точка может присутствовать в наборе несколько раз с разными ориентациями. Если дескриптор данной точки не сильно меняется от вращения, это может приводить к сопоставлению неправильно повёрнутого варианта точки с соответствующей точкой на второй картинке. Увеличение порога для отбрасывания повёрнутых вариантов ключевой точки действительно уменьшает влияние этой проблемы, поскольку второго варианта ориентации в таких случаях просто не возникает. Но это приводит и к меньшему количеству сопоставлений между картинками. Угол поворота картинки всё равно лучше оценивать по итоговой гомографии, полученной из множества сопоставлений ключевых точек, поэтому угол поворота каждой отдельной ключевой точки большой роли в этом случае не играет.
2) Как надежно замерить во сколько раз распараллеливание через OpenMP ускоряет ваш вариант SIFT? Попробуйте сделать это на вашем компьютере, какое ускорение относительно однопоточной версии оказалось? Сколько у вашего процессора ядер и сколько потоков?
Здесь не вполне ясно: распараллеливание применяется к коду теста, а не самого SIFT. Следует ли измерять эффект для этого кода или следует внедрить OpenMP внутрь реализации SIFT и измерить полученный эффект?
В любом случае, процедура кажется вполне понятной: нужно убедиться, что сборка собрана с оптимизациями компилятора (желательно с
CMAKE_BUILD_TYPE=Release), запустить варианты с нужными#pragma ompи без них и измерить либо время работы либо всей процедуры SIFT, либо конкретных распараллеленных участков кода.3) Правда ли можно строить каждый слой в Gaussian пирамиде из самого первого слоя этой октавы? Или нужно обязательно делать так как предложено в статье - дополняя размытие предыдущего слоя этой октавы? Совпадают ли пирамиды визуально?
Если я правильно понимаю, дополнение размытия — лишь оптимизация, работающая за счёт уменьшения размера ядра свёртки, требуемого для каждого следующего размытия. Визуально оба варианта я не сравнивал, но результат, за исключением небольших погрешностей, должен быть аналогичный.
4) Какие ожидания от картинок в Gaussian пирамиде можно придумать? Как проверить что работает корректно? С какой другой картинкой предыдущей октавы должна визуально совпадать конкретная картинка конкретной октавы? Как их визуально сравнить, ведь они разного размера?
Картинка номер i данной октавы должна совпадать с картинкой номер s+i предыдущей октавы. Визуально сравнить можно, например, увеличив в два раза размер меньшей картинки, что и делает в задании функция
phg::SIFT::savePyramid.5) Почему в октаве Gaussian пирамиды s+3 картинки а не s+2 например?
Судя по применению в коде, s — целевое количество слоёв в октаве, доступных в DoG для оценки наличия локального максимума по значению пикселя в пирамиде. Для оценки наличия локального максимума у каждой из s картинок в DoG должно быть две соседние картинки. Следовательно, в октаву нужно добавить две крайние картинки, то есть в DoG в итоге должно быть s+2 картинки. Для получения s+2 картинок DoG нужно на одну размытую картинку больше, то есть s+3.
6) Какие ожидания от картинок в DoG пирамиде можно придумать?
Не вполне ясно, что означает этот вопрос, но закон с совпадением i-й картинки с (s+i)-й для предыдущей октавы вполне должен выполняться и в случае с DoG.
7) Почему порог контрастности должен уменьшаться при увеличении числа слоев в октаве?
Потому что порог применяется к разности изображений, пусть и размытых. Чем больше слоёв, тем меньше отличаются картинки между соседними слоями, и тем меньше будет разность пикселей. Следовательно, действительно кажется разумным масштабировать порог в зависимости от количества слоёв.
8) Какая строка ответственна за определение сигмы (или что почти то же самое - радиуса) которая задает окрестность по которой определяется ориентация ключевой точки?
За это ответствен следующий блок кода. Последняя его строка — и есть вычисление окончательного значения радиуса, по которому вычисляется ориентация ключевой точки.
PhotogrammetryTasks2026/src/phg/sift/sift.cpp
Lines 414 to 417 in 2fdd286
9) За какой строки вашего кода дескриптор инвариантен к повороту картинки?
Из-за этой:
PhotogrammetryTasks2026/src/phg/sift/sift.cpp
Lines 660 to 661 in 2fdd286
Github Actions CI