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

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

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

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

September 2017

S M T W T F S
     1 2
3456789
1011 12 13141516
17181920 212223
24252627282930

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 25th, 2017 04:18 am
Powered by Dreamwidth Studios