Компьютерное зрение на С++. ФМЛ №239. 2021/2022

Урок 26: April Tag - этап 2: декодирование

Mon, 02 May 2022 21:03:00 +0000

Два этапа: детекция и декодирование

В статье две ключевые части:

1) Детекция тэга (попытка найти темные четырехугольники - это внешние границы)

2) Система декодирования обнаруженного тэга (в тэге можно хранить числа чтобы различать один тэг от другого)

В прошлой статье обсуждается первый этап детекции.

Сегодня же мы обсудим только второй этап - детекции, т.е. обнаружения тэгов.

Итак предполагается что мы нашли много черных четырехугольников - предполагаемых тэгов. Теперь надо для каждого из них решить две задачи:

Правда ли что это тэг?
Декодировать уникальный идентификатор этого тэга

Вытаскиваем внутреннюю часть тэга

We compute the 3×3 homography matrix that projects 2D
points in homogeneous coordinates from the tag’s coordinate
system ... to the 2D image coordinate system.

Итак раз мы знаем у тэга границы, то мы знаем его углы, находим матрицу гомографии \(H\) как делали это раньше (при сопоставлении SIFT-ключевых точек).

Но теперь у нас всего четыре “ключевые” точки - это углы тэга на картинке которые хотят перейти в новую систему координат - в углы идеального квадрата:

Теперь мы работаем с правой картинкой. Обратите внимание что там может быть не тэг а полная ерунда в случае если это ложно-положительное срабатывание.

Давайте бинаризируем наш тэг - теперь все яркие пиксели белые, а все темные пиксели - черные. Затем рассечем наш квадрат на 8 линий и 8 столбцов.

В каждой образовавшейся клетке либо \(0\) либо \(1\) - в зависимости от того каких пикселей больше - черных или белых.

Заметьте что крайние ячейки всегда должны быть заполнены нулями (это черный край помогающий нашему первому этапу - обнаружению тега).

Мы можем например считать что это не тег, если хотя бы одна из крайних ячеек не засчиталась как \(0\) (хотя должна быть равна \(0\) в случае корректного тэга).

Кодировка

Пусть у нас есть 6x6 бит (из внутренних клеток). Выпишем их в ряд - получим 36 битное число.

Теперь речь пойдет не про обработку картинок, а про то как кодировать информацию с учетом того что информация могла быть передана с ошибками (ошибками декодирования или шумом в фотографии или это может быть вызвано несовершенством алгоритма).

Более того - мы хотим понимать в случае когда полученные биты не имеют смысла и являются шумом - т.е. хотим отдать долг ложным срабатываниям обнаружения тега - и поняв что это на самом деле не тег а ошибка - проигнорировать его.

Как же тогда кодировать числа?

Lexicode - устойчивость к ошибкам

We propose the use of a modified lexicode [24]. Classical
lexicodes are parameterized by two quantities: the number
of bits n in each codeword and the minimum Hamming
distance between any two codewords d. Lexicodes can
correct ⌊(d − 1)/2⌋ bit errors and detect d/2 bit errors.
For convenience, we will denote a 36 bit encoding with a
minimum Hamming distance of 10 (for example) as a 36h10
code

Итак они предлагают из всех возможных 36 битных чисел оставить для использования только такие, что между любыми двумяи из них есть хотя бы \(d\) разных бит.

В таком случае предложенная кодировка сможет гарантировать следующие свойства:

Результат будет корректен если у нас меньше чем \((d-1)/2\) ошибок в битах
Ошибка в результате будет обнаружена если у нас меньше чем \(d/2\) ошибок в битах

Для удобства кодировку на 36 битах с \(d=10\) они называют 36h10 (буква h - от слова Hamming, т.к. число разных бит - это расстояние Хэмминга).

Lexicodes derive their name from the heuristic used to
generate valid codewords: candidate codewords are considered
in lexicographic order (from smallest to largest), adding
new codewords to the codebook when they are at least a
distance d from every codeword previously added to the
codebook. While very simple, this scheme is often very close
to optimal [25].

Как же найти подходящие нам 36 битные числа? Как составить словарь?

Предлагается жадным образом добавлять очередное число в словарь только если это слово не сломает правило про минимальное рассточние Хэмминга между словами (хотя бы \(d\) разных бит).

Устойчивость к повороту тэга

In the case of visual fiducials, the coding scheme must be
robust to rotation. In other words, it is critical that when
a tag is rotated by 90, 180, or 270 degrees, that it still
have a Hamming distance of d from every other code. The
standard lexicode generation algorithm does not guarantee
this property. However, the standard generation algorithm
can be trivially extended to support this: when testing a
new candidate codeword, we can simply ensure that all four
rotations have the required minimum Hamming distance.
The fact that the lexicode algorithm can be easily extended
to incorporate additional constraints is an advantage of our
approach.

Но обратите так же внимание что тэг может поворачиваться, мы хотим не путать из-за этого что за число нам показывают.

В таком случае жадное порождение словарика надо лишь слегка расширить - слово добавляется только если оно и 3 его слова-побратима (полученных поворотами на 90 градусов) тоже проходят проверку на минимальное Хэмминг расстояние со всеми остальными словами (включая их слова-побратимы).

Устойчивость к встречаемому в природе

Some codewords, despite satisfying the Hamming distance
constraint, are poor choices. For example, a code word
consisting of all zeros would result in a tag that looks like
a single black square. Such simple geometric patterns commonly
occur in natural scenes, resulting in false positives.
The ARTag encoding system, for example, explicitly forbids
two codes because they are too likely to occur by chance

Некоторые кодовые слова могут быть не специальным тэгом - а просто совпадением. Например тэг полностью из нулей - это просто черный квадрат, в таком случае например стол может быть ошибочно интерпретирован как такой ненадежный тэг.

Rather than identify problematic tags manually, we further 
modify the lexicode generation algorithm by rejecting
candidate codewords that result in simple geometric patterns.
Our metric is based on the number of rectangles required to
generate the tag’s 2D pattern.
For example, a solid pattern
requires just one rectangle, while a black-white-black stripe
would require two rectangles (one large black rectangle with
a smaller white rectangle drawn second). 

Чтобы автоматически оценить “простоту” или “сложность” рассматриваемого паттерна - они решают задачу “сколько прямоугольников нужно чтобы нарисовать такой тэг”.

Итого

Итого мы используем подмножество 36-битных чисел такое что между любыми двумя кодами есть большая разница - много бит выглядят по-разному. Кроме того все используемые коды выглядят достаточно сложно чтобы мы крайне мало шансов имели встретить что-то в мире случайно оказавшееся похожим на корректный тэг.

Хотя генерация словаря корректных тэгов с учетом всех описанных деталей может быть вычислительно тяжелой и медленной - это не страшно, т.к. достаточно сделать это один раз и сохранить перечень получившихся кодов в файл-словарь.

Пример сколько корректных тэгов при допустимом минимальном расстоянии Хэмминга \(d=9\) и \(d=10\) между кодами в нашем словариками:

Урок 25: April Tag - этап 1: обнаружение

Mon, 02 May 2022 21:02:00 +0000

Сайт AprilTag
Статья которую мы будем реализовывать - AprilTag: A robust and flexible visual fiducial system, Edwin Olson, 2011

Мы обсудим как решить следующую задачу - пусть мы можем нарисовать (обычно распечатать на листе бумаги или пластика) какие-то специальные картинки (тэги), возможно даже несколько - каждая из этих картинок имеет свой идентификатор (код, по сути просто уникальное число). И теперь мы хотим эти картинки быстро и надежного распознавать на фотографии. В т.ч. хотим понимать какой из тэгов где.

Можно было бы решать это через ключевые точки общего назначения (SIFT и т.п.), но они работают довольно медленно и кроме того оказывается что если разработать специализированный тэг - то он будет гораздо лучше обнаружаться и позволит надежно работать даже в сложных условиях.

Пример как выглядят AprilTag (обратите внимание что справа на тэги наложены расшифрованные идентификаторы - числа которые были декодированы из обнаруженных тэгов):

Два этапа: детекция и декодирование

Our system is composed of two major components: the tag
detector and the coding system. In this section, we describe
the detector whose job is to estimate the position of possible
tags in an image. Loosely speaking, the detector attempts to
find four-sided regions (“quads”) that have a darker interior
than their exterior. The tags themselves have black and white
borders in order to facilitate this (see Fig. 2).

Итак, в статье две ключевые части:

1) Детекция тэга (попытка найти темные четырехугольники - это внешние границы)

2) Система декодирования обнаруженного тэга (в тэге можно хранить числа чтобы различать один тэг от другого)

Сегодня мы обсудим только первый этап - детекции, т.е. обнаружения тэгов.

Не хотим пропустить тэг пусть и ценой обнаружения иллюзий

Note that the quad detector is designed to have a very
low false negative rate, and consequently has a high false
positive rate. We rely on the coding system (described in
the next section) to reduce this false positive rate to useful
levels.

Любопытное решение - детектор планировалось сделать так чтобы он максимально редко выдавал ложно-отрицательный результат (т.е. редко не обнаруживал тэг, пусть и ценой перегиба в сторону обнаружения тэга там где его нет - т.е. пусть и ценой частого ложно-положительного результата).

Но раз мы почти всегда видим тег там где он есть, и довольно часто видим тег там где его нет - как с этим работать? Как не страдать от иллюзий? Давайте просто полагаться что на второй ключевой части - системе декодирования - мы поймем что это не тег, а какая-то случайная ерунда, и просто отсечем такие ложно-положительные результаты.

Т.о. с одной стороны мы почти никогда не пропускаем тэги (редки ложно-отрицательные случаи) пусть и ценой частых ложно-положительных случаев, которые мы устраняем на следующем этапе обработки - на этапе декодирования номера тэга мы планируем понять что это не тэг а какая-то ерунда.

P.S. на тему ложно-негативных и т.п. результатов:

Бывают положительные и отрицательные результаты работы алгоритма:

Положительный (не обязательно это хорошо) - нашли тег на картинке (при этом он там может быть на самом деле, или это иллюзия)
Отрицательный (не обязательно это плохо) - не нашли тег на картинке (при этом его там может не быть на самом деле, или же есть но мы его не заметили)

А с учетом того что на самом деле на картинке - результат работы алгоритма может быть поделен на истинные и ложные (когда ошибся), вот и выходит:

Истинно-положительный - когда алгоритм нашел тэг на картинке, и это правильный ответ, нашел действительно тэг а не какую-то ерунду
Ложно-положительный - когда алгоритм думал что нашел тэг на картинке, но это неправильный ответ, а алгоритм нашел что-то (может быть) похожее на тэг, но не тэг
Истинно-отрицательный - когда алгоритм решил что на картинке нет тэга, и это правильный ответ
Ложно-отрицательный - когда алгоритм думает что на картинке нет тэга, но это не так - тэг есть, просто алгоритм его не заметил (т.е. ошибся)

3) Обнаружаем границы-отрезки

..., computes the gradient direction and magnitude at every pixel
(see Fig. 3) and agglomeratively clusters the pixels into
components with similar gradient directions and magnitudes.

Итак в целом обнаружение границ-отрезков задающих четырехугольник тэга находится через нахождение по-пиксельных градиентов и постепенного объединения их в компоненты (кластеризация) на основе похожести направления и силы градиентов.

The clustering algorithm ...: a graph is created in which
each node represents a pixel. Edges are added between
adjacent pixels with an edge weight equal to the pixels’
difference in gradient direction.

1) Итак создается граф: вершина=пиксель, ребра=смежные пиксели, длина ребра=разница в направлении градиентов смежных пикселей

Изначально каждый пиксель в своей компоненте (в своем кластере).

These edges are then sorted and
processed in terms of increasing edge weight: for each edge,
we test whether the connected components that the pixels
belong to should be joined together.

2) Все ребра сортируются и обрабатываются по возрастанию их длины, т.е. сначала обрабатываем пары пикселей с похожими градиентами.

Для очередного ребра мы делаем следующее:

2.1) Смотрим какие пиксели он соединяет, смотрим в каких двух компонентах эти пиксели состоят

2.2) Хотим решить надо ли объединить эти две компоненты связности друг с другом в одну общую компоненту связности (т.е. мы пытаемся понять - эти два набора пикселей - один и тот же связный отрезок, или два разных)

Given a component n,
we denote the range of gradient directions as D(n) and the
range of magnitudes as M(n). Put another way, D(n) and
M(n) are scalar values representing the difference between
the maximum and minimum values of the gradient direction
and magnitude respectively.

2.3) У каждой компоненты связности \(n\) есть множество пикселей которые в нее входят, у каждого пикселя есть свой градиент. Тогда у компоненты есть \(D(n)\)=диапазон направлений (\(D\)=Direction=направление) этих градиентов, \(M(n)\)=диапазон силы, т.е. длины (\(M\)=Magnitude) этих градиентов.

Given two components n and m,
we join them together if both of the conditions below are
satisfied

2.4) Итак мы объединяем две компоненты связности если после их объединения диапазон направлений градиентов и диапазон силы градиентов не сильно увеличиться у обеих компонент (поэтому справа минимум).

Не сильно увеличится - задается вторым слагаемым в приведенных выше формулах, и по сути это константа деленная на суммарное число пикселей. \(K_D=100\) (в градусах) и \(K_M=1200\) (в пикселях).

Обратите внимание - зачем нам делать дозволенное увеличение диапазонов все меньше и меньше по мере увеличения компоненты? Что будет в начале? Компоненты из одиночных пикселей - мы их объединяем если градиенты хоть сколько-то не в противоположном направлении (плюс-минус 50 градусов - дозволенная разница). Что будет в конце? Огромные компоненты там где истинные отрезки (с четким пониманием какое направление и сила градиентов, т.е. малые диапазоны), и много мелких компонент в остальных местах.

Благодаря таким формулам-критериям огромные компоненты (по сути отрзеки) не будут объединяться с мелкими компонентами (по сути шум). За исключением случая когда эти мелкие компоненты покрывают продолжение отрезка этих огромных компонент (т.е. случая когда их градиенты похожи на градиенты большой компоненты).

Т.е. чем больше у нас пикселей в компоненте - тем сильнее мы уверены что диапазон градиентов определн правильно, а значит разрешаются только объединения которые очень слабо увеличивают диапазон (отсюда деление на общее число пикселей).

This gradient-based clustering method is sensitive to noise
in the image: even modest amounts of noise will cause local
gradient directions to vary, inhibiting the growth of the components.
The solution to this problem is to low-pass filter the image
... We recommend a value of σ = 0.8.

Обратите внимание что даже малый шум может существенно влиять на направления градиентов, а наш алгоритм к такому чувствителен. Достаточно слегка поблюрить картинку чтобы это побороть.

Once the clustering operation is complete, line segments
are fit to each connected component using a traditional
least-squares procedure, weighting each point by its gradient
magnitude (see Fig. 3). We adjust each line segment so that
the dark side of the line is on its left, and the light side is
on its right. In the next phase of processing, this allows us
to enforce a winding rule around each quad.

2.5) Когда все ребра обработаны и компоненты связности определены - в каждой компоненты связности надо найти “общий отрезок-прямую”. Предлагается это сделать с помощью метода наименьших квадратов, и это стандартный хороший метод, но давайте сделаем это просто и наивно - через RANSAC.

Для удобства в следующем этапе обработки удобно фиксировать направление отрезка так чтобы “слева” от направленного отрезка была черная зона, а справа - белая. Тогда мы знаем что тэги (а они черные) огибаются против часовой стрелки:

4) Обнаружаем четырехугольники

At this point, a set of directed line segments have been
computed for an image. The next task is to find sequences
of line segments that form a 4-sided shape, i.e., a quad. The
challenge is to do this while being as robust as possible to
occlusions and noise in the line segmentations.

Итак, у нас есть компоненты связности задающие отдельно взятые отрезки на нашей картинке. Из них мы хотим собрать четырехугольники которые могли бы оказаться искомыми тэгами.

Our approach is based on a recursive depth-first search
with a depth of four: each level of the search tree adds an
edge to the quad. At depth one, we consider all line segments.
At depths two through four, we consider all of the line
segments that begin “close enough” to where the previous
line segment ended and which obey a counter-clockwise
winding order. Robustness to occlusions and segmentation
errors is handled by adjusting the “close enough” threshold:
by making the threshold large, significant gaps around the
edges can be handled. Our threshold for “close enough” is
twice the length of the line plus five additional pixels. This
is a large threshold which leads to a low false negative rate,
but also results in a high false positive rate.

Предлагается делать перебор который немного напоминает поиск в глубину (DFS) - мы хотим найти четыре отрезка, вложенно перебирая их и отсекая комбинации которые нам не подходят.

Критерий отсечения:

Вот мы выбрали первый отрезок - какой отрезок подходит на роль второго (следующего за первым)? Тот у которого начало недалеко от конца первого. Здесь нам очень помогает порядок обхода сделанный ранее, иначе мы бы не знали где у отрезка “начало” а где “конец”
Тэги темные, мы их обходим против часовой стрелки, значит у следующего отрезка направление должно заворачивать налево (относительно предыдущего)
Вот мы выбрали все четыре отрезка - надо проверить что четвертый отрезок закончился где-то недалеко от начала первого

Чем больше это самое недалеко - тем более чувствителен алгоритм обнаружения - чаще находит тэги, но и чаще находит мусор.

В статье используют удвоенную длину отрезка плюс 5 пикселей.

Обратите внимание что перебирать отрезки чье начало недалеко от конца предыдущего отрезка - можно очень быстро (используя алгоритмические структуры вроде Kd-деревьев), но для упрощения предлагается просто явно пробегать по всем отрезкам с зажатым порогом.

Кроме того вероятно из компонент связности нас интересуют только те у которых достаточно большое число пикселей.

Урок 24: многопоточность - OpenMP

Mon, 25 Apr 2022 21:02:00 +0000

Для C++ существует API позволяющее очень красиво распараллелить вычисления на многоядерную архитектуру процессора - OpenMP.

Это не единственная модель вычислений, часто удобно просто явным образом запустить отдельный поток вычислений, или явно работать с защелкой (lock), или использовать другие примитивы. Но сегодня мы обсудим один из самых популярных и часто используемых вариантов в случае когда речь идет о C++ и обработке картинок - распараллеливание обработки в цикле.

P.S. не забудьте компилировать это задание в Release.

Распараллеливание цикла

Представим что есть цикл который увеличивает каждый элемент вектора в два раза:

std::vector<int> xs = ...;

for (int i = 0; i < xs.size(); ++i) {
    xs[i] *= 2;
}

Вот такое указание скажет компилятору что мы хотим выполнить цикл в несколько потоков чтобы использовать все ядра (и виртуальные потоки) процессора.

#pragma omp parallel for // omp = OpenMP, parallel = запустить потоки, for = распределить по ним индексы этого цикла
for (int i = 0; i < xs.size(); ++i) {
    xs[i] *= 2;
}

Иначе говоря каждый индекс i для которого этот цикл должен быть выполнен - достанется для выполнения одному из потоков.

Критическая секция

Что если мы хотим суммировать все числа массива? В чем проблема такого, казалось бы, естественного решения?

long long totalSum = 0;
#pragma omp parallel for // parallel = запустить потоки, for = распределить по ним индексы этого цикла
for (int i = 0; i < xs.size(); ++i) {
    totalSum += xs[i];
}

В том что здесь происходит состояние гонки при считывании и записи текущего значения totalSum. Ведь мы одновременно делает это из разных потоков.

Как это можно исправить? Правильно, воспользовавшись lock-ом (защелкой, по сути замком на двери уборной), который будет гарантировать нам что лишь один из потоков сейчас работает с переменной totalSum.

long long totalSum = 0; // используем long long (64-битное число) чтобы при суммировании int - не переполнился результат
#pragma omp parallel for
for (int i = 0; i < xs.size(); ++i) {
    #pragma omp critical // omp = OpenMP, critical = это критическая секция кода, в нее потоки заходят по одному
    {
        totalSum += xs[i];
    }
}

Какова будет производительность (скорость работы) такого кода? Почему?

Как бы это сделать лучше?

Reduction

Очень часто хочется делать подобные операции как в прошлой функции - объединение результата между разными потоками.

Т.е. по сути хочется применить некую операцию между результатами работы всех потоков, такое преобразование называется редукция (reduction).

Причем операции бывают разные - например суммирование (или перемножение, взятие максимума, взятие минимума).

Если мы укажем что потоки должны провести редукцию над totalSum, то каждый поток сделает свою личную копию этой переменной, будет суммировать свои элементы в эту копию (по сути накапливая свою частичную сумму), и когда весь цикл будет обработан - все потоки соберутся, покажут друг другу накопленное значение этой переменной, и объединив результаты - запишут в оригинальную переменную totalSum общий результат.

long long totalSum = 0;
#pragma omp parallel for reduction(+: totalSum) // в скобочках идут параметры редукции - сначала идет операция, затем - название переменной-аккумулятора
for (int i = 0; i < xs.size(); ++i) {
    totalSum += xs[i];
}

Насколько быстро работает такой код относительно однопоточной версии и версии с critical секцией? Почему?

Какие еще операции ложаться на эту парадигму? Какое свойство от них требуется? Ложиться ли например на эту идею операция вычитания? А взятие наибольшего общего делителя?

Самописный Reduction

Что нужно чтобы суметь написать редукцию самостоятельно (просто из любопытства и чтобы научиться писать более сложные вещи)?

1) Запустить каждый поток

2) В каждом потоке завести аккумулятор для частичной суммы (его личная копилка)

3) Пройтись по циклу и в каждом потоке добавлять элементы в свою переменную

4) Просуммировать все частичные суммы в общую переменную

long long totalSum = 0;
int threadsN = 0;
#pragma omp parallel // ЗДЕСЬ НЕТ for, но есть parallel = говорим что эту секцию хочется запустить для каждого потока процессора
{
    int threadId = -1;
    #pragma omp critical // в критической секции рассчитаемся по номерам потоков и выведем в консоль что такой-то поток был запущен
    {    
        threadId = threadsN;
        std::cout << "Thread #" << threadId << " started..." << std::endl;
        ++threadsN;
    }
    long long threadSum = 0;
    #pragma omp for // ЗДЕСЬ НЕТ parallel, т.к. это ключевое слово говорит "запускай потоки", но потоки уже запущены,
    for (int i = 0; i < xs.size(); ++i) { // осталось лишь распределить среди них вычислительную рабочую нагрузку
        threadSum += xs[i]; // почему здесь не нужна критическая секция?
    }
    #pragma omp critical
    {
        totalSum += threadSum;
        std::cout << "Thread #" << threadId << " finished!" << std::endl;
    }
}

А зачем здесь первая критическая секция? Нельзя ли ее сделать без синхронизации? Попробуйте.

А зачем здесь вторая критическая секция? Нельзя ли ее сделать без синхронизации? Попробуйте.

Как распределяются вычисления?

Как выяснить какие индексы цикла достаются потоку при вычислении? Попробуйте придумать эксперимент который позволит это выяснить опытным путем.

Урок 23: многопоточность (lock, критическая секция)

Tue, 19 Apr 2022 21:02:00 +0000

Однопоточоная модель вычислений

Все это время мы мыслили в модели вычислений когда программа шаг за шагом выполняет одну инструкцию за другой.

Могут быть команды которые меняют порядок выполнения инструкций:

for позволяет выполнять некоторый набор последовательных команд пока выполняется некоторое правило (предикат),
if позволяет выполнять набор команд только в некоторых случаях,
вызов функции может выполнить прыжок (в ассемблере для этого используется инструкция jump) исполнения команд в другое место

выглядит это примерно так - есть набор инструкций, есть указатель на инструкцию выполняемую в данный момент (instruction pointer) и оперативная память которую эти инструкции меняют:

Многопоточная модель вычислений

Но скорость работы программы определяется тем сколько команд в секунду выполняет процессор. В какой-то мере эта скорость определяется частотой процессора. Например процессор с частотой 3 GHz может выполнять примитивные команды со скоростью около 3 миллиарда примитивных операций в секунду.

И такая частота работы процессора была достигнута уже около 2004 года, и с тех пор росла несущественно, хотя до 2004 года довольно много лет (условно 10-20 лет) частота процессора росла быстро - примерно в два раза каждые два года. См. так же Закон Мура.

Как же продолжать получать достигать увеличения мощности процессоров? Ведь это необходимо например для серверного рынка.

Давайте скажем что одновременно у нас выполняется много программ, пользователь может одновременно смотреть youtube, слушать музыку, играть в сапера и т.п., все эти программы работают параллельно. Что если создать в процессоре несколько вычислительных ядер - каждое из которых будет работать как мы привыкли - в модели однопоточного вычисления - независимо от других ядер? Мы получим ускорение, ведь теперь не придется делить силы одного ядра на все эти программы, мы получили увеличение общей вычислений мощности во столько раз сколько ядер в процессоре.

Но что если мы хотим ускорить работу одной отдельно взятой программы? Что если мы хотим часть задачи считать в одном потоке (на одном ядре), другую часть задачи считать в другом потоке (на другом ядре) и за счет этого получить ускорение? Тогда нам нужно уметь обмениваться данными между этими потоками - например чтобы находить общий ответ в вычисляемой задаче (представьте что мы хотим просуммировать числа массива). Для этого у нас уже есть оперативная память, но возникает одна большая проблема.

Проблема гонки (Race condition)

Пример с Jenga Представьте что у нас есть Вася и Петя. Каждый из них достиг невиданных высот в мастерстве игры в Дженгу:

Каждый из них всегда делал свой ход безукоризненно, всегда грамотно выбирал какую деревяшку можно вытащить, и успешно ее вытаскивал!

Но что если Вася и Петя сделают ход абсолютно синхронно? Что если они выберут две деревяшки с одного и того же уровня, или хуже того - просто одну и ту же деревяжку?

Тогда они помешают друг другу и результат может быть непредсказуем. Было бы лучше им сначала решить кто ходит первый, а кто второй. Тем самым гарантировав что в любой момент с башней взаимодействует не больше одного игрока, а значит никто ему не помешает.

Пример с банком Представим что есть два банкомата и многоликий Коля. Этот многоликий Коля может одновременно быть везде и нигде. Взаимодействовать абсолютно синхронно с любым числом предметов, даже с банкоматами.

При этом банк из-за большого числа клиентов все транзакции из банкоматов выполняет на разных ядрах процессора (их могут быть тысячи).

В таком случае может случиться следующее:

1) У Коли была 1000 рупий на счету

2) Он синхронно с банкомата А снял 100 рупий, и с банкомата Б снял 200 рупий

3) Каждое снятие выполняется на отдельном вычислительном ядре процессора, но то сколько денег на счету Коли хранится в одной и той же переменной счет в оперативной памяти

4) Кроме того каждое снятие это три инструкции процессора:

4.1) считать информацию из оперативной памяти о количестве денег на счете

4.2) проверить достаточно ли денег

4.3) посчитать сколько денег осталось

4.4) сохранить в оперативной памяти новое число на счете

Но в таком случае на счете сохранится то ли 900 рупий, то ли 800 рупий. Банку очень не понравится такая многопоточность!

Подобная ошибка, или даже скорее - подобная ситуация и состояние называется состоянием гонки (Race condition). Ведь два потока буквально соревнуются “кто первый!”, и ирония в том что побеждает скорее тот кто последний - ведь именно его результаты будут сохранены в памяти. При этом обычно результат зависит от воли случая, и в этом коварство гонки - она может приводить к сложно отслеживаемым и трудновоспроизводимым (а значит тяжко отлаживаемым) ошибкам в коде.

Что делать (lock и критическая секция)

Оказывается существует инструмент который позволяет указать что эту часть программы может выполнять только один поток. Например если мы хотим просуммировать все элементы массива - давайте скажем что один поток считает левую половину, а второй считает вторую половину. Но нам нужно будет результаты их работы просуммировать. Тогда давайте добавлять их частичную сумму к переменной с общим ответом. Но делать это нужно обязательно без состояния гонки.

Справиться с этим поможет инструмент lock (в переводе - защелка) и он позволяет сказать что мы делаем какую-то опасную инструкцию (добавление нашей частичной суммы к общему ответу), мы боимся гонки, мы боимся что другой поток тоже будет добавлять частичную сумму и все испортиться.

А значит давайте скажем что в один и тот же момент времени добавлять частичную сумму к результату может только один поток.

Иначе говоря давайте создадим специальную комнату, выполняя команды в которой мы имеем гарантии что никто другой в этой комнате нам не помешает. Что-то вроде уборной - защелка на входе (отсюда название lock) позволяет быть уверенным что нам не помешают. В коде секция с командами которые проводятся с такой гарантией называется критической секцией:

Благодаря тому что суммирование частичных сумм выполняется из критической секции - сначала один из потоков сделает свои дела, т.е. узнает какая была общая сумма (пока что 0), затем посчитает новую сумму (т.е. 0+a) и сохранит ее в оперативной памяти. И лишь затем, дождавшись когда один поток выполнит свою задачу - другой поток постучавшись и увидев что уборная свободна зайдет и сделает свои дела. Т.е. узнает какая общая сумма на данный момент (увидит новую сумму - частичную сумму сохраненную первым потоком), посчитает новую сумму (т.е. добавит свой результат) и сохранит ее в опреативной памяти.

Урок 22: ретуширование фотографии (быстро и качественно, PatchMatch)

Mon, 04 Apr 2022 21:02:00 +0000

Постановка задачи и базовой идеи:

Хотим залатать дырку в картинке (дырка задается маской)
Вместо залатывания монотонным цветом - хотим чтобы выглядело естественно
Поэтому залатываем дырку беря наиболее подходящие доноры-заплатки из других частей картинки:

Основные идеи предыдущей попытки:

Давайте хранить в каждом пикселе стрелочку как на иллюстрации выше - указание откуда берется донор-заплатка
Научимся замерять качество заплатки через сумму разницы цветов в окрестности патча (например 7х7 пикселей)
Будем рассматривать новые случайные стрелочки и заменять старые на новые если в таком случае качество растет

Как можно коротко охарактеризовать такую попытку? По своей сути это что-то вроде перебора: чем дольше мы ждем - тем больше вариантов будет рассмотрено, а значит больше шансов найти хороший ответ.

Но как увеличить шансы найти хороший ответ за минимальное число попыток? Т.е. как увеличить качество и при этом ускорить?

Идея 1: заметим что доноры-заплатки согласованы (Propagation=распространение)

Если есть какое-то хорошее сопоставление - то почти наверняка такую же стрелочку стоит провести и для наших соседей. Иначе говоря наши соседи хотят сопоставляться с соседями нашего сопоставления:

Как это реализовать? Давайте предложим пикселю вместо случайной гипотезы, вместо случайного смещения - смещение которое на данный момент сохранено как лучшее у пикселя слева от нас. Оценим качество такого смещения для нас, по сути - примерим его на себя, если нам подошло, если наше качество выросло - то надо сохранить для себя такое смещение.

А кто еще может вдохновить нас такими идеями? Например сосед сверху, сосед справа и сосед снизу.

Из этого вытекает идея этапа Propagation (в переводе - распространение):

1) Идем по всем строчкам сверху вниз

2) Идем по всем пикселям строчки слева направо

3) Смотрим на смещения у соседей слева и сверху - если они улучшают наше качество - сохраняем их у себя

Таким образом все хорошие идеи которые случайным образом угадались будут распространяться вниз и вправо насколько это возможно.

Чтобы было симметрично и хорошие идеи распространялись так же и вверх и влево - давайте запускать в т.ч. обратный Propagation:

1) Идем по всем строчкам снизу вверх

2) Идем по всем пикселям строчки справа налево

3) Смотрим на смещения у соседей справа и снизу - если их смещение улучшает наше качество - берем лучшее из них себе

Изначально еще до Propagation нам надо выбрать хоть какие-то сопоставления - их давайте сделаем случайными.

Но после прохода Propagation когда мы вдохновились решениями соседей и все хорошие сопоставления распространились до куда могут - как генерировать новые идеи?

Можно просто накинуть для каждого пикселя новое случайное сопоставление, и если оно лучше по качеству чем то что у него было до сих пор - заменить.

Но как например заложить в алгоритм идею навроде у нас хорошее сопоставление взятое от соседа, но нам бы его чуть изменить, чуть сместить, чуть уточнить под себя?

Давайте брать не просто случайное сопоставление, а несколько гипотез в экспоненциально убывающих окнах:

Случайное сопоставление вокруг нашего пикселя в радиусе ширины картинки (по сути - случайная гипотеза во всей картинке)
Случайное сопоставление вокруг нашего пикселя в половине радиусы ширины картинки (в какой половинке?)
Случайное сопоставление … в радиусе равном четвертинке ширины картинки (в какой четвертинке?)
Случайное сопоставление … в окрестности \(\frac{1}{8}\) ширины картинки (вокруг чего?)
Случайное сопоставление … в окрестности \(\frac{1}{16}\) ширины картинки (вокруг чего?)
…
Случайное сопоставление … в окрестности 1 пикселя вокруг нашего текущего сопоставления

Т.е. мы накидываем случайные гипотезы все ближе и ближе к нашей текущей гипотезе:

И берем лучшую из них (или оставляем старое сопоставление если оно победило по качеству).

Этот этап называется Refinement = уточнение/улучшение решения.

Идея 3: лучше начать с картинки в меньшем разрешении (Coarse-to-Fine = от грубого к детальному)

В маленькой картинке проще перебрать все гипотезы и в целом окно сопоставления (например 7х7) видит контекст лучше и надежнее.

Так давайте сначала залатаем дырку в низком разрешении и на базе этого залатывания получим неплохой стартовый вариант для следующего разрешения:

Общая структура кода

1) Взяли картинку, взяли маску.

2) Построили пирамиду из разных разрешений этой картинки (по сути - много раз уменьшаем ее в два раза).

3) Построили пирамиду из разных разрешений этой маски (уменьшаем в два раза).

4) На каждом уровне детализации картинки+маски:

4.1) Если это первый уровень - генерируем случайные сопоставления

4.2) Если это не первый уровень - сопоставления берем с предыдущего уровня

4.3) Выполняем сколько-то итераций, на каждой итерации:

4.3.1) Выполняем Propagation (т.е. распространяем хорошие гипотезы) - вниз и вправо если итерация четная, вверх и влево если итерация нечетная

4.3.2) Выполняем Refinement (т.е. уточнения текущей гипотезы случайными пертурбациями в экспоненциально умешающемся окне поиска)

Технические детали

1) Как построить пирамиду картинок разного разрешения? Пример:

cv::Mat original = ...;
std::cout << "Image resolution: " << original.cols << "x" << original.rows << std::endl;
std::vector<cv::Mat> pyramid; // здесь будем хранить пронумерованные версии картинки разного разрешения
                              // нулевой уровень - самая грубая, последний уровень - самая детальная

cv::Mat img = original.clone();
const int PYRAMID_MIN_SIZE = 20; // до какой поры уменьшать картинку? давайте уменьшать пока картинка больше 20 пикселей
while (img.rows > PYRAMID_MIN_SIZE && img.cols > PYRAMID_MIN_SIZE) { // или пока больше (2 * размер окна для оценки качества)
    pyramid.insert(pyramid.begin(), img); // мы могли бы воспользоваться push_back но мы хотим вставлять картинки в начало вектора
    cv::pyrDown(img, img); // эта функция уменьшает картинку в два раза
}

2) Что делать если мы сопоставляем патч \(A\) вокруг пикселя с патчем-донором \(B\) вокруг пикселя на которого указывает сопоставление?

2.1) Если патч-донор \(B\) оказался заползающим на отмаскированную територию, т.е. пытается взять те цвета которые мы пытаемся менять и улучшать - давайте просто выдадим ему очень плохое качество (хуже чем у любого другого сопоставления которое не выходит за пределы картинки, чтобы такое сопоставление всегда проигрывало и никогда не бралось).

2.2) Если патч-донор \(B\) оказался за пределами картинки хотя бы одним пикселем - это плохой донор, он обрезан, его лучше не брать, давайте тоже просто выдадим ему очень плохое качество (хуже чем у любого другого сопоставления которое не выходит за пределы картинки, чтобы такое сопоставление всегда проигрывало и никогда не бралось).

2.3) Если патч \(A\) оказался за пределами картинки хотя бы одним пикселем - это плохая окрестность вокруг пикселя который мы хотим залатать. Что тогда с ним делать? Не бросать же. Так давайте просто не учитывать те пиксели из окрестности, что выходят за пределы картинки. Или давайте вместо их разницы цветов (ведь у них нет цвета) добавлять какую-нибудь константу. От значения этой константы сопоставление-победитель не изменится.

3) Как организовать код так чтобы Propagation стадия была написана без копи-пасты один раз? Чтобы не было варианта про вперед (вниз и вправо) и второго варианта про назад (вверх и влево)? Если нет идей - позовите и обсудим. Вот код подсказка:

bool isForward = true / false;
int iFirst = 0;
int iLast = N; // на самом деле это индекс ПОСЛЕ последнего, в данной иллюстрации у нас в массиве якобы N элементов
int iStep = 1;

if (!isForward) {   // если мы хотим протий по массиву в обратном направлении
    iFirst = N - 1; // то начинаем с конца
    iLast = -1;     // заканчиваем как только дошли до элемента сразу за самым первым 
    iStep = -1;     // и шаг теперь не плюс 1, а минус 1, т.к. мы идем назад (уменьшаем индекс)
}

for (int i = iFirst; i != iLast; i += iStep) {
    int iPrevious = i - iStep;
    int iCurrent = i;
    int iNext = i + iStep;
    // ...
}

4) Какую метрику для оценки качества сопоставления патча лучше использовать? Можно использовать сумму абсолютных разниц (SAD = Sum of Absolute Differences), но гораздо лучше работает сумма квадратов разниц (SSD = Sum of Squared Differences), т.к. за отклонение цвета штраф обладает квадратичной (более сильной и строгой) зависимостью а не линейной.

5) Как обновить найденные сопоставления при переходе от одного уровня детальности к следующему? Подумайте как обновить каждую стрелочку-сопоставление? Во-первых, каждый пиксель расчетверился, значит каждый из этих новых пикселей хочет вдохновиться старой стрелочкой сопоставлением. Во-вторых, картинка увеличилась вдвое, значит все расстояния увеличились вдвое, значит и стрелочку надо домножить на два.

6) Как ускорить еще сильнее? Заметьте что стрелочки нам нужны не для всех пикселей, но на самом деле и не только для тех что отмаскированы… Подумайте почему? Или закодьте и посмотрите как изменится разница? Это очень интересный вопрос, позовите меня и его будет очень полезно обсудить.

7) Что делать если я не понимаю всю ценность в освоении тайных навыков paint-мастерства? Не хочу изучать Paint.NET и аналоги? Не понимаю что мне все-равно позже надо будет изучить все эти рисования со слоями и прозрачностью для создания презентаций и прочих визуализаций? Тогда вот готовая маска для датасета с клумбой.

Ссылки

Оригинальная статья представившая этот алгоритм:

Примеры

Урок 21: ретуширование фотографии (залатывание дыр)

Mon, 14 Mar 2022 21:02:00 +0000

Давайте посмотрим на такой кадр из фильма:

Снизу слева заметен микрофон, что если мы хотим его удалить?

Давайте для начала создадим картинку-маску которая сохранит наше мнение о том какие пиксели надо удалить.

1) Дома скачайте и установите paint.net и обязательно создайте свою картинку-маску для второго примера в репозитории, на уроке же воспользуйтесь моей маской для микрофона и других тестов (маски уже есть в репозитории).

2) Откройте картинку 2_original.jpg в paint.net и добавьте слой поверх картинки - там мы будем рисовать нашу маску:

3) Теперь аккуратно белым карандашом очертите контур вокруг микрофона:

4) Теперь залейте белым цветом весь микрофон:

5) Оригинальная картинка нам больше не нужна - уберите ее слой и залейте все остальное черным цветом:

6) Сохраните получившуюся черно-белую картинку через File->Save As->->OK->Flatten (обязательно укажите название файла и его расширение):

7) Проверьте что все в порядке с картинками в папке репозитория, что маска идеально накладывается на микрофон (еще можно открыть картинку и нажимая стрелочки влево-вправо, или PageUp-PageDown помигать между картинками):

Алгоритм

1) Создаем картинку в которой для каждого пикселя храним смещение - указание откуда мы берем донора для ретуширования, откуда берем заплатку. Изначально смещение (dx=0, dy=0) означает что донор мы сами. Но в отмаскированных пикселях надо найти кого-то другого неотмаскированного из другой части картинки.

2) Картинка хранящая такие смещения:

будет хранить два целых числа - относительно смещение по оси x (dx, т.е. смещение номера колонки) и относительное смещение по оси y (dy, т.е. смещение номера строчки)
тип этой картинки - CV_32SC2
заполнена она изначально парами из нулей - cv::Scalar(0, 0)
а какого она разрешения?
каждый элемент в такой картинке смещений обладает типом не cv::Vec3b как было с RGB-картинками, а cv::Vec2i (i=int)
поэтому чтобы извлечь какой-то элемент надо написать: cv::Vec2i dxy = shifts.at<cv::Vec2i>(j, i);

3) Теперь давайте просто много раз генерировать случайную гипотезу-смещение, и сравнивать ее качество с качеством смещения которое мы уже сохранили в этом пикселе.

4) Как оценивать качество? Приложим окрестность вокруг пикселя к окрестности вокруг пикселя на который указывает смещение.

5) В коде приведет какой-то набросок кода который может подсказать общую структуру кода.

Урок 20: сшивка панорамы по шву найденному быстрой Дейкстрой

Tue, 08 Mar 2022 21:02:00 +0000

Пусть мы взяли две картинки:

Пусть мы поняли насколько отличаются их цвета в одном и том же пикселе:

Давайте проложим кратчайший путь по этой карте различий из нижнего левого угла всего пространства панорамы в верхний левый угол:

Что нам для этого надо учесть? Как свести задачу к Дейкстре из прошлого задания?

Давайте максимально приблизим к решению из задания про “найти выход в лабиринте-картинке”
Достаточно создать картинку-лабиринт (см. функцию buildTheMaze(...)) из нашей картинки насколько отличаются их цвета в одном и том же пикселе
А в пикселях лабиринта где хотя бы одна из наложенных картинок отсутствует (т.е. isPixelEmpty(...), т.е. черный пиксель) - скажем что цена прохождения очень высокая - например const int BIG_PENALTY = 100000;
После чего (см. функцию findBestSeam(...)) из каждого пикселя давайте проведем ребро вверх и ребро вправо с длинной равной значению содержащемуся в пикселе лабиринта
И наконец найдем Дейкстрой кратчайший путь из вершины start соответствующей нижнему левому углу всего пространства панорамы, в вершину finish соответствующую верхнему правому углу всей панорамы

Теперь надо как-то построить красивую панораму так чтобы все что слева от этого шва - было взято из первой картинки, а все что справа от этого шва - было взято из правой картинки.

Давайте визуализируем и построим для начала такую картинку - в каждом пикселе черный цвет (PIXEL_NO_DATA = 0) если этого пикселя нет ни на одной картинке, темно-серый (PIXEL_FROM_PANO0 = 100) если этот пиксель должен быть взят с первой картинки, светло-серый (PIXEL_FROM_PANO1 = 200) если со второй:

Как построить такую картинку? Давайте начнем с того чтобы заполнить всю картинку PIXEL_NO_DATA, затем запретим пересекать шов - заполним все пиксели принадлежащие шву значением PIXEL_IS_ON_SEAM = 1, затем с помощью поиска в ширину заполним пиксели относящиеся к первой картинке (т.е. PIXEL_FROM_PANO0):

1) Изначально отметим все пиксели как PIXEL_NO_DATA

2) Теперь запретим пересекать шов - заполним все пиксели принадлежащие шву значением PIXEL_IS_ON_SEAM = 1

3) Дальше давайте воспользуемся поиском в ширину (BFS) чтобы распространить влияние первой картинки начиная с верхнего левого угла вплоть до шва-границы

4) Отметим верхний левый пиксель как PIXEL_FROM_PANO0 и добавим его в текущую волну распространения (curWave)

5) Выполняем в цикле while до тех пока в текущей волне распространения (curWave) есть хотя бы один пиксель:

5.1) Смотрим на каждый пиксель из текущей волны распространения и смотрим в цикле на каждый из четырех соседей (слева, сверху, справа, снизу)

5.2) Если сосед (neighbor - сосед, поэтому пусть nx, ny) за пределами картинки - ничего с ним не делаем

5.3) Если сосед пуст в первой картинке - в него тоже не надо распространять влияние первой картинки - ничего с ним не делаем

5.4) Если это пиксель лежащий на шве (PIXEL_IS_ON_SEAM) - в него тоже не надо распространять влияние первой картинки - ничего с ним не делаем

5.5) Если это пиксель который уже принадлежащий первой картинке (PIXEL_FROM_PANO0) - ничего с ним не делаем

5.6) Иначе - отмечаем соседний пиксель nx, ny как принадлежащий первой картинке (PIXEL_FROM_PANO0) и добавляем его в следующую волну обработки nextWave

5.7) Когда мы обработали все пиксели текущей волны - новая волна готова, берем ее вместо текущей: curWave = nextWave;

6) Все остальные пиксели будем заполнять со второй картинки - значит все кто не PIXEL_FROM_PANO0 и при этом не пусты на второй картинке - должны быть заполнены PIXEL_FROM_PANO1

Наконец давайте сделаем красивую панораму с учетом этой картинки указывающей откуда какую картинку брать:

Как это сделать? пройти по всем пикселям, посмотреть из какой картинки брать цвет - и взять соответственно :)

Сделайте свою панораму

Сделайте две фотографии при этом убрав два объекта на фоторой фотографии, примерно так:

Голубая вертикаль показывает где прошла граница другой фотографии.

Когда снимаете первую фотографию положите объект (зеленого Единорога) там где будет проходить граница второй фотографии.

Не двигайте телефон в пространстве, камера вашего телефона должна быть в той же точке пространства, просто слегка поверните телефон вокруг оси проходящей через камеру вашего телефона. Иначе говоря - вам надо избегать параллакса.

Когда снимаете вторую фотографию уберите старый объект и положите новый объект (фиолетовое нечто, или можете просто переложить объект) там где проходит граница первой фотографии.

Подумайте где должен был бы пройти шов, проверьте где он на самом деле прошел. А что будет если оба эти объекта большие и наложатся?

Чтобы сохранить результат на github - разверните все подпапки в lesson17/resultsData -> выделите все картинки (кликнув по самой верхней, а затем зажав Shift и кликнув по самой нижней) -> правая кнопка мыши -> Git -> Add.

Как ускорить Дейкстру

1) Использовать компиляцию с оптимизациями, т.е. компилировать Release или RelWithDebInfo

2) В самом начале считанные картинки уменьшить в разрешении - см. сколько раз они уменьшаются - переменная int downscale = 2;

3) И наконец самый хороший шаг - ускорить Дейкстру. В ней тормозит этап “ищем самую ближайшую вершину”, его можно ускорить используя приоритетную очередь которая за быстро умеет выдавать минимальный элемент (он в ней всегда лежит первым) и в эту приоритетную очередь можно за быстро добавлять новые элементы:

Создайте эту приоритетную очередь (очередь по английски - queue): std::set<std::pair<int,int>> queue;
Каждый элемент в этой очереди - пара, первое число в паре - приоритет (в нашем случае “расстояние от старта”), второе число - номер вершины
Изначально в очередь нужно добавить стартовую вершину с приоритетом 0: queue.insert( std::pair<int,int>(0, start));
Чтобы достать (и удалить из очереди) минимальный элемент (тоже пару): std::pair<int, int> min_pair = queue.extract(queue.begin()).value();
Чтобы узнать из минимального элемента что за вершина в нем: the_closest_one = min_pair.second; (не забудьте проверить - а не обработана ли уже эта вершина, ведь мы одну и ту же вершину могли добавить в очередь несколько раз, подумайте об этом!)
И наконец каждый раз когда у какой-то вершины меняется дистанция - ее нужно добавить в очередь с этой новой дистанцией как приоритет: queue.insert(std::pair<int, int>(vertex_new_distance, vertex));
Удобнее всего обкатать ускоренную Дейкстру в прошлом задании про лабиринты, когда заработает - можно убрать уменьшение картинок в этом задании - int downscale = 0;

Урок 19: панорама и визуализация качества склейки

Tue, 01 Mar 2022 21:02:00 +0000

Давайте возьмем опять две кратинки и снова сошьем их в панораму:

Но как оценить качество склейки? Как визуализировать насколько хорошо одна картинка наложилась на другую?

Давайте просто визуализируем насколько отличаются их цвета в одном и том же пикселе:

Упражнение 1 Подумайте почему разница выглядит так?

Упражнение 2 Почему в левой части перекрытия картинка светлее а в правой части - темнее?

Упражнение 3 Какая в таком случае панорама будет выглядеть более бесшовной - правая картинка поверх левой или наоборот (левая картинка поверх правой)?

Упражнение 4 А где вообще заметнее всего в панораме что это две картинки? Это можно было бы назвать швом или разрезом?

Упражнение 5 Подумайте - а можно ли было бы еще лучше как-то проложить этот шов кроме как примитивно выбирая какую из картинок класть поверх другой?

Давайте посмотрим еще на примеры:

Упражнение 6 Почему почти вся зона перекрытия выглядит черной?

Упражнение 7 Что можно тогда предположить о заметности шва? Он сильно заметен или нет?

Упражнение 8 Как бы вы сформулировали в каких частях картинки на этом примере наибольшая разница цветов?

Упражнение 9 Если вы обратили внимание на дом и кран, то как бы вы сформулировали как должен быть проложен шов/разрез относительно таких ярко выделяющихся и по-разному выглядящих объектов?

Упражнение 10 Есть идеи какой алгоритм мог бы проложить этот шов автоматически так чтобы его суммарная заметность была минимальна?

Упражнение 11 Сфотографируйте пару фотографий так чтобы у них было 30% перекрытия и при этом в зоне перекрытия присутствовал объект симулирующий “проблему” (как дом и кран) - например просто положите объект когда делаете первую фотографию, а перед тем как делать вторую фотографию - уберите этот объект.

Урок 18: поиск кратчайшего пути методом Дейкстры и лабиринты

Tue, 15 Feb 2022 21:02:00 +0000

Предлагается реализовать алгоритм поиска кратчайших путей в графе методом Дейкстры (если что - можно найти много статей про этот алгоритм в интернете).

Граф представляем ввиде:

1) Вершины пронумерованы от \(0\) до \(N-1\) (где \(N\) - число вершин), для каждой вершины будем хранить:

Расстояние от точки старта до нее по кратчайшему найденному на данный момент пути. Т.е. мы пытаемся найти кратчайшие пути из стартовой точки до каждой другой точки. Изначально эти расстояния - бесконечность для всех вершин кроме самой стартовой.
Пометку обработали ли мы уже эту вершину, иначе говоря проверили ли все исходящие из этой вершины пути для того чтобы попытаться найти какие-то новые кратчайшие пути до каких-то вершин.
На равне с кратчайшим расстояним самого быстрого пути нам хотелось бы знать сам путь. Для этого достаточно в каждой вершине хранить ссылку на предыдущую вершину с кратчайшего пути, т.е. достаточно помнить последний шаг - тогда отшагнув по нему назад - можно будет спросить еще один предыдущий шаг у этой предыдущей вершины.

2) Ребра хранятся списками смежности:

Каждое ребро знает откуда и куда идет и знает свою длинну (т.е. насколько длинный маршрут надо преодолеть чтобы переместиться по этому ребру).
У каждой вершины есть вектор в котором хранятся все ребра которые исходят из этой вершины.
Получается список смежности - это вектор размера \(N\) в котором каждый элемент - векторов ребер (список ребер исходящих из вершины). Ведь вершины пронумерованы от \(0\) до \(N-1\). Т.е. std::vector<std::vector<Edge>> edges(nvertices);

Алгоритм Дейкстры

1) Создали список смежности (т.к. записали для каждой вершины список ее ребер, обратите внимание что граф неориентированный, т.е. ребра симметричные).

2) Создали вектор в котором у каждой вершины хранится длина кратчайшего пути от старта до нее. Изначально все значения равны константе бесконечности INF: const int INF = std::numeric_limits<int>::max(); (самое большое значение int). Значение кратчайшего расстояния для начальной вершины выставляем в 0.

3) Создали вектор в котором у каждой вершины хранится флажок распространяли ли мы пути от нее, т.е. обработана ли уже вершины. Изначально никакя вершина не обработана.

4) Создали вектор указывающий для каждой вершины куда (в какую вершину) надо отшагнуть назад чтобы прошагать задом наперед кратчайший путь. Изначально пути неизвестны, а в таком случае давайте укажем несуществующую точку - \(-1\).

5) Пока прогресс не прекратится:

5.1) Ищем из вершин которые еще не обработаны (из которых еще не продолжили пути) - самую близкую к началу (и достижимую), выбрали ее - теперь это Избранная Вершина.

5.2) Если такой нет (т.е. все вершины обработаны или все необработанные вершины недостижимы) - прогресс прекратился - break;

5.3) Смотрим куда ведет каждое ребро исходящее из Избранной Вершины, если мы можем продлив путь нашей Избранной Вершины улучшить текущий ответ для соседней вершины (т.е. куда ведет очередное ребро) - делаем это (обновив ее кратчайшее расстояние и указав что шаг назад из нее надо делать в Избранную Вершину).

5.4) Помечаем Избранную Вершину обработанной (т.е. что она уже нанесла все добро своим соседям что могла).

6) Проверяем какой ответ лежит в вершине до которой мы хотели найти путь.

7) Если там лежит не бесконечность - то можем восстановить этот путь прошагав назад по ссылкам на предыдующую вершину на кратчайшем пути. Просто шагаем пока не дойдем до начальной вершины, ведь из начальной вершины предыдущий шаг будет \(-1\).

Задание 1: Дейкстра

mainDijkstra.cpp

Реализуйте метод Дейкстры описанный выше.

Чтобы проверить корректность:

1) Запустите на всех четырех тестах из папки data/mazesText/N.in (просто Ctrl+C -> Ctrl+V -> Enter в консоль после запуска приложения) - результат должен совпасть с N.out

2) Зарегистрируйтесь и отправьте свое решение на CodeForces - да, мы ищем Избранную Вершину очень медленно и не эффективно, но нас это устраивает, поэтому Превышено ограничение времени на тесте 31 - считайте успешным выполнением.

Задание 2: Лабиринт

mainMaze.cpp

Теперь давайте сделаем из этого что-нибудь классное, например найдем кратчайший путь в лабиринте:

1) Теперь граф надо придумать самим - давайте для начала придумаем как пронумеровать вершины графа - давайте нумеровать пиксель в строчке \(j\) и колонке \(i\) как \(j*w+i\), где \(w\) - ширина картинки.

2) Надо придумать какие у нас ребра - давайте соединять пиксели соседние друг с другом (т.е. у каждого пикселя кроме тех что на краю - четыре соседа).

3) А какие пропускные способности у ребер? Давайте они будут равны тому насколько яркий пиксель. Тогда в темных пикселях мы разрешаем двигаться дешево, а в белых - дорого (ведь это стенки).

4) Добавьте отрисовку кратчайшего пути:

5) Но как сделать так чтобы логика “какая пропускная способность у ребра” не зависела черно-белый или бело-черный у нас лабиринт? Чтобы работало даже если тропинка покрашена в синий цвет?

6) НЕ ЗАБУДЬТЕ протестировать все лабиринты (второй и третий - отличаются, пятый - не обязательный) и сохранить на диск результирующие картинки чтобы я мог легко и быстро на них посмотреть.

Мелочи

1) Не забудьте компилировать с оптимизациями (а не в Debug) - см. Как ускорить программу

2) НЕ ЗАБУДЬТЕ протестировать все лабиринты (второй и третий - отличаются, пятый - не обязательный) и сохранить на диск результирующие картинки чтобы я мог легко и быстро на них посмотреть.

Урок 17: сопоставление картинок SIFT/ORB для интерактивного AR через вебкамеру

Tue, 01 Feb 2022 21:02:00 +0000

В предыдущем задании мы обсудили как работает RANSAC + методы фильтрации шумных сопоставлений.

Давайте теперь на базе этого сделает примерно такое приложение:

Но еще и работающее через вебкамеру.

Итого план задания - выполнять TODO в исходниках, в частности:

1) Проверьте работает ли у вас вебкамера через OpenCV, и выставите useWebcam соответственно

2) Детектируйте ключевые точки и постройте у них дескрипторы (на обеих фотографиях - ту что ищем и ту где ищем эту картинку)

3) Сопоставьте ключевые точки

4) Пофильтруйте найденные сопоставления (как минимум через K-ratio test, но лучше на ваш выбор)

5) Добавьте вывод в лог - сколько ключевых точек было изначально, и сколько осталось сопоставлений после фильтрации

6) findHomography(...) + cv::warpPerspective = нашли матрицу перехода и натянули одну картинку поверх другой

7) В конце кода поправьте управление - если пользователь нажал кнопку X, то Y.

8) Добавьте короткую текстовую справку про кнопки управления (текстом поверх окна)

9) Добавьте разбивку сколько времени занимает детектирование, сколько матчинг, сколько фильтрация (текстом поверх окна)

10) SIFT работает довольно медленно, попробуйте использовать ORB + не забудьте что тогда вам нужен другой DescriptorMatcher, насколько вырос FPS?

13) Изучите документацию и попробуйте улучшить качество/скорость - SIFT::create() и ORB::create()

14) Бонусное задание - можно попробовать сделать эффект дополненной реальности более полным - ведь сейчас если мы вкорячиваем несквик поверх коробок - то он рисуется поверх в т.ч. коробки справа, которую мы заменять не планировали. Можно попробовать это улучшить подобно тому как мы делали зеленый экран - достаточно сверить похож ли на заменяемую картинку пиксель который мы хотим заменить и если да - то только тогда заменять его на пиксель с новой картинки (на несквик).

Компьютерное зрение на С++. ФМЛ №239. 2021/2022

Урок 26: April Tag - этап 2: декодирование

Два этапа: детекция и декодирование

Вытаскиваем внутреннюю часть тэга

Кодировка

Lexicode - устойчивость к ошибкам

Устойчивость к повороту тэга

Устойчивость к встречаемому в природе

Итого

Урок 25: April Tag - этап 1: обнаружение

Два этапа: детекция и декодирование

Не хотим пропустить тэг пусть и ценой обнаружения иллюзий

3) Обнаружаем границы-отрезки

4) Обнаружаем четырехугольники

Урок 24: многопоточность - OpenMP

Распараллеливание цикла

Критическая секция

Reduction

Самописный Reduction

Как распределяются вычисления?

Урок 23: многопоточность (lock, критическая секция)

Однопоточоная модель вычислений

Многопоточная модель вычислений

Проблема гонки (Race condition)

Что делать (lock и критическая секция)

Урок 22: ретуширование фотографии (быстро и качественно, PatchMatch)

Идея 1: заметим что доноры-заплатки согласованы (Propagation=распространение)

Идея 2: как улучшить случайные гипотезы? (Refinement=уточнение)

Идея 3: лучше начать с картинки в меньшем разрешении (Coarse-to-Fine = от грубого к детальному)

Общая структура кода

Технические детали

Ссылки

Примеры

Урок 21: ретуширование фотографии (залатывание дыр)

Алгоритм

Урок 20: сшивка панорамы по шву найденному быстрой Дейкстрой

Сделайте свою панораму

Как ускорить Дейкстру

Урок 19: панорама и визуализация качества склейки

Урок 18: поиск кратчайшего пути методом Дейкстры и лабиринты

Алгоритм Дейкстры

Задание 1: Дейкстра

Задание 2: Лабиринт

Мелочи

Урок 17: сопоставление картинок SIFT/ORB для интерактивного AR через вебкамеру