Помогите освоить LUA Опции

[DarkMaster]

скрипт должен быть неубиенным

В рамках одной вкладки слабо реально. Например, в случайный момент времени может вылезти дисконнект или крашануть клиент. Тогда в каждый цикл придется помещать проверку. Чтобы избежать этого маразма я создаю доп вкладку для контроля. В луа на данный момент не на 100% красиво можно использовать, т.к. доступа к переменным соседнего скрипта нет. Я создавал счетчик который увеличивал значение при успешном прохождении какой-либо части скрипта, на основании которого можно было суди о зависании скрипта в некотором месте. Дальше соответственно скриншот, кил процесса, перезапуск. Сейчас это можно только через файл, либо через сокеты/com порты и городить подобный огрод я не хочу. Но вцелом контроль рабочий.

Вопрос про камеру - уже более 2 тыс. просмотров, вопросы иного плана, в данной теме - видимо не так интересны.

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

Согласен - утомляет. Идеал - иллюзия. Поиск идеала - бесконечность.

А еще есть состояние "оно просто работает". Вот этого неидеального состояния зачастую достаточно в данном конкретном случае. Вопрос в том, что "рабоает" зачастую упирается либо в производительность либо в функционал.

Я верю - он сделает компиляцию и все проблемы по скорости останутся в прошлом.

Компиляция не повлияет на финды существенным образом, т.к. они уже откомпилированы. Повлиять это может только на время парсинга параметров.

[sutra]

Сейчас это можно только через файл

Ну конечно через файл. Проверок действительно очень много, почему и очень неудобно, что нет continue. Мне приходится в разных местах контролировать зависание. Раньше была серьёзная проблема, изголялся так, что сам удивлялся как это всё работает без потери скорости. Сейчас в lua проблема испарилась сама собой. Там где надо "рисанул" экран в память, если за отведённое время экран не изменился, значит приплыли ... и на перезагруз браузера.

Ну теперь по делу. Для начала чисто синтетический тест. Поиск выполнялся среди 9000 картинок размером 500х500. Картинки - пустышки, все одинаковые. В общем анализировались все пиксели от первого до последнего. Итак на медленном поиске (потом объясню что это) 11,193 сек. На быстром поиске - 3,887 сек.

Теперь про реальный тест. Абсолютно реальные картинки, размером 64х40, 20-60% фона, достаточно тяжёлые для поиска условия.

Код

tmc=os.clock()
nnn,rrr=-1,-1
for z=1,1000000 do
  for j=0,3 do
    for i=1,8 do
      if 1==ImageCompare(p,l,455,915, 686,921,749,960,D[j][i], 192,25, 1) then
        nnn=j rrr=i break
      end
    end
    if nnn>-1 then break end
  end
end
log(os.clock()-tmc)
log(nnn,rrr)  -- найдена картинка с индексом [3][8]

При быстром поиске : 0.464 сек. Итого = 0,000000464 сек.
При медленном : 1.152 сек. Итого = 0,000001152


Как раз имитация реального поиска. Типа разный регистр и разный алфавит если применять к тексту.

Код

local function ImageCompare(pg,lg,scrX,scrY,fx1,fy1,fx2,fy2,pl,ll,dev,ch)
  local ci,x,indg,raz=(fx2-fx1+1)*3,0,pg+(fy1-scrY)*lg+(fx1-scrX)*3
  for y=fy1,fy2 do
    while x<ci do
      raz=rmem("unsigned char*",indg)[x]-rmem("unsigned char*",pl)[x]
      if raz~=0 then
        if raz>0 then  if raz>dev then  return 0  end
          else  if raz<-dev then  return 0  end
        end
      end
      x=x+ch
    end --until x>ci
    indg,pl,x=indg+lg,pl+ll,0
  end
  return 1
end----------------------------------------------------------------------------

Ну и собственно сам нехитрый базовый код.

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

Теперь про параметры. Главный ch - может задаваться 1,2,3 . Если 1 - поиск по всем каналам - самый медленный, но самый надёжный, 2 - по 2 каналам и 3 - только по каналу BLUE.

Реально не нашёл ни одного случая, когда бы некорректно работал быстрый поиск. Если только специально подсовывать Малевича с изменённой окраской.

pg, lg - адрес и длина строки образа, что даёт getimage
scrX,scrY - координаты левого верхнего угла образа, то что задаём в getimage.
Далее координаты поиска - абсолютные относительно окна.
pl,ll - адрес и длина строки картинки (убрал её вычисление из функции, чтобы не тормозить поиск, при желании можно вставить во внешнюю обёртку)
dev - аналог deviation - разность каналов между искомыми пикселями.

Ремарочка осталась от репита, но тогда надо уменьшить на единичку ci

Реально перепробовал кучу вариантов - короче, чем проще, тем лучше. Быстрее вряд ли можно сделать, только если Дарк забубенит что-то нереальное.

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

[DarkMaster]

размером 64х40, 20-60% фона,

Фон статичный или нет? Если фон статичный, то это не жесткие условия. Если фон постонно меняется (объект на прозрачной положке) - тогда будет тяжело. Если же фон статичный, то зачастую это наобот позволяет более жестко распознавать, т.к. при статичном фоне можно задирать deviation без рисков.
Кстати по поводу фона. Макрикровка фона в изображениях планируется? Это помимо того, что позволяет исключить несущественные детали, но и может существенно увеличить скорость при поиске изорбражений с большим фоном, т.к. весь этот набор пикселей просто не будет обрабатываться.

[sutra]

dev-ом очень эффективно можно играть, у меня неплохо ищет в самых разных случаях.

Фон статичный или нет

Не совсем, но там максимум +- 10 разница. По барабану фон.

Если фон постонно меняется

Не могу ничего сказать, но если фон есть, значит есть отличия от буковки. Играть dev-ом - НАЙДЁТ.


Проблема не в фоне, а в том что символ плавает. И реально универсально можно только действительно подсчётом значимых пикселей отличить.

Я уже говорил, ну вот даже циферка "1" Да плавает так, что хрен отличишь, проще сделать 2 картинки.

Ищет быстро, перелопатить можно чего угодно мгновенно. То есть функционал есть - это главное. Ну если юзер ленивый и тупой, я ему не помощник, тут только Кнайт... (IMG:style_emoticons/default/biggrin.gif)

[DarkMaster]

Не могу ничего сказать, но если фон есть, значит есть отличия от буковки. Играть dev-ом - НАЙДЁТ.

Найди Х (скажем, это прицел), на фоне от 0x000000 до 0xFFFFFF.

[sutra]

Конечно если чат, на постоянно меняющемся фоне, тут не знаю, надо смотреть. У меня такой задачи не стоит, поэтому убивать время не стану. Появится задача - решу. А пока и так нормуль.

Найди Х (скажем, это прицел),

Хорошо, попробую.


Блин, лень тыкаться, напиши на нормальном RGB про фон.

Ну уж прицел бы я искать стал колором, без проблем, на ЛЮБОМ на фиг фоне.

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

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

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

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

[sutra]

Резюмируя. У меня была задача. Я её решил. Быстрее, только если как ты говоришь используя потоки или cuda. Но мне быстрее не надо и так на выходе всегда НУЛЬ потраченного времени. getimage быстрее работать не станет, а это единственный фактор, который влияет на конечный результат по скорости.

У себя текст я распознаю колором, абсолютно точно 100%, точно так же мгновенно. Так и останется, зачем мне тащить кучу картинок, если всё и так чудно работает. И кстати, там нет 10 вариантов. Не помню, но вроде не более 7 вариантов при всех комбинациях символов.

[DarkMaster]

Фон:
0-255
0-255
0-255
Искать красный крест.
Точно такой же цвет используется в подсветке целей, по центру экрана и т.д.
Скрин чуть позже смогу дать (IMG:style_emoticons/default/smile.gif)

[sutra]

Ну задача то всё-таки была сравнивать картинки, а не искать их. Так и обозвал СРАВНЕНИЕ , а не ПОИСК. Искать надо по другому алгоритму. Нужен красный цвет, так его и надо искать, пропуская всё остальное по боку. Ну запихай в память нули, если там не красный пиксель и сравнивай потом картинку - найдёт. Взял образ, подправил его и сравнивай.

Кстати вопрос, а как записать в память? wmem?

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

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

[DarkMaster]

Кстати вопрос, а как записать в память? wmem?

rmem - это вообще моя фантазия) Это просто переименованная функция ffi.cast.
Т.е.:
local ffi = {}
ffi.cast = function() ... end
local rmem = ffi.cast

За исключением того, что ffi объявлен не нами, а встроен в luajit и подгружен через require. Ну а так смысл тот же самый.

"wmem" в данном случае будет обычным присвоением. Lua по идее сам должен сориентироваться и тип данных подправить (конвертнуть).

Так и обозвал СРАВНЕНИЕ , а не ПОИСК. Искать надо по другому алгоритму.

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

[sutra]

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

Надо так и делать SpeedFind SmartFind.

Как я понял есть 2 основных задачи. Работа с фоном и поиск значимых пикселей. Ну про фон я уже сказал, нужна предварительная обработка образа (можно сделать его копию). Вторая задача однозначно должна решаться иной функцией. Что я и добивался от Кнайта. Если задан параметр аккуратности, то из внешней обёртки должна вызываться ДРУГАЯ функция, чтобы не портить скорость базовой.

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

Получить и скорость и универсальность не получится, по крайней мере тем инструментом что есть, только если ты разберешься с cuda. Как вариант можно сначала попробовать поискать быстрым способом, а вот если не нашло, тогда включать дополнительные мозги и искать с другими параметрами. Сложно сделать конечный продукт для юзера. Но поскольку я сам юзер, то мне это не нужно. Я наоборот подстраиваю всё под собственные условия.

По ходу у Кнайта примерно так и реализовано, почему и скорость начинает падать при увеличении dev . Но ведь опять же, параметры то задаёт юзер, а мы вроде уже определились, что юзер по определению тупой, а он должен чесать репу с какими же параметрами искать. Тут по логике вообще эти параметры не должны задаваться, а должны выдаваться, мол картинка найдена, но вероятность 70% - так хоть какой-то реализм будет и обмана никакого, что нашли, то и показали.

И опять же, вот найдена картинка с вероятностью 80% - это как? Ответа то нет. 80% - это найдена или нет. 20% что нет. Бред короче. Вся эта процентовка очень ненадёжная вещь.

Это не мой путь, во всяком случае применительно к игре. Всё должно искаться 100%. Никакой иной результат меня не устраивает.

[sutra]

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

[DarkMaster]

Запихивать всё в одну нецелесообразно.

Поэтому я выше и предложил сделать форк.

Получить и скорость и универсальность не получится

Это неизбежно - любой комбайн медленее аккуратно заточенной функции. Лишние проверки, сочетания проверок и т.д. Тут разве что стоит молится на jit, чтобы он проигнорировал лишние if'ы, но это все достаточно шатко и валко. Вообще не в пилоте когда я тестил jit он вообще выкидывал не несущие полезной нагрузки конструкии. Т.е.:

Код

local t = os.clock()
for i = 1, 1000000 do
    local j = i + 1
end
print(os.clock() - t)

и

Код

local t = os.clock()
print(os.clock() - t)

Выполнялись с одинаковой скоростью. Вот такой вот он jit.

только если ты разберешься с cuda

Есть желание и большое. Основная проблема будет скомпилить это под винду. Это процес похлеще, чем запуск последней игрушки под wine в linux.

И опять же, вот найдена картинка с вероятностью 80% - это как?

Это значит, что количество пикселей равное 80% совпало. С учетом dev естественно.

Есть конкретная задача - должно быть конкретное решение.

Это конкретное решение может осуществлятсья через вмеру универсальный инструмент. На данный момент это финд. Который кнайт сейчас точно трогать не будет потому, что 100% следит за этой темой, улыбается и ждет, что из этого всего выйдет (IMG:style_emoticons/default/tongue.gif)

[WKnight]

(IMG:style_emoticons/default/blush2.gif)

[sutra]

Всё так, всё верно. И всё-таки, ещё раз про текст. Я однозначно придерживаюсь мнения, что это отдельная тема. И значит, либо должен быть параметр, типа искать текст, либо отдельная функция. Здесь надо опять же различать задачи. Вариант 1): Мы ловим всё одним заходом (учитывая как плавают буковки) или всё-таки по типу поиска картинки (несколько вариантов картинок). Второй вариант настолько прост, что даже обсуждать нет смысла. Насколько я понял - планы Наполеоновские, искать на любом фоне, ну тогда уж и любым цветом. Не вопрос, что мешает разделить понятие фона? Пусть будет фон1 и фон2 для образа и картинки соответственно. Нашли фон (хотя может не хуже его задавать юзеру). Задали погрешность (именно фона, для каждого), причём тут действительно нужна относительная погрешность (для каждого из каналов вычислится своя). И вперёд. Смотрим по строкам пикселей (именно по строкам и ни как иначе). Нашли НЕ ФОН - записали в блокнотик плюсик. Затем сравниваем сколько плюсиков нашли в образе и сколько в картинке. Отличие более 1 (тут тоже есть вариант типа 1,5 - это отдельная тема для большей точности), значит не то нашли. Нет отличий (или почти нет), значит количество значимых пикселей идентично. Если на всех строках всё идентично - нашли то, что надо. На любом фоне, любым цветом. Вот только у меня сразу возникает вопрос, а зачем тогда нужны картинки, если я и так могу задать количество значимых пикселей для каждого символа. Очень грубо (у меня намного проще, так как я не морочился про фон), но я именно так и делаю, без всяких картинок.

[sutra]

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

[sutra]

Теперь про погрешность. В базовом варианте конечно всё примитивно (но быстро). Но по уму погрешность должна считаться для каждого канала индивидуально. Иначе говоря, есть пиксель 100 200 200 - и разница погрешности должна быть к примеру +- 10 20 20 . В общем не абсолютная, а относительная, тогда легко ловятся например картинки, которые оказались например затенёнными (там стандарт типа -20%). Но если я буду такое делать - однозначно запихну в отдельный алгоритм.

Да, про фон что ещё хотел сказать, хотя уже краем касался этой темы. А если есть картинки, которые обозначают одно и то же, но разное состояние. Самый примитивный момент выбрана она или нет, хотя могут быть варианты и с 3-мя фонами. Как мы будем их искать? Если мы не учитываем фон, то будут найдены ВСЕ. Так что господа - чешите репу. Не получится у вас думать за всех, ну только если мы прикрутим к Пилоту IQ.

Конечно можно найти картинки, а потом посмотреть фон. Но тогда сами нарушаем принцип суперумности и суперуниверсальности.

[sutra]

Вариант поиска текста, про который я говорил, предполагает, что мы знаем местоположение символов. Если нет, то надо тогда ещё смотреть координаты (относительно начала поиска) значимых пикселей. Конечно это ещё чуток замедлит, но будет намного точнее. В принципе скорости хватает и если пораскинуть мозгами однозначно можно сделать достаточно точный распознаватель символов. Мне пока некогда этим заниматься, надо скрипт доделать. Там как раз придётся много чего искать и ОЧЕНЬ хитрыми методами, там как раз все цвета радуги, при всех отягчающих обстоятельствах. Но колор точно расправится со всеми неугодными пикселями.

Я уверен, сбалансированное решение будет найдено. Ну и совершенство - это идеал, а он как известно - недостижим. Так что Кнайту работа обеспечена наверное до бесконечности.

[sutra]

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

Относительная - для каждого канала своя. А точнее для каждого канала каждого пикселя (если это не пиксель фона).

[DarkMaster]

Учитывая мой опыт работы с findimage могу однозначно сказать, что иметь возможность исключить фон чрезвычайно важно. Таким образом мы можем значительно уменьшить погрешности поиска, при этом еще и уменьшить количество необходимых изображений. Тем не менее нужно понимать, что некоторые вещи без исключения из поиска фона найти просто физически невозможно. Используемый вариант с закрашиванием верхнего левого пикселя сейчас полностью адекватен, кроме автоматизации процесса. Все-таки должен быть какой-то хотя бы примитивный встроенный инструемнт для того, чтобы это делать не paint'ом (прекращена поддержка, будет удален из дальнейших релизов windows).
Как должен выглядеть правильный вариант в моем понимании:
local result my_fi(
x1, y1, x2, y2,
image_path|{array_of_image_path,{all_image|first_found}},
type=1|2|handle,
accuracy=1-1000, -- либо double (могут быть проблемы, надо тестить)
deviation=0-255,
deviation_R=0-255,
deviation_G=0-255,
deviation_B=0-255,
gamma={110,55,220,90,45,180}|{110,55,220,10},
-- {110,55,220,90,45,180}
-- Пропорция каналов должна быть в переделах 110/55/220-90/45/180
-- {100,50,200,10}
-- Альтернативная запись. 100/50/200 +/-10% от указзаных.
-- т.е. те же самые 110/55/220-90/45/180
-- это очень важный момент, т.к. вероятность поймать левое изображение
-- в отличие от deviation значительно ниже, а в большинстве случаев
-- deviation используется именно для исключеня полупрозрачности, что
-- неразумно и алгоритм должен быть именно таким.
channel_no_R=true|false, -- выключем канал
channel_no_G=true|false, -- выключем канал
channel_no_B=true|false, -- выключем канал
channel_only_min=true|false,|
-- использовать только минимальное значение из каналов (r=100,g=50,b=200) - будет использовать 50
channel_only_max=true|false,|
-- использовать только максимальное значение из каналов (r=100,g=50,b=200) - будет использовать 200
channel_only_avg=true|false
-- использовать усреденное значение каналов (r=100,g=50,b=200) = (100+50+200)/3
-- по факту, логичнее на самом деле использовать сумму, но что внутри никто не узнает =).
)

Сообщение отредактировал DarkMaster - 28.12.2018, 18:52