Комментарии 23
То, что должно было быть упомянуто — результат чувствителен не к шуму, а к начальному выбору центров.
0
Да и кнему тоже.Про шум я имел ввиду то, что например при том же вычитании фона, некоторые точки из-за шума исходных изображений могут детектироваться как движущийся, а если они находиться на существенном расстоянии от кластера то граница того же кластера может сушественно исказиться.
0
ну и то, что зачастую это неплохо «лечится» случайным выбором изначальных центров + запуском пакетом (batch), т.е. несколько раз подряд с последующим усреднением результата
0
А если будет две одинаковые машины, он будет считать их одной?
0
Странно слышать рассказ об алгоритме кластеризации, с «примерами», нарисованными ручками. На них же ничего не видно. Интереснее смотреть когда есть картинка, которую кластеризуют. А тут сухой пересказ классического алгоритма и немного кода. Не видно ни на что алгоритм способен, ни его минусов.
P.S.
А, это первый пост автора. Тогда плюс. Но в будущем пишите более развернуто, с нормальными примерами.
P.S.
А, это первый пост автора. Тогда плюс. Но в будущем пишите более развернуто, с нормальными примерами.
+2
Да, с картинками нехрошо вышло, т.к с самой программой, которая выделяет движущиеся объекты, возникли пролемы.Пришлось ручками, хотя результат, впринципе, должен получиться приблизительно такой.
0
А каким алгоритмом движущиеся объекты выделяли?
0
В случае использования только значений RGB результат будет совсем не таким. Как минимум, наравне с синей и красной машинами в отдельный кластер будут отнесены зеленая трава и серый асфальт. Приведу пример применения алгоритма K-средних для изображения, взятого из книги Bishop, «Pattern recognition and machine learning»:
![image](https://habrastorage.org/r/w780q1/getpro/habr/comment_images/49b/9fb/c32/49b9fbc3210a300f0eecd6c89f8cc525.jpg)
Если же использовать вместе со значениями RGB еще и координаты самой точки (как предлагает автор), то возникает вопрос соотношения и нормировки этих величин: может сложиться ситуация, когда разница в расположении точек вносит намного бОльший вес в «расстояние» (которое считается как корень из суммы квадратов разницы соответствующих значений), нежели разница в цвете, либо наоборот. К примеру, для изображения 1000х1000 px максимальная разница координат точек (x и y) составляет 1000, тогда как разница в значении красного, зеленого и синего цветов не больше 255.
![image](https://habrastorage.org/getpro/habr/comment_images/49b/9fb/c32/49b9fbc3210a300f0eecd6c89f8cc525.jpg)
Если же использовать вместе со значениями RGB еще и координаты самой точки (как предлагает автор), то возникает вопрос соотношения и нормировки этих величин: может сложиться ситуация, когда разница в расположении точек вносит намного бОльший вес в «расстояние» (которое считается как корень из суммы квадратов разницы соответствующих значений), нежели разница в цвете, либо наоборот. К примеру, для изображения 1000х1000 px максимальная разница координат точек (x и y) составляет 1000, тогда как разница в значении красного, зеленого и синего цветов не больше 255.
0
Вы несколько все усложняете, в данном случае трава и асфальт никогда не попадут в кластер т.к они вообще не участвуют в кластеризации. В данном посте рассматривался тот случай, когда после метода вычитания фона все объекты кроме движущихся отсекаются, и в вектор кластеризируемых точек попадают только точки двух машин.
0
(надо обновлять комментарии, да)Как минимум, наравне с синей и красной машинами в отдельный кластер будут отнесены зеленая трава и серый асфальт.Как я понял, они же «пропадают» при вычитании фона, то есть их пиксели в принципе не доходят до этапа кластеризации.
А про соотношение цвета/сдвига координат — можно привести всё к значениям на [0;1] и уже там шаманить с весами, не будет хотя бы зависимости от размера картинки.
0
А как всё это собственно запустить, т.е. как вызвать метод Start?
Создать сколько надо кластеров и во все записать цвета пикселей или как-то по другому?
Спасибо
Создать сколько надо кластеров и во все записать цвета пикселей или как-то по другому?
Спасибо
0
А почему этот алгоритм не реагирует на тень? Она ведь не меняется и движется с той же скоростью
0
Ну по идее он должен на нее реагировать, а для отсечения теней применяются другие методы. Еще при выделении движущихся объектов можно перейти из RGB в YUV или HSV. Там теням будут соответствовать изменения в данном месте компоненты яркости практически без изменений цветовых компонент. Ну и так далее.
+1
В тиории ее надо отфильтровать перед тем как подавать в алгоритм
0
Координаты нового центроида можно найти описав вокруг пикселей кластера прямоугольник и тогда центроидом будет пересечение его диагоналей.
А почему не найти среднее арифметическое координат пикселей кластера для определения координат центроида?
+1
Можно конечно и так, но в посте рассматривался именно прямоугольник для большей наглядности.
0
Наглядность наглядностью, конечно, но центр масс-таки и нагляднее центра некого описывающего прямоугольника, да и корректнее, имхо.
Вот, например, в таком случае:
Центр прямоугольника даст точку A, тогда как реально стоило бы брать нечто ближе к точке B. Суть же в том, чтобы взять точку, «хорошо приближающую» точки текущего кластера.
Вот, например, в таком случае:
Скрытый текст![](https://habrastorage.org/r/w1560/storage2/06f/d2b/e03/06fd2be036ac13403516f42a8a7cf456.png)
![](https://habrastorage.org/storage2/06f/d2b/e03/06fd2be036ac13403516f42a8a7cf456.png)
Центр прямоугольника даст точку A, тогда как реально стоило бы брать нечто ближе к точке B. Суть же в том, чтобы взять точку, «хорошо приближающую» точки текущего кластера.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простейшая кластеризация изображени методом к-средних (k-means)