|
|
|
Разработка findcolor, findimage, Pure lua |
|
|
sutra |
4.5.2021, 17:33
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Cockney. Попробовал бенчмарк. С координатами точно какая-то проблема. Инфо из лога. Screen width: 1920 Screen height: 969 Pattern width: 27 Pattern height: 28 ... Findimage processing time: 228[ms]
Found: 22 X: 910, Y: 255, accuracy: 100 X: 1918, Y: 962, accuracy: 100 X: 1918, Y: 963, accuracy: 100 X: 1917, Y: 964, accuracy: 100 ... картинку нашёл правильно ПЕРВУЮ, а вот почему ещё нашлось 21. Что интересно, действительно всего 22 картинки, но они сильно отличаются друг от друга.
Свой финд представлю однозначно позже. С этими праздниками времени нет совсем.
|
|
|
|
Cockney |
4.5.2021, 19:40
|
Master
Сообщений: 1.394
Регистрация: 22.6.2013 Группа: Пользователи Наличность: 20894
Пользователь №: 16.156
|
Можно картинки, на которых проводился запуск ? Вообще, ситуация, когда за результат считаются подобные координаты Цитата X: 1918, Y: 962, accuracy: 100 X: 1918, Y: 963, accuracy: 100 X: 1917, Y: 964, accuracy: 100 по сути побочный эффект того, что область поиска смещается на 1 вправо и на 1 вниз на каждой итерации, т.е. вполне вероятна ситуация, что на очередной итерации мы проверяем тот же участок, только меньше на 1 сверху и на 1 слева, но основная масса пикселей та же самая. Я это регулировал точностью, т.е. условно находится 19 изображений с точностью 90 и одно с точностью 97 - это то что нам и нужно. Не знаю на сколько это верно, но другого способа найти ВСЕ изображения я пока не придумал. Да и собственно на сколько помню, пилот примерно так же себя ведет, если искать с маленькой точностью. В приведенном логе странно, что найдено это все с точностью 100. Надо ковырять, смотря на картинки.
|
|
|
|
cirus |
4.5.2021, 20:18
|
Elder
Сообщений: 3.480
Регистрация: 18.8.2014 Группа: Пользователи Наличность: 26576
Пользователь №: 16.971
Возраст: 29
|
Цитата странно, что найдено это все с точностью 100 Если искать чёрный квадрат 4*4 на чёрной картинке 5*5, то будет найдено 4 картинки со 100% точностью. Просто надо отсеивать лишние результаты. Те, что с меньшим процентом сразу можно исключить. Из оставшихся исключить те, которые находятся чуть ниже и правее, учитывая ширину и высоты картинки. Например, если искомая картинка размером 10*5 и нашлась в координатах 300 400, то все картинки от 300 до 310 по X и от 400 до 405 по Y лишние. Отсеивание это отдельная опция должна быть, с возможностью указать расстояние, при котором картинки удаляются из результата поиска. Хотя, это всё и так можно сделать в виде отдельной функции.
|
|
|
|
Cockney |
4.5.2021, 20:31
|
Master
Сообщений: 1.394
Регистрация: 22.6.2013 Группа: Пользователи Наличность: 20894
Пользователь №: 16.156
|
Цитата(cirus @ 4.5.2021, 20:18) Если искать чёрный квадрат 4*4 на чёрной картинке 5*5, то будет найдено 4 картинки со 100% точностью. Просто надо отсеивать лишние результаты. Те, что с меньшим процентом сразу можно исключить. Из оставшихся исключить те, которые находятся чуть ниже и правее, учитывая ширину и высоты картинки. Например, если искомая картинка размером 10*5 и нашлась в координатах 300 400, то все картинки от 300 до 310 по X и от 400 до 405 по Y лишние. Отсеивание это отдельная опция должна быть, с возможностью указать расстояние, при котором картинки удаляются из результата поиска. Хотя, это всё и так можно сделать в виде отдельной функции.
sutra говорил вроде про сильно отличающиеся картинки, но ладно. По поводу отсеивания: а если при заданной точности 90 было найден набор с точностью от 91 до 100, т.е. все подходят под этот критерий ? Ну, если требуется найти одну, то да, легко выбрать, а если все возможные ? Реальна же ситуация, когда одна картинка залезает на другую ? Как тогда быть ? А, дочитал сообщение. Да, как вариант - функция отсеивания, но с другой стороны, а чем текущий вариант с установкой точности выше/ниже не устраивает ? Результат тот же (вроде).
|
|
|
|
sutra |
6.5.2021, 14:47
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Коллеги, я очень сильно извиняюсь. Ввиду того, что не пользовался стандартным финдом, просто опять не доглядел. Это по поводу того, что стандартным финдом не будут искаться "тёмные" пиксели. Будут, ещё как будут. Там суть deviation - это по сути АБСОЛЮТНАЯ погрешность, просто её абсолютность измеряется процентами от значения 255. Но по факту - это тоже плохо, относительная погрешность (% от значений каналов конкретных пикселей) зачастую куда важнее. Ну а правильнее всего конечно же сочетать и то и другое, что я и делаю. "Дорисовываю" описание финда (с примерами), дождитесь - выявились интересные факты.
|
|
|
|
Cockney |
10.5.2021, 23:33
|
Master
Сообщений: 1.394
Регистрация: 22.6.2013 Группа: Пользователи Наличность: 20894
Пользователь №: 16.156
|
За почти неделю размышлений так и не понял как это все работает. Изначально на примере cirus находились все 5 изображений, причем быстро ~0.02с, в тот же момент пример sutra выдавал в лучшем случае 8 найденных изображений при времени >30с. Но то был перебор пикселей с некоторыми оптимизациями на математику. Как я не менял подход, выходило что работает либо на данных cirus, либо на данных sutra. Ни точность, ни отклонение ничего не давали. Поменял алгоритм. Ищет точечно, без перебора. Теперь ищет на данных sutra все 17 монеток без звездочек за ~0.1с при точности 90 и отклонении 30, а на данных cirus примерно 15 картинок (перекрытие координат, без отсеивания, но в целом, находятся все) при временных затратах - 1.5 секунды, точности 96, отклонении 34. При точности 90, отклонении 30 не находит ничего. В чем проблема такой просадки по скорости остается загадкой.
|
|
|
|
sutra |
14.5.2021, 17:24
|
Adept
Сообщений: 923
Регистрация: 10.8.2018 Группа: Пользователи Наличность: 0
Пользователь №: 19.007
|
Да. В очередной раз сильно затупил. Дело в том, что то, что я предложил - это переделка на новые рельсы того алгоритма, который был у меня раньше. На кой я делал эти битовые маски я и сам не знаю. Переделал финд. Теперь GetImage и LoadImage сразу формируют уже готовый массив каналов для всех пикселей рисунка. Скорость выросла ровно в 4 раза, так всё делается напрямую, без memcpy. На тех же картинках, все 22 картинки золота теперь ищутся за 5 тысячных секунды, а до этого было 2 сотых секунды. Теперь всё хранится в 4-х уровневой матрице CI [bm] [y] [x] [ch] - номер рисунка, ордината, абсцисса, номер канала. Теперь никакой длины строки пикселей нет нигде в принципе. В общем концепцию я описал, код цикла, чисто для понимания прилагаю. код
Код while y<hF do -- цикл по высоте зоны поиска while x<wF do -- цикл по ширине зоны поиска for i=1,kk do -- цикл поиска искомых пикселей картинки local iy,ix=pic[1][i][0]+y,pic[1][i][1]+x if CI[bm][iy][ix][v1]<pic[2][i][v1]or CI[bm][iy][ix][v1]>pic[2][i][V1]or CI[bm][iy][ix][v2]<pic[2][i][v2]or CI[bm][iy][ix][v2]>pic[2][i][V2]or CI[bm][iy][ix][v3]<pic[2][i][v3]or CI[bm][iy][ix][v3]>pic[2][i][V3]then j=j+1 if j>sim then sr=false break end -- увеличение счётчика пропущенных пикселей -- если превышение нормы - картинки тут нет, искать далее end end if sr then -- картинка найдена af[k],k={x,y},k+1 if k>nP then return k-1,af end -- зарисовали координаты в результируемый массив -- если нашли столько сколько нужно - возврат if shiX>0 then x=x+shiX shi=true end -- если требуется сдвиг (шаг) поиска следующей -- двигаем, правим индекс, ставим флаг работы по высоте if shiY>0 then shi=true end end x,sr,j=x+1,true,0 end x,y=x1,y+1 if shi then y=y+shiY shi=false end -- если нужен сдвиг поиска по высоте - двигаем, далее попиксельно end
Переделывать описание под новые финды нужно время. У меня просто возник вопрос, а надо? Насколько я понял интерес к моей "стряпне" минимален.
|
|
|
|
|
|
11 чел. читают эту тему (гостей: 11, скрытых пользователей: 0)
Пользователей: 0
|
|