Task01 Вячеслав Григорович ITMO#16
Open
HackAss2002 wants to merge 1 commit intoPhotogrammetryCourse:task01from
Open
Task01 Вячеслав Григорович ITMO#16HackAss2002 wants to merge 1 commit intoPhotogrammetryCourse:task01from
HackAss2002 wants to merge 1 commit 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.
Если у нас будет большое значение, то мы будем реже из одной точки плодить несколько с разными направлениями. Это нужно т.к. мы все же считаем приближенно, у нас есть шумы, сглаживание гистограммы, да и в целом некоторые узоры могут иметь несколько направлений. Если мы не будем добавлять эти доп точки, то просто не сможем сопоставить одну и ту же точку с 2 разных картинок где за счет погрешности по-разному выбралось доминирующее направление. Если будет маленькое значение, то получим много мусора
Получилось за счет уменьшения значения увеличить final score
Выглядит так, что у нас нет io, есть много памяти, но последовательной, т.к. что нет random access, и много вычислений, так что мы тут больше cpu bound
В buildOctaves мы можем распараллелить слои в октаве, т.к. делаем не инкрементально и зависимостей тут особо нет. Дожидаемся последнего слоя и строим следующий октав
В buildDoG, иожем распараллелить все слои и октавы
В findScaleSpaceExtrema можем распараллелиться вплоть до пикселей, но тут будет нужно синхронизироваться в записи точек
В computeOrientations можем распараллелить по ключевым точкам. Вроде тут тоже синхронизация только при записи результата
В computeDescriptors, аналогично распараллеим по ключевым точкам, но тут надо синхронизироваться постоянно на запись точек и дескрипторов, поэтому стоит делать батчинг для более редкой синхронизации
В selectTopKeypoints, вроде особо не распараллелить
Будто бы большую часть кода можно ускорить в количество ядер раз, но надо уже смотреть соотношение операций по времени
Но для теста нужно сделать скрипт с множеством замеров на одних и тех же данных, которые уже загружены и готовы
Пробовать руки не дошли
Можно с математической точки зрения и даже визуально будут совпадать, т.к. погрешность с флотами здесь относительно небольшая. Но мне от одной мысли об этом уже плохо, уж сильно навозился за жизнь проблемами с точностью даблов, а вы тут хотите инкрементально менять флоты, страшно
На первых октавах и на первых слоях картинка не сильно размыты. Чем дальше там больше мыла. В конце получим среднюю яркость изображения. Последний слой октавы равен первому слоя следующей октавы с учетом ресайза
Мы хотим s искать фичи на s слоях DoG, поэтому нам надо +2, чтобы искать экстремумы на предыдущем и следующем для крайних слоев и еще +1 при построении DoG, т.к. здесь один слой это разность 2 подряд Гауссов, то есть из 2 слоев получаем 1 разницу
Визуально на первых DoG мы должны отчетливо видеть мелкие детали, трава, нитки и т.д., которые очень быстро начнет исчезать с ростом октавы и слоя. На более поздних уже начнут исчезать большие объекты
Чем больше у нас слоев, тем меньше у нас разница между ними и мы будем выкидывать то, что выкидывать не стоило
Нет, т.к. количество точек может буть меньше. В картинке может не быть столько точек сколько нам надо. Точки близкие к границам могут выкидываться, т.к. их зона выходит за границы картинки
Может предварительно выкинуть точки selectTopKeypoints, а потом понять, что по предудщему пункту уже не хватает
Чтобы не умереть при вычислении можем найти все экстремумы, посортить их, но не выкидывать. И начать по очереди(или батчами) их прогонять через весь последующий пайплайн пока не наберем нужное количество точек
Github Actions CI