eddys_snippets/erosion-dilation/README

************************************
СООБРАЖЕНИЯ ПО ПОВОДУ ЭРОЗИИ/ДИЛЯЦИИ
************************************


Эрозия

00000     00000
01110     00000
01110 =>  00100
01110     00000
00000     00000

Бит равен единице лишь тогда, когда присутствуют все его 4 связи.
Т.е. для срединных битов байта выполняем & текущего байта с байтами верхней и нижней строк. Для крайних битов необходимо проверить еще и 4-связные байты:

ABC
DEF
GHK

Младший бит E проверяется по старшему биту F, младшим битам B и H и второму биту E.
Старший бит E проверяется по младшему биту D, старшим битам B и E и седьмому биту E.

Таким образом, алгоритм получается следующим:
1. подменяем E маской[E] (эрозия внутренних битов)
2. делаем &: E = E & B & H
3. корректируем старший бит E по младшему D и младший бит E по старшему F.

ПРОВЕРИТЬ, ЧТО БЫСТРЕЙ: (A&0X80)>>8 ИЛИ РАЗЫМЕНОВАНИЕ УКАЗАТЕЛЯ (ПО ТАБЛИЦЕ)


Диляция

00000     00110
00110     01111
01010 =>  11111
01100     11110
00000     01100

Обратная ситуация: вместо & делаем | :
1. подменяем E маской (диляция внутренних битов)
2. делаем |: E = E | B | H
3. корректируем старший и младший биты операцией |.




**************************************************
СООБРАЖЕНИЯ ПО ПОВОДУ ВЫДЕЛЕНИЯ СВЯЗАННЫХ ОБЛАСТЕЙ
**************************************************

Вернемся к тому же общему случаю: искомый пиксель нахдится в байте E.
ABC
DEF
GHK

Фильтрация 4-связанных областей схожа с операцией диляции за исключением собственно
логики - в отсечении пикселей, не являющихся 4-связанными, необходимо провести операцию:

E4 = E & ( B|H|(E<<1)|(E>>1)|(D<<7)|(F>>7) )

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

Соответственно, для крайних пикселей (крайние столбцы/строки) выражение для E4
будет видоизменяться (для крайних строк - наличием/отсутствием B,H; для крайних
столбцов - наличием/отсутствием выражений с D, F).

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

Кстати, здесь нет проверки A,C,G и K, иначе пришлось бы еще больше кода наворачивать
(добавились бы особые случаи для углов изображения).


Общее выражение для поиска 8-связанных областей несколько видоизменится:

пусть {x} = (x|(x<<1)|(x>>1)), тогда
E8 = E & ( {B|H} | ((E<<1)|(E>>1)) | ((C|F|K)>>7) | ((A|D|G)<<7) )

Вычислительная сложность сильно возрастает, причем многие операции вычисляются по
два раза.  Пожалуй, можно попытаться немного ускорить вычисления, если заранее
подготовить матрицу {x} (и матрицы (x<<7) и (x>>7) ???).
/* (сомнительно) Аналогично, заранее подготовив матрицы x<<7) и (x>>7) можно
 *  попытаться ускорить поиск E4 */


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

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

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

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

Теперь каждый пиксель нашей матрицы соответствует одному пикселю изображения
ABC
DEF
GHK

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


=== Нулевое приближение ===

/*
Работаем с копией изображения, т.к. уже пройденные значения будем обнулять.
*/

Итак, выделим память под промежуточный буфер (сразу обнулив ее) и начнем
проходить изображение с левого верхнего угла. Как только мы натыкаемся
на единицу в E, записываем в соответствующие координаты буфера 1.
Далее смотрим, куда нам нужно двигаться. Считаем, что в A,B,C и D нули (т.к. там -
уже пройденная область). Нам необходимо проверить пиксели F, G, H и K.
Теперь каждый из них становится E. Если кто-то из них установлен в 1, проверяем
его соседей и т.д. Однако, на всех шагах, отличных от первого, мы уже обязаны
проверить ВСЕХ СОСЕДЕЙ, т.к. не факт, что наша область не представляет собою
какой-нибудь извращенной фигуры с отростками и многочисленными полостями.

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

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

После копирования каждого пикселя с 1 в результирующий буфер, "стираем" его
с оригинала (сбросом в 0). По окончанию операций обнуляем буфер.

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


=== "Гюйгенс". ===
Один из вариантов прохождения по изображению в поисках связанных областей (который,
собственно, первым пришел мне в голову еще вчера, но лучше всего, конечно, он бы
выглядел в рекурсивном исполнении).

== лирика по поводу рекурсии ==
Еще раз, чтобы убедиться лишний раз в том, что рекурсия невозможна, я набросал
элементарнейшую проверялку:

#include <stdio.h>

int incr(int a){
    fprintf(stderr, "%d ", a++);
    incr(a);
    return a;
}

main(){
    incr(1);
    return 0;
}

Проверялочка эта должна вылетать с сегфолтом как только скончаются все ресурсы
на рекурсию. Получилось вот что:

... 261504 Ошибка сегментирования (core dumped)
... 261350 Ошибка сегментирования (core dumped)
... 261333 Ошибка сегментирования (core dumped)

ЕМНИП, что-то подобное было на ЛОРе. И, возможно, предел этот даже как-то регулируется.
Число это подозрительно близко к 256к (262144): возможно, оно так и есть (просто
еще кучу места в стеке занимают всякие вспомогательные буферы из stdio).

Я немного видоизменил программку: она теперь еще и по 1к выделяет:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int incr(int a){
    char *x = malloc(1024);
    memset(x, 1, 1024);
    fprintf(stderr, "%d ", a++);
    incr(a);
    return a;
}

main(){
    incr(1);
    return 0;
}

Теперь цифры "более другие":

... 174258 Ошибка сегментирования (core dumped)
... 174372 Ошибка сегментирования (core dumped)
... 174325 Ошибка сегментирования (core dumped)

Кто сожрал 85к? Почему именно 85к? Заменяю выделение памяти на `char x = 2;` -
получаю то же самое. Добавление переменных ничего не меняет.
В любом случае, все-таки про рекурсию придется забыть: если искомая область будет
иметь площадь, превышающую эдак 170 тысяч пикселей (а это не так уж и много), то
я получу большой фигвам.
## конец лирики

Принцип Гюйгенса прост: каждая точка волнового фронта (в нашем случае - точка
внутри искомой области) является источником нового волнового фронта (в нашем
случае - центром, от которого "расходится" поисковая волна).

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

Долго кумекая, я так и не придумал, как реализовать "Гюйгенса", не вводя уйму
промежуточных матриц.


### "Гюйгенс модифицированный" ###
Для ограничения одной-единственной вспомогательной матрицей, можно попробовать
оставить одну "волну": от первоначальной точки проводим расходящуюся во все
стороны "волну". Пусть для простоты она будет "квадратной".
Пробегаясь по всем точкам очередного фронта "волны", кроме особых (о них -
позже, их тоже надо контролировать), "стираем" единицы с изображения, перенося их в маску.
Как только натыкаемся на нуль, если до этого тоже был нуль, заносим единичку в
матрицу спец.маски в соответствующий пиксель, а также в пиксель,
соседний с текущим, но расположеный на "волне" с радиусом на 1 больше (т.е. для левой
поверхности переносим пиксель влево на 1, для правой - вправо на 1 и т.п.).
Если натыкаемся на 1, делаем обнуление соответствующего пикселя на "волне" с радиусом
на 1 больше + его предыдущего соседа в спец.маске. Таким образом, "тени" получаются постепенно
сходящимися. Но все равно, остается возможность того, что эти "тени" что-нибудь да
сокроют, не говоря уже о том, что эта "волна" только в очень редких случаях сразу
выявит хотя бы внешний контур искомой фигуры.
Именно для этого и нужна наша спец.маска: как только "кончится" искомая фигура по
"большой волне", нужно будет просмотреть все пиксели маски (внутри уже получившегося
прямоугольника + 1 по радиусу, т.к. снаружи все равно нули), пробегая по их
внешней границе: как только обнаруживаем 1 в изображении, "выпускаем" новую "волну".
Пока бежим первый раз, пропускаем все единички в маске, копируя их на "волну" маски
с большим радиусом.

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

=== первое приближение к решению ===
Итак, сегодня я накачал всяких статеек. Почитал. Обычный алгоритм выделения
связанных областей (как я мог о нем не вспомнить?) жутко тормозной: он требует
как минимум четыре прохода (1 - маркировка соседних областей, 2 - построение
списка эквивалентности номеров, 3 - переименование областей, 4 - выделение
объектов). При этом на первом шаге мы должны проверять, были ли до пикселя нули,
на втором - верхнего соседа (и его боковых, если нужно заполнить 8-связанную
область), на третьем - сверяться с таблицей, на четвертом -
многократно сканировать изображение, пока все объекты не будут выделены.
Конечно, четвертый шаг можно укоротить: на третьем же шаге выделить массив
прямоугольников и обновлять размеры соответствующего прямоугольника.
Тогда четвертый шаг сведется к сканированию внутренностей каждого прямоугольника
с заполнением его маски единицами там, где в массиве номеров пиксель == N.

Процедура перемаркировки такова:
проходя матрицу с маркерами, проверяем каждый пиксель. Если пиксель нулевой,
устанавливаем флаг обнаружения в false и продолжаем. Если флаг == true, это значит,
что данный номер мы уже перемаркировали - продолжаем.
Если же пиксель - "свеженайденный", надо проверить все 6 пикселей (для 8-связных
областей) в предыдущем и последующем рядах (снизу - т.к. возможен вариант коротенького
кусочка, а то и единичного пикселя над длинной линией - из-за флага обнаружения мы
пролетим под ним, а вот на этапе сканирования его, изучая то, что под ним, сделаем
правильную ремаркировку). Вполне возможно, что нет необходимости проверять сразу и
пиксель над, и под нашим: пиксель точно под ним по-любому будет проверен (он - либо
часть более длинной линии, которую мы обнаружим в DL или DR углах, либо часть
вертикальной, которая обнаружится при сканировании нижней линии).

А вообще, полезно рассмотреть, какие варианты расположения соседей
могут быть, чтобы не пропустить мелочей (нумерация не важна, поэтому просто 1/0;
кроме того, т.к вариантов аж 256, рассмотрим лишь некоторые):
(X - что угодно, U - единица в одном из пикселей, V - единица в одном и более пикселей)

 A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R
XXX 000 UUU 000 101 101 11X 000 010 000 000 000 000 000 000 000 000 000
11X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X 01X
XXX 000 000 VVV 000 VVV VVV 010 000 000 000 000 000 000 000 000 000 000

A - просто проходим мимо
B - инкрементируем счетчик уникальных объектов и перемаркируем текущий номер
C - ремаркируем текущее значение на то, которое содержится в массиве с индексом,
	имеющим значение счетчика в пикселе с единичкой
D - то же, что в B + ремаркировка значений в нижней строке
E - ремаркировка текущего + правого верхнего счетчика по массиву с индексом,
	равным значению счетчика в левом верхнем пикселе
F - ремаркировка всех по левому верхнему
G - для упрощения можно сделать эквивалентом F: нет нужды усложнять алгоритм ради
	пары лишних операций
H - нет нужды проверять этот вариант, т.к. на стадии I он ремаркируется
I - заменяет H

Итак, общие тенденции:
- Если в верхней строке ничего нет, проверяем, не является ли наше текущее
значение счетчика уже перемаркированным: если является, оставляем как есть,
иначе - счетчик уникальных объектов инкрементируется и текущее значение перемаркируется
им; объекты внизу (если есть) тоже перемаркируются им
- если в левом верхнем углу !=0, все номера перемаркируются им, а пиксель над
нами проверять нет нужды
- если обнаружен !=0 ровно над нами, правый верхний проверять нет нужды, а оставшиеся
перемаркируются им

При организации процедуры переименования я натолкнулся на следующее: если ряд
X переименовывается в нижележащий Y, а потом Y переименовывается в Z, то ряд
X так и остается переименованным в Y.
Следовательно, при переименовании в массиве ассоциаций на стадии перенумерования
надо проверять, выполняется ли равенство assoc[assoc[X]] == assoc[X], т.е. зафиксировать
сложные связи.

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

Пока засыпал, придумал, как правильно скорректировать алгоритм переименования:
скажем, переименовываем мы пиксель с изначальной меткой "X", имеющий новую
метку "Y" (т.е. assoc[X] != X) в "Z". В этом случае надо наоборот переименовать
Z в Y, а величины, больше Z, но <= Ncur декрементировать, затем декрементировать
и Ncur.
 Все довольно просто, а очевидным
плюсом является то, что не надо многократно сканировать изображение для переименования
"по месту": это будет сделано на шаге 3.

Конечно, все познается в сравнении, поэтому сразу обливать дерьмом этот метод
нельзя: стоит попытаться его реализовать. А учитывая то, что все шаги, кроме второго,
превосходно параллелизуются (1, 3 - хоть по строкам, хоть по прямоугольным областям,
4 - по номерам объектов), на куде, пожалуй, он будет работать просто превосходно!


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

Итак, если выбрать эффективный метод закрашивания областей, то обнаружение
сведется к следующему:
1. пробегаемся по точкам изображения, как только находим 1, "закрашиваем" всю
область нулями с "перенесением" ее во временную маску (равную размеру изображения)
и параллельным обновлением границ бокса;
2. выделяем для бокса память и переносим в него кусок из маски ("модифицированный"
шаг 4 из предыдущих размышлений);
3. сканируем изображение, начиная со следующей точки после точки из п.1.

Если опустить "волшебную" фразу "закрашиваем" из п.1, то изображение сканируется
не "три с половиной", а "полтора" раза.  Т.о., если "закрашивание" будет
сканировать пиксели изображения лишь один раз, то получим весомый выигрыш.
Однако, тут же всплывает и минус: параллелится эта задача только разбиением
изображения на фреймы с последующим объединением оных. В принципе, если "закрашивание"
будет достаточно быстрым, то проблем не будет: все равно алгоритм будет работать
быстрее классического.

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

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

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


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


== реализация перемаркировки ==
Реализуя перемаркировку, я наткнулся на кое-какие "косяки". В итоге "малюсенькая"
inline-функция для перемаркировки превратилась в громоздкого монстра.
Но надо еще протестировать на разных "картинках" ее поведение. Если проблем
с перемаркировкой не будет, можно будет переходить к завершающему этапу - заполнению.

Так как в процессе перемаркировки счетчик количества объектов скачет туда-сюда,
для завершающего - четвертого - этапа придется-таки использовать "полтора" прохода:
сначала пробежаться по изображению с заполнением величин соответствующих боксов,
а затем уже пробежаться по внутренностям каждого бокса, заполняя их маски.

Пожалуй, цикл по ремаркировке стоит вынести в отдельную функцию: тогда можно будет
искать и 4-связанные области без предварительной 4-фильтрации.

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

Кстати, сейчас прогнал поиск 8-связанных областей по изображению, отфильтрованному
функцией FCfilter, и до меня дошло, что все равно нужно писать отдельную функцию
поиска 4-связанных областей, т.к. вполне может быть так, что две 4-связанные
области соприкасаются по диагонали. При этом они являются разными объектами, но
поиск 8-связанных областей обзывает их одинаково (что понятно).

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

Перед тем, как выполнить поиск 4-связанных областей, я выполняю фильтрацию. Она
заодно отсекает и одиночные пиксели. А вот фильтрация для функции выделения
8-связанных областей заключается в том, что как раз только одиночные пиксели
и отсекаются. Жалею сейчас, что пока был в ИПФ, не нагуглил, как наиболее оптимально
их фильтровать, поэтому опять буду изобретать велосипед.
Фильтрация одиночных точек на "упакованном" изображении при помощи логических
операций, как я говорил выше, использует огромное количество промежуточных
вычислений, поэтому я даже и браться не буду за нее: выигрыш производительности
получится сомнительным. Поэтому, пожалуй, проще всего будет воткнуть эту проверку
в функцию поиска связанных областей.

Красотищща! Оно работает!!!

Рано радовался: запустил тест (случайная картинка 2000х2000): получилось, что
cc4 работает почти в 2 раза медленней, чем cc8!!! Как? А ведь у cc8 значительно
больше проверок... Черт знает что! Да и вообще не понравилось мне время
выполнения: 13.3 секунд у cc4 и 7.8 у cc8.  Кстати, я еще не реализовал
шаг 4! При этом если из cc4 выкинуть функцию `FC_filter`, производительность
возрастает еще на пару секунд (ну, это,
наверное, из-за того, что приходится лишние пиксели проверять).

Я подозреваю, что виновата перемаркировка, занимающая тем больше времени,
чем больше областей обнаружено на изображении. Сейчас воткну тайминги в cclabel.
Тайминги показали, что действительно шаг 2 занимает на 4 порядка больше времени,
чем остальные шаги. А ведь сканирование-то идет единожды!
Отключив функцию ремаркировки, я получил крайне высокую производительность.
Глянул количество первично обнаруженных областей - их больше 200 тысяч!
Понятное дело, что если каждый раз при перемаркировке пробегаться по 200000
значений, а ремаркировок получаем почти столько же, производительность выйдет
вообще никакая!

В общем, надо думать, как оптимизировать это узкое место. Параллелизация
дала прирост производительности всего лишь в полтора раза. Я, правда, еще заметил,
что у меня количество итераций постоянно - по всем элементам, хотя стоит
проверять лишь те, которые уже пройдены. Скорректировал, получил прирост
производительности всего-то в полтора раза у cc4 и никакого прироста у cc8!

Уменьшив содержание единиц и нулей на изображении от 50/50 до 10/90, я получил
поразительно низкие цифры для cc4: полторы сотни миллисекунд! Время cc8 получилось
в районе 1с. Даже не знаю, нормально ли это: надо будет сравнить с другими
алгоритмами (хотя бы с лептоникой).
Уже сравнение с октавой показало, что у меня полная лажа: для тех же 50/50
октава дает 20мс! Зато для 10/90 у меня быстрей, чем в октаве (но октава
считает и одиночные точки :( ).

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

Я долго думал, как бы это на графах реализовать, но что-то так и не придумал.
Посмотрел на время - уже начало 11-го. Пора баиньки, а то завтра в 4:30 вставать.

== другой метод ==
Пока сидел в аэропорту НН, было время почитать статью китайцев. Действительно,
интересный способ: мой метод (теоретически) будет хорош на небольшом количестве
больших объектов, а их метод - на большом количестве малых.
Принцип почти тот же, что и в моем случае, но:
- шаги 1 и 2 объединены: на стадии именования меток происходит и ремаркировка;
- второй проход (который у меня - третий) такой же, как у меня - переименование
участков по скорректированным меткам.
Правда, китайцы умолчали, как они создавали список меток: если его создавать
динамически (как список, динамический массив или даже дерево), то все операции
над списком будут довольно-таки дорогими, поэтому есть смысл просто выделить
заранее достаточное количество памяти. Учитывая то, что объектов на изображении
ну никак не может быть больше, чем 1/6 размера изображения, можно "на авось"
выделить 1/4 размера изображения под массив ремаркировок.

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

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

Описанная выше процедура - для маркировки 8-связанных областей, если же нам нужно
маркировать 4-связанные области, мы просто проверяем лишь точку НАД нашей.

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

Черт бы подрал этот аэропорт: wifi как бы номинально есть, а реально - не работает,
собака! Вроде бы соединяет, но скорость очень близка к нулю: tracepath дает
аж секунды! В общем, на втором этаже жизни нет.

Все-таки сделал более-менее реализацию. Работает, но нужно еще внимательно
просмотреть функцию ремаркировки: эта собака неправильно считает количество
найденных объектов!

Бульбец! Самолет задерживают на полтора часа! Буду дописывать...