Разработка findcolor, findimage, Pure lua Опции

[DarkMaster]

Хотя чего там тестить.

Ну вот чтобы я не пытался криво втулить свои картинки непонятно куда. Т.е. если там выпадет по времени работы 10 секунд, то смысла все это разгр<вырезано анти-матом> не вижу. Хотя у меня подозрения все есть, что твой код отработает шустро. Если нет, то все равно напишу, просто не так, как хотел. Я _ОЧЕНЬ_ не хочу тулить dll'ки. Возможно именно под сравнение трех массивов придется, но это лично для меня будет большой фейл.

[sutra]

Из кода видно, что чем меньше матрица pic[0][0], тем быстрее будет поиск. НАМНОГО быстрее если лопатить большие зоны. В этом вся и фишка. Хотите скорость - надо напрячь мозги. Лень, ну тогда будет медленнее. Каждый выберет для себя компромисс сам.

Из твоего bmp-шника не совсем понятно как искать. Насколько уникальна картинка, можно искать по красному, можно по зелёному. СМЫСЛ в чём?? Чтобы увеличить скорость, надо понять уникальность картинки. И если например такого ярко красного пикселя нет нигде, кроме как в этой картинке, то можно искать тупо по одному пикселю, а ещё тупее - найти его колором.

Соврал, по одному не получится, а вот по ДВУМ - легко.

И повторюсь. Я могу искать не только значимые пиксели (скажем красные), но и фон. Например посередине от этих двух красных однозначно присутствует светлый пиксель (скажем RGB данного пикселя все значения не менее 100) или например бесцветный пиксель значения RGB отличаются друг от друга не более, чем на 30 единиц. Нет никаких ограничений для фантазии юзера.

Ещё раз повторюсь. Если мне например не нужна скорость, ничего я не делаю, лень ... никаких условий ... задал погрешность и всё. А при желании можно задавать сколь угодно сложно комбинированные условия поиска (по которым и будет создана матрица поиска).

[Madeus]

Ещё раз повторюсь. Если мне например не нужна скорость, ничего я не делаю, лень ... никаких условий ... задал погрешность и всё. А при желании можно задавать сколь угодно сложно комбинированные условия поиска (по которым и будет создана матрица поиска).

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

[cirus]

Я _ОЧЕНЬ_ не хочу тулить dll'ки.

Что это даст? Луа и си сравнимы по скорости. Другие языки явно не ускорят поиск в разы.
fi_large.bmp ищется 4 секунды на i7-7700K 4.20GHz.
Так что надо менять алгоритм поиска.

[sutra]

И вот чтобы искать такие бесцветные пиксели и нужны RED-BLUE , RED-GREEN , GREEN-BLUE

и тут встает вопрос быстродействия "для всех".

Это в принципе невозможно. Скорость и так повысили getimage-м , она вполне себе приемлема и не сопоставима с Пилотовской. Скорость моего алгоритма зависит только от юзера и от мощности его машинки. НО всегда есть маневр, о какой уравниловке может идти речь, её в природе не существует.

[DarkMaster]

Луа и си сравнимы по скорости

Есть у меня сомнения. В любом случае количество пикселей необходимых для проверки не меняется. Каким образом можно проверить не 189 пикселей, а 2 и понять, что это не наше изображение? Старый финд же как-то ищет. Оптимизации накрываются кстати медным тазом, если искать не одно изображение, а все. Никуда не денешься - проверять придется все.

sutra, пожалуйста, прогони через свой алгоритм мои изображения. Девиэйшн можешь поставить минимальынй(но не нулевой) - оттенки идентичные. Какая скорость нахождения изображения fi_large внутри scr? accuaricy 10% - это важно, т.к. вместо 1- пикслей, ему нужно будет обработать не менее 189 на каждую возможную координату в пределах scr.

[sutra]

Хорошо, сейчас попробую, протестирую. Мне по барабану какой девиэйшн, всё будет искаться одинаково. Спазу скажу, ни о каких секундах не может быть и речи. Сейчас попробую.

[DarkMaster]

Что это даст? Луа и си сравнимы по скорости. Другие языки явно не ускорят поиск в разы.
fi_large.bmp ищется 4 секунды на i7-7700K 4.20GHz.

Мой финд: 9.8 сек (только этап сравнения).
Старый финд с методом забора изображения "2": 0.106
Искал 100 изображений, так, что перелопатил он там все. Ну либо старый финд откровенно врет с accuracy либо все-таки где-то косяк. Я склоняюсь ко второму варианту.

[sutra]

Код

--lua
local path=[[A:\МММ]]                                      -- Объявление + инициализация каталога сохранения файлов создаваемых скриптом
local f=require[[Scripts\LUA\fun]]
local p,w,h,l=loadimage([[A:\scr.bmp]])
local PIC=f.CreateFindArray({{[[A:\fi_large.bmp]],r=0,acc=90}},1920)
local k,m
local t1=os.clock()
for i=1,10 do
  k,m=f.FindImage(p,l,0,0,1919,1079,PIC,1)
end
local t2=os.clock()
deleteimage(p)
deleteimage(p1)
log(k)
log(m[1][1],m[1][2])  -- 1874 1039
log(t2-t1)            -- 0.109 сек
 

[cirus]

Брать с искомой картинки первый пиксель и искать его на скрине, если нашёлся, то уже искать саму картинку в этом месте. Если точность не 100%, то брать второй пиксель и снова искать и т. д. пока хватает точности. Для fi_large.bmp этот способ точно будет быстро искать. По сути сначала вызываем findcolor и уже потом используем findimage в найденных координатах.

[sutra]

Это искались ВСЕ голубые пиксели (r=0)

Код чисто для примера, запускать не надо (для новичков), без модуля понятно работать не будет.

[DarkMaster]

Брать с искомой картинки первый пиксель и искать его на скрине, если нашёлся, то уже искать саму картинку в этом месте. Если точность не 100%, то брать второй пиксель и снова искать и т. д. пока хватает точности. Для fi_large.bmp этот способ точно будет быстро искать. По сути сначала вызываем findcolor и уже потом используем findimage в найденных координатах.

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

10 прогонов. хе. Кодом поделишься? Буду искать где проблема...

Еще один маленький вопрос. Не затруднит ли перед непосредственно ифом который весь массив лопатит поставить счетчик? Ну тупо чтобы знать сколько раз этот иф был вызван(вне зависимости от результата истина/ложь).

Это искались ВСЕ голубые пиксели (r=0)

Эмм... Это финдколор получается) А именно имиджем по 3 каналам. Так сказать старой тяжелой артиллерией.

[sutra]

Погоди Дарк. Надо смотреть. Что-то я не доглядел. Не глядя пихнул. Там оранжевые - это что? Паразитные что-ли? или фон?

[DarkMaster]

Погоди Дарк. Надо смотреть. Что-то я не доглядел. Не глядя пихнул. Там оранжевые - это что? Паразитные что-ли? или фон?

Вообще фон серый. Есть два изображения которые я ищу: маленькое fi.bmp - на большом их 4 штуки по углам, второе изображение большо: fi_large.bmp и оно там только в правом нижнем углу. Смысл теста в том, чтобы без хитрожопостей типа 1 канал, исключение фона и т.д. найти fi_large. Левый верхних пиксель фоном не является. Все грубо, базово.

[sutra]

Понял, сорри, не то делал.

local PIC=f.CreateFindArray({{[[A:\fi_large.bmp]],r=0,R=254,fgr=true}},1920) -- 1,154 (10 итераций) всё кроме оранжа

--local PIC=f.CreateFindArray({{[[A:\fi_large.bmp]],r=0,fgr=true}},1920) -- 0.120 (10 итераций)


В любом случае быстрее выходит.

Так large отличается от того что на скрине. Там оранжевый кант в левом углу совсем другой.

[DarkMaster]

Я не спал уже хз сколько, ухожу на отдых в уверенности, что завтра будет понимание и прогресс =)

[cirus]

Брать с искомой картинки первый пиксель и искать его на скрине, если нашёлся, то уже искать саму картинку в этом месте. Если точность не 100%, то брать второй пиксель и снова искать и т. д. пока хватает точности. Для fi_large.bmp этот способ точно будет быстро искать. По сути сначала вызываем findcolor и уже потом используем findimage в найденных координатах.
Это все будет работать пока ты не будешь искать картинок больше, чем есть на экране. Именно поэтому я и вбиваю 100 картинок, когда там она одна. Чтобы увидеть скорость без оптимизаций.

Какая разница? Берём первый пиксель, даже если найдется несколько тысяч таких пикселей на скрине, проверить наличие картинок в этих местах вообще ничего не стоит по времени. Если конечно не искать белый цвет в блокноте. В любом случае не миллиард пикселей проверять. Да, при очень низкой точности искать тоже будет долго, но этого и не требуется.
Может есть ещё какие-то варианты.

В любом случае быстрее выходит.

sutra, где в твоём поиске параметр точности поиска? Поиск при 100% точности в любом алгоритме будет искать быстро.

[DarkMaster]

Там оранжевый кант в левом углу совсем другой.

Какой нафиг другой? Я копипастил о,О

Какая разница?

Огромная разница. Это очень сильно ускорит поиск в случае, когда нужно найти 1 изображение и пофигу где. Когда нужно найти все изображения или, скажем, просто в упорядоченном виде, то начинаются проблемы. Упорядоченность дает конечно не полный перебор, но не без развлечений. А если тебе надо найти 100 изображений, а там только одно, то как ты сможешь исключить позицию, где 188 пикселей подряд идут ошибочные, а потом все нужные? В итоге тот же полный перебор будет.

В любом случае быстрее выходит.

Дай код а... можно в приват...

[sutra]

sutra, где в твоём поиске параметр точности поиска? Поиск при 100% точности в любом алгоритме будет искать быстро.

В моём случае НЕТ РАЗНИЦЫ. Сравнений ровно столько же. дал погрешность +- 20 - результат тот же.

[cirus]

188 пикселей подряд идут ошибочные, а потом все нужные? В итоге тот же полный перебор будет.

Полный перебор двух миллиардов пикселей (1920*1080) или нескольких тысяч возможных мест? Как бы есть разница.