valbok
разные результаты kmeans
Собственно столкнулся с проблемой. Известно, что результаты kmeans зависят от случаной составляющей. И не смотря на улучшеный алгоритм kmeans++ всё равно выдача разная.
Можно конечно говорить о том, что вероятно точки не являются чем-то целым, поэтому и нельзя их толком сгруппировать, оттого они попадают в разные кластеры.
Но в нашем случае ведь это критично - потому как область, которую вы вырезаем по крайним точкам - меняется от запуска к запуску, пусть и не существенно, но на phash заметно влияет. Ну и резльтаты поиска соотвествующие.
Думал что выравнивание относительно центроида что-то решит (по вашему пути иду), но что-то я не заметил улучшений ((
Давайте может ещё раз обсудим суть фиксированных координат или сторон?
Не помню говорил ли я это, но пришлось отказаться от идеи вырезать картинки по кластерам из-за большого количества ложных срабатываний. Идея была в том, что если изменять количество кластеров, то центройды могут примерно совпасть, обрезать по крайним точкам кластера дает независимость от масштаба.
Но в итоге было куча кластеров и вырезок, и часть из них конечно совпадало. Удалось только придумать как вырезать картинку, чтобы немного уменьшить ложные срабатывания. https://github.com/valbok/img.chk/blob/master/core/hash/extractor.py : 88
В общем, для задачи поиска фрагмента думаю кластеризация не годится. Идея кодировать ORB дескрипторы в phash была более продуктивна. Но как я сказал раньше, можно отказаться от phash вобще, и не терять точность, а использовать четыре 8байтных значений в базе и тогда вся ответственность на поиск соответствия ложится на науку и на ORB.
чтобы немного уменьшить ложные срабатывания
вот тут вот я пытался разобраться по вышеуказанному исходнику, но в чём его особенность? попытка слегка подогнать размеры к кратному числу? что это дает? отсчёт кратности ведется от координаты центроида? но дело в том что если он "слегка" плавает, то и картность будет так же плавать - по крайней мере у меня так - и точность сильно страдает
- отсчёт кратности ведется от координаты центроида?
Ну проблема в том, что вырезаемая картинка бывает и похожа, но ее хеш не совпадает, из-за того что размер плавает, чтобы хоть как-то стандартизировать размер, сделал чтобы дискретно размер формировался. Это дало небольшой прирост точности) Но не удалось придумать ничего другого, картинки все равно получались не совсем едентичные.
но решение есть на самом деле - многократные повторения дают устойчивую картинку, есть кластеры, которые повторяются от вызова к вызову, т.е. если заложиться каким-то процентом совпадений, то можно получить вполне работоспособное решение, но оно затратное по времени и нужно подбирать эти значение - количество повторов, процент совпадения
наверняка можно поиграться параметрами CvTermCriteria кстати о них нужно отдельно поговорить - как обосновать их выбор?
кстати о них нужно отдельно поговорить - как обосновать их выбор?
Немного тестил, не увидел никаких улучшений, на качество кластеризации и фиксации границ не повлияло. Выбрал такие, как в мануале по кластеризации.
а в каком именно мануале?
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)
странно, а почему же нет улучшений?
http://stackoverflow.com/questions/11885751/cv2-kmeans-usage-in-python Да вроде остановился на варианте отсюда) Но было давно, не уверен как влияло на саму кластеризацию и границы кластера.
опять же attemps = 100 https://github.com/valbok/img.chk/blob/master/core/hash/extractor.py#L47
А попытки, на сколько я помню, немного сдвигают границы, я вывел их в параметры, чтобы проверять, остановился на 100, потому что были адекватные результаты. А вообще наверное не особо полезно.