Task01 Леонид Тернопол СПбГУ#6
Open
firelion9 wants to merge 1 commit intoPhotogrammetryCourse:task01from
Open
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.
Перечислите идеи и коротко обозначьте мысли которые у вас возникали по мере выполнения задания, в частности попробуйте ответить на вопросы:
Почему SIFT менее точно угадывает средний угол отклонения? изменяется ли ситуация если выкрутить параметр ORIENTATION_VOTES_PEAK_RATIO=0.999? почему?
Вычисление угла основаны на дискретизации направлений градиентов с последующей интерполяцией наиболее ярко выраженного направления. Понятно, что тут угол считается не очень точно. ORIENTATION_VOTES_PEAK_RATIO=0.999 ситуация будет чуть лучше, потому что шумные точки с несколькими локальными максимумами, по которым может быть сложно определить правильное отклонение, будут давать меньший вклад в среднее
Как надежно замерить во сколько раз распараллеливание через OpenMP ускоряет ваш вариант SIFT? Попробуйте сделать это на вашем компьютере, какое ускорение относительно однопоточной версии оказалось? Сколько у вашего процессора ядер и сколько потоков?
Нужно замерить время выполнения интересующего нас куска кода в 2 вариантах (с openmp и без). Каждый замер нужно провести многократно и взять минимальное время. Входная картинка должна быть достаточно большой, чтобы накладные расходы на openmp не перевешивали ускорение от него.
С расставленными за пару минут прагмами omp (без оптимизаций с локальными кешами, omp critical на всех push_back) получилось ускорить полный цикл обработки на 20% (5.2 c -> 4.1 c) на картинках, что были в репозитории (8 ядер, 16 потоков). Вероятно omp можно применить более разумно
Правда ли можно строить каждый слой в Gaussian пирамиде из самого первого слоя этой октавы? Или нужно обязательно делать так как предложено в статье - дополняя размытие предыдущего слоя этой октавы? Совпадают ли пирамиды визуально?
Правда, и визуально они даже будут совпадать. Вариант из статьи работает быстрее за счёт меньших радиусов размытия, но накапливает чуть большую погрешность
Какие ожидания от картинок в Gaussian пирамиде можно придумать? Как проверить что работает корректно? С какой другой картинкой предыдущей октавы должна визуально совпадать конкретная картинка конкретной октавы? Как их визуально сравнить, ведь они разного размера?
Должно получаться размытие при увеличении слоя и октавы. В рамках 1 октавы идёт размытие по Гауссу и на слое s (в терминах реализации), то есть на 3 с конца, sigma=2. Это примерно соответствует даунсемплингу в 2 раза (по каждой стороне), что соответствует первому слою следующей октавы (перед сравнением мы обратно апскейлим картинку). Следующие 2 картинки тоже будут примерно совпадать со 2 и 3 из следующей октавы
Почему в октаве Gaussian пирамиды s+3 картинки а не s+2 например?
Потому что мы хотим посчитать попарные разницы между соседними слоями (+1) и получить s слоёв, у которых будут оба соседа (+2). 1+2 = 3 != 2
Какие ожидания от картинок в DoG пирамиде можно придумать?
В первых октавах там должны быть контуры. Далее пятна в местах, где были объекты
Почему порог контрастности должен уменьшаться при увеличении числа слоев в октаве?
Потому что суммарное изменение контрастности от первого слоя к s-му -- константа (по модулю погрешностей). Соответственно при увеличении количества слоёв пропорционально уменьшается разница между соседними
Какая строка ответственна за определение сигмы (или что почти то же самое - радиуса) которая задает окрестность по которой определяется ориентация ключевой точки?
float kp_sigma_octave = (float)(sigma0 * std::pow(2.0, (double)layer / s));За какой строки вашего кода дескриптор инвариантен к повороту картинки?
float angle_invariant = angle - kp_angle_rad;-- углы считаются в локальной системе координат, повёрнутой в сторону (одного из) наиболее частых градиентов в окрестности ключевой точкиВсегда ли мы получаем ровно столько точек сколько запросили в параметре nfeatures? Как подкрутить алгоритм, чтобы всегда выдавать ровно запрошенное количество точек (когда это в принципе возможно) но не сильно просесть в производительности?
Может получиться меньше, если мы не найдём достаточно хороших точек на картинке. Чтобы адаптироваться к такой ситуации, можно динамически подкручивать пороги обнаружения точек. Например, не отбрасывать недостаточно зацепистые точки сразу, а хранить их в куче размера nfeatures и выбрасывать, когда появляется много более зацепистых (замедление вставки в (log nfeatures) раз, но потом не нужно будет делать частичную сортировку)
Github Actions CI