разные результаты kmeans

[vinnitu]

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

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

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

Думал что выравнивание относительно центроида что-то решит (по вашему пути иду), но что-то я не заметил улучшений ((

Давайте может ещё раз обсудим суть фиксированных координат или сторон?

[valbok]

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

Но в итоге было куча кластеров и вырезок, и часть из них конечно совпадало. Удалось только придумать как вырезать картинку, чтобы немного уменьшить ложные срабатывания. https://github.com/valbok/img.chk/blob/master/core/hash/extractor.py : 88

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

[vinnitu]

чтобы немного уменьшить ложные срабатывания

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

[valbok]

• отсчёт кратности ведется от координаты центроида?

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

[vinnitu]

да, я же об этом и говорю )

[vinnitu]

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

наверняка можно поиграться параметрами CvTermCriteria кстати о них нужно отдельно поговорить - как обосновать их выбор?

[valbok]

кстати о них нужно отдельно поговорить - как обосновать их выбор?

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

[vinnitu]

а в каком именно мануале?

https://github.com/valbok/img.chk/blob/master/core/hash/extractor.py#L62 (1, 10) https://github.com/Itseez/opencv/blob/master/samples/cpp/kmeans.cpp#L57 (10, 1.0) http://robocraft.ru/blog/computervision/1061.html тут cvTermCriteria(CV_TERMCRIT_EPS+CV_TERMCRIT_ITER, 10, 1.0)

странно, а почему же нет улучшений?

[valbok]

http://stackoverflow.com/questions/11885751/cv2-kmeans-usage-in-python Да вроде остановился на варианте отсюда) Но было давно, не уверен как влияло на саму кластеризацию и границы кластера.

[vinnitu]

опять же attemps = 100 https://github.com/valbok/img.chk/blob/master/core/hash/extractor.py#L47

[valbok]

А попытки, на сколько я помню, немного сдвигают границы, я вывел их в параметры, чтобы проверять, остановился на 100, потому что были адекватные результаты. А вообще наверное не особо полезно.