Графики из предыдущей темы (блин, обнаружил, что я вчера все делал в /tmp, а перенести в ~/Dropbox забыл! Поэтому все изменения пошли коту под хвост, уцелело лишь то, что в ЖЖшке выложил, так что посчитать коэффициенты не могу, а тесты заново делать ломает) показывают, что зависимость скорости вычислений от количества пикселей на объекте (а также — количества объектов и их размера) имеет степенной вид, причем степень довольно плавно изменяется при изменении размера изображения.

Таким образом, если время вычислений T = Nm, где N - количество пикселей на изображении, то разбиение изображения на M кусков может позволить ускорить вычисления в том случае, если
T1 = M·[(N/M)m + t(sqrt(N/M))] < T.
Здесь t - время выполнения операции слияния границ соседних блоков с соответствующей ремаркировкой.

подробности )
Итак, как я уже говорил в предыдущей записи, алгоритм китайцев у меня заработал. Вот — сравнение с моим:
graph
Производительность, по вертикали — логарифм времени выполнения операции, по горизонтали — корень из количества пикселей на картинке. Синее, красное, розовое — мое; зеленое, голубое и желтое — китайцев. Верхняя пара кривых — для 50% соотношения пикселей изображения и фона; средняя — для 10%; нижняя — для 90%.
Подробности )
Итак, продолжая разбираться с Octave, я решил понемногу получить в ней функционал моего велосипеда, чтобы проще было проводить дальнейшую разработку (сначала читаю статьи, затем разрабатываю алгоритм, затем оттачиваю его на мат. модели и только после этого переношу все на С).

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

July 2017

S M T W T F S
      1
23 4 5 6 78
9 101112 131415
16171819 202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 20th, 2017 02:43 pm
Powered by Dreamwidth Studios