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

[DarkMaster]

Цук вроде буфер доделал... Сколько он у меня крови попил... Зато теперь 1 конвретация фул хд изображения по методу r занимает 36мс, 1000 конвертаций 64мс. В общем генерация изображений по a, r готовы. Осталось накатать таблицу на s (там не изображения) ну и перебор сгенерированных изображений.

[Madeus]

Супер! Ждем! Ну я уж точно! (IMG:style_emoticons/default/laugh.gif)

[DarkMaster]

По сути первый запуск. Ну почти первый. Вроде даже нашло.
Синтаксис почти аналогичен старом финдколору, надо будет чуть-чуть дошаманить.
r = clr.findimage(0, 0, 1919, 1079, {[[image\fi.bmp]]}, 264916 , 90, 1, 1, 'r')
r = clr.findimage(0, 0, 1919, 1079, {[[image\fi.bmp]]}, [[image\scr.bmp]], 90, 1, 1, 'r')

папки пока не жрет, кэш работает на загруженное через getimage и на загруженное финдколором в качестве _искомого_ изображения. Т.е. в примере выше scr.bmp будет автоматически удален из кэша. Где искать. Если искать по ранее загруженному в память изображению, то источник(где искать), должен быть передан в виде таблицы {a, w, h, l}. Таблицы, а не списка. Т.е.:
local t = {1,2,3,4} - правильно
а не
local t = {["a"]=1, ....} -- так не писать. ошибка
если данное изображение получено через getimage, либо "осело в кэше", то w, h, l при вызове можно не указывать. Если захотелось пофантазировать и кодом сгенерировать некоторую картинку, то можно ее отправить указав полный синтаксис {a, w, h, l}.

s метод в финдимидже еще не делал, в колоре не помню, но вроде рабочий.
строгое сравнение тоже не делал еще.

В целом код не прилизан, манов толком нет и т.д. Надо все причесывать и очень сильно.

Сообщение отредактировал DarkMaster - 4.4.2021, 10:44

[cirus]

В ext.findimage нет объявления переменной t.
Если картинка по указанному пути не найдена, то выдаст ошибку.

[Madeus]

В ext.findimage нет объявления переменной t.
Если картинка по указанному пути не найдена, то выдаст ошибку.

это опять тесты скорости были) закоментить вывод логов надо сразу

По сути первый запуск. Ну почти первый. Вроде даже нашло.

При указании deviation_type 'a' ошибка

Код

color1.lua:928: attempt to perform arithmetic on global 'h' (a nil value)

При указании метода 2 ошибка

Код

color1.lua:1153: attempt to index a nil value

А вот со скоростью явно что-то не так:
Игра ищем неизвестное кол-во кнопок старый фаинд ищет так deviation 5 и 15

Код

test = findimage (1151, 377, 1364, 899, {path .. 'Button' .. '.bmp'}, 2, 75, -1, 5)
Speed = 0.055999999996857

test = findimage (1151, 377, 1364, 899, {path .. 'Button' .. '.bmp'}, 2, 75, -1, 15)
Speed = 3.7170000000042

Новый фаинд ищет так

Код

test = ext.findimage (1151, 377, 1364, 899, {path .. 'Button' .. '.bmp'}, 0, 75, -1, 20, 'r', 'abs')
Speed = 0.22499999999127

Самое долгое в браузере Firefox ищем кнопку логина
Старый фаинд

Код

test = findimage (769, 733, 1121, 843, {path .. 'Login' .. '.bmp'}, 2, 80, 1, 1)
Speed = 0.039999999993597

test = findimage (0, 0, 1919, 1079, {path .. 'Login' .. '.bmp'}, 2, 80, 1, 1)
Speed = 0.13400000000547

Новый фаинд

Код

test = ext.findimage (769, 733, 1121, 843, {path .. 'Login' .. '.bmp'}, 0, 80, 1, 1, 'r')
Speed = 0.7780000000057

test = ext.findimage (0, 0, 1919, 1079, {path .. 'Login' .. '.bmp'}, 0, 80, 1, 1, 'r')
Speed = 14.098000000013

14 секунд в фулхд (IMG:style_emoticons/default/smile.gif)

А ну и координаты он все равно возвращает относительно начала координат поиска. Если искать в фул хд вернет то что надо, если указать зону конкретную то вернет относительно ее начала и килкнуть по найденой картинке невозможно. И еще он возвращает 16 найденых картинок что-ли #test == 16, хотя count 1. Старый 1 находит.

[DarkMaster]

это опять тесты скорости были) закоментить вывод логов надо сразу

не закомментил именно для тестов ибо были сомнения в производительности. Не до конца понимаю почему и как так получилось, хотя таких диких цифр у меня не было. Искал 9*9 каринку где-то 0.36 на фул хд. Надо смотреть где тянет вниз. Там, к сожалению, не все так очевидно бывает. Тут прямо место для Cockney, который обязан просто сказать, что мы занимаемся херней и для этого есть другие языки и компиляторы. Мне сложно со всем этим не согласится, равно, как и исключить при оценке выбора языка тот момент, что финды были на протяжении жизни поилота самыми изменяемыми функциями и поддержка при нескольких языках, на мой взягляд, будет неоправдано усложенена. Проще сделать нормально один раз, потом по мере необходимости докручивать какие-нибудь фишки вроде новых типов поиска.

При указании deviation_type 'a' ошибка

Тестовый вариант включен был. Расскоментил рабочий, закомментил тестовый. Второй блок реальный был.

При указании метода 2 ошибка

А вот это на самом деле очень странно ибо getimage я создавал так, что он должен в итоге поставлять одинаковый результат по части формата. Адрес в number, w, h, l и в кэш закидывать. Посмотрю.

А ну и координаты он все равно возвращает относительно начала координат поиска.

То был колор, это имидж) Подручу, там 2 строчки из имиджа скопировать.

И еще он возвращает 16 найденых картинок что-ли #test == 16, хотя count 1. Старый 1 находит.

Забыл.

Ща фиксить буду. Больше всего откровенно пугает скорость. Sutra ты там тут?) В чем косяк fi_compare?

Сообщение отредактировал DarkMaster - 4.4.2021, 19:14

[Madeus]

То был колор, это имидж) Подручу, там 2 строчки из имиджа скопировать.

Прогнал еще раз findcolor твой, в фул хд возвращает корректно, в указанной области возвращает относительно начала координат поиска, версия последняя с фиксами, где нет еще findimage`a

[Cockney]

Тут прямо место для Cockney, который обязан просто сказать, что мы занимаемся херней и для этого есть другие языки и компиляторы.

А что я ? Молчу-молчу. Вы наверняка лучше знаете и понимаете как реализовать потенциал lua. Могу только заметить, что лучше сначала собрать базу аномалий и фиксить уже после того как у всех стабильно будет все находиться. В конце концов jit смотрит на возможности процессора при компиляции, и кто знает что он генерирует.

Вообще, не стоит наказывать самих себя) Заведите гит репозиторий, отводите ветки и смотрите что лучше/хуже работает. Так вы не будете ходить по одним и тем же граблям. Как минимум коллективно.

[cirus]

DarkMaster, а ты уверен что у пилотного findimage поиск просто перебором? С маленькими картинками может и будет быстро искать, но чуть побольше уже сомнения. К примеру возьмём картинку 40*25, 1000 пикселей, при 50% точности нужно проверить половину, т. е. 500 пикселей чтобы понять что в проверяемом месте картинка не найдётся. Т. е. для FullHD 1920*1080*500 больше миллиарда пикселей надо проверить.

[DarkMaster]

DarkMaster, а ты уверен что у пилотного findimage поиск просто перебором?

Я уверн. Уверен, что нет =) Мне известна, как минимум одна оптимизация, но на тестовых изображениях я специально создаю условия, чтобы она не работала. В целом она достаточно сомнительна для меня на самом деле. Если быть точнее, то она будет работать в плюс только в определенных ситуациях.

[DarkMaster]

Хз. Переделал на ffi.cast по адресам - разницы особо не увидел... Недопонимаю в чем проблема.

[DarkMaster]

Вобщем у меня тесты на фул хд и искомом изображении 46*41. Искомое изображение в одном экземпляре в правом нижнем углу, т.е. находится в самом конце. При 90% точности время поиска занимает 10 секунд. Во время тестов выяснелось следующее... Каждый новый счетчик добавляет примерно 0.5 сек, само условие со вложенной проверкой на достаточность количесво пикселей занимет 9 секунд. Если выкинуть проверку на достаточность пикселей, то время выполнения сокращается на 5 секунд.
Что со всем этим делать пока не понятно... Если выкинуть весь хлам и оставить один счетчик, то выполняет мгновенно...

[Madeus]

Вобщем у меня тесты на фул хд и искомом изображении 46*41. Искомое изображение в одном экземпляре в правом нижнем углу, т.е. находится в самом конце. При 90% точности время поиска занимает 10 секунд. Во время тестов выяснелось следующее... Каждый новый счетчик добавляет примерно 0.5 сек, само условие со вложенной проверкой на достаточность количесво пикселей занимет 9 секунд. Если выкинуть проверку на достаточность пикселей, то время выполнения сокращается на 5 секунд.
Что со всем этим делать пока не понятно... Если выкинуть весь хлам и оставить один счетчик, то выполняет мгновенно...

Ни че не понял, но очень интересно (IMG:style_emoticons/default/biggrin.gif)
У меня кол-во секунд не складывается...

[sutra]

Всем Гуд! Дарк, у меня не было времени тестить новые фишки. Да и надоели мне все эти тесты, я собственно говоря - практик, мне интересно смотреть методы, которые вы используете, чтобы потом использовать их самому. Я не большой сторонник МЕГА проектов. На мой взгляд лучше сделать несколько функций (old, new или вообще дать функциям новые имена), чем всё запихивать в одну. На мой взгляд ты торопишься с "похоронами" имеющихся финдов. Давай для начала сделаем loadimage, чтобы хоть какая-то была работоспособность, а уж потом хоронить всё старое. Да и saveimage я бы доработал. Ну для себя точно буду переделывать. Мне нужно, чтобы сохранялся в файл не ВЕСЬ образ, а его конкретная зона. Ну вот пример практика ... Сделал образ ... поискал одно ... поискал второе ... а на третьем, что-то пошло не так и мне было бы намного удобнее сохранить в файл именно эту область, чтобы потом не шариться в редакторе высчитывая координаты.

[sutra]

По поводу финдимиджа стандартного (текущего). Я давным-давно от него отказался. Я не знаю причин, но там просто убийственные тормоза, если увеличиваешь deviation. У моего варианта нет никаких зависимостей от этого параметра. У меня зависимость только от параметра accuracy и это понятно, потому что поиск выполняется до превышения "ошибок". Я использую 3 параметра: погрешность (deviation) нужна при малых значениях RGB, точность (% отклонения цвета) и аккуратность (похожесть картинки) если например часть картинки перекрыта другой картинкой.

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

Проще говоря создаётся матрица {X,Y,R1,R2,G1,G2,B1,B2} и ищется эта самая матрица. Если подсунута не матрица, имидж создаёт её сам, а если нет использует подсунутую. В большинстве случаев, особенно критичных к скорости, используются уже именно готовые матрицы. Они загружаются у меня при старте из бинарного файла и всё летает на ура.

Для меня задача №1 loadimage. Без него никак не обновиться по полной программе. Думаю сам проковыряюсь долго, хотя вроде общие принципы мне понятны.

Чтобы было понятнее про матрицу. Ну вот например поиск цифр 7 и 2 осуществляется поиском (сравнением) всего 2-х пикселей. У семёрки 2 крайних верхних, а у двойки 2 крайних нижних, надеюсь понятно объяснил.

[DarkMaster]

На мой взгляд лучше сделать несколько функций

Можно сделать их вообще миллион и катать велосипед каждый раз по новой. Смысл подобных функций в унификации в первую очередь. И переписывается это все по 10 раз именно потому, что в ходе работы приходить осознание правильной концепции.
В частности ты хотел получить разницу каналов в финдах. Сейчас есть некоторый "остов" для этого. Т.е. там по большому счету нужно добавлять только непосредственно маленькую функцию, которая пояснит какой канал куда пихать. В этом как раз вся идея - масштабируемость.

Давай для начала сделаем loadimage, чтобы хоть какая-то была работоспособность, а уж потом хоронить всё старое.

Я его собирался переписывать, но после финдов ввиду того, что текущий типа и так работает, а при включенном буфере вообще пофигу, как он работает. Грузится 1 раз, больше к виниту обращений не будет.

Да и saveimage я бы доработал. Ну для себя точно буду переделывать. Мне нужно, чтобы сохранялся в файл не ВЕСЬ образ, а его конкретная зона.

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

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

Я верю в то, что это очень эффективно. Вопрос в том какое количество людей сможет этим пользоваться =) У меня есть свой взгляд на то, как вообще подобный код должен формироваться. По большому счету лично мое мнение, что картинка, которая будет использоваться в поиске должна генерироваться, области задавться руками, по дефолту с нулевым разбегом от позиции изображения и т.д. Человек должен достаточно просто и быстро создавать подобные вещи, а многие аспекты обработать в ручную нереальный по затратам времени труд. У меня стоит 3 задачи:
1) Закрытие текущих багов и необоснованных тормозов.
2) Создание кода, который может свободно использоваться в последующем для создания скриптов. И использоваться не каким-то гуру и не через Ж.
3) Перевод на луа и после создания определенной основы (вектор задать, если угодно), получить свободно расширяющиеся модули пользовательские с централизованным распространением. Это одна из причин, почему пока я хочу кодить один. Садиться и писать подробные тз у меня желания нет, получить франкенштейна, когда каждый писал, как хотел я тоже не имею желания.

[DarkMaster]

Проще говоря создаётся матрица {X,Y,R1,R2,G1,G2,B1,B2} и ищется эта самая матрица. Если подсунута не матрица, имидж создаёт её сам, а если нет использует подсунутую. В большинстве случаев, особенно критичных к скорости, используются уже именно готовые матрицы. Они загружаются у меня при старте из бинарного файла и всё летает на ура.

У меня предельно похожая схема. При загрузке файла он падает в буфер, при вызове финдимиджа с некоторым девиэйшеном генерируется 2 массива по своей структуре являющиеся корректными bitmap. В одном минимально допустимые значения во втором максимально допустимые. В итоге идейно все должно заканчиваться сличением трех массивов-битмапов "некторый скрин", "максимальный искомый", "минимально искомый". Ну и дальше идет попиксельно сравнение
min<скрин<max
Эти сгенерированные изображения с отклонениями так же падают в буфер и повторно не создаются для тех же параметров deviation.

Для меня задача №1 loadimage. Без него никак не обновиться по полной программе. Думаю сам проковыряюсь долго, хотя вроде общие принципы мне понятны.

Я в нем проблемы вообще не вижу. Честно. Проще сделать "обрезалку", которую все равно делать. И в эту обрезалку загонять адрес битмапа в оперативке, а не на винте. С винта лоад дергат вполне нормально.

Чтобы было понятнее про матрицу. Ну вот например поиск цифр 7 и 2 осуществляется поиском (сравнением) всего 2-х пикселей. У семёрки 2 крайних верхних, а у двойки 2 крайних нижних, надеюсь понятно объяснил.

Это вопрос создания подобных изображений. Сравнивать то их чем-то все равно нужно, а создают зачастую ломти до 25*25 пикслей (в среднем). 2 пикселя и текущий вариант быстро сравнит. Видимо придется разгр<вырезано анти-матом> твой код сравнения. Честно скажу - писал больше с нуля ибо чужой код и не самый простой кусок. Учитывая полученные проблемы с производительностью надо смотреть, что у тебя получается.

Можешь на своем текущем коде в твоей реализации сделать поиск изображения 40*40 в фул хд и точностью 90%? Хочу понять насколько разница в производительности. На моем очень древнем железе получалось около 830млн пикселей в секунду.

[sutra]

Вопрос в том какое количество людей сможет этим пользоваться

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

А почему сейчас про это вспомнил. Сам принцип (внутренней обработки, не для пользователя), ну он ведь в принципе такой же как у тебя. Задаются просто границы поиска RGB, и потом элементарный перебор с минимумом математики внутри.

Хорошо, потетстю на твоей картинке с мишенями и скажу что и как. Надо тока найти её, вроде ничего не удалял.

[DarkMaster]

Мое текущее безобразие.

По поводу не надо было... Одно дело надо, другое возможность. Иногда кушать еще надо( Возможность появилась, я занимаюсь. И ты сразу, как почуял)

[sutra]

Хотя чего там тестить. Просто кину кусок кода который собственно и ищет, всё по минимуму. Чисто для примера, сорри без комментов, с кривыми именами переменных. Сделано давно и просто лень было облагородить.

Код

      while y<ye do
        while x<xe do
          for i=1,pic[0][0]do     -- pic - матрица
            n=ins+pic[i][6]
            if a[n][v1]<pic[i][v1]or a[n][v1]>pic[i][V1]or a[n][v2]<pic[i][v2]or a[n][v2]>pic[i][V2]or a[n][v3]<pic[i][v3]or a[n][v3]>pic[i][V3]then
              j=j+1 if j>sim then  sr=false  break  end  -- sim аккуратность
            end
          end
          if sr then  af[k],k={x,y/wi},k+1  if k>numf then  return k-1,af  end  end
          x,sr,ins,j=x+1,true,ins+1,0
        end
        x,y,ins=0,y+wi,ins+pic[0][2]-1
      end