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

[sutra]

if numf==k then return arr, k end

Вот из-за такой мелочи убил несколько часов. В новой версии Пилота просто вылетал lua, попробовал на предыдущей версии и получил реальную ошибку. Фишка в том, что ошибка проявлялась намного позже её совершения, поэтому пришлось ВСЁ перелопатить, сидел и думал - ... есть причина, ... должна быть причина ... А причина как всегда - или нолик, или единичка. Надо было так:

if numf-1==k then return arr, k end

Видимо никто не пользовался моей фигнёй, ну или стряпали свою.

[sutra]

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

Дарк в своё время ткнул меня носом, что индексация массива начинается с нуля, вот тупо и поменял нолик на -1, а посмотреть весь код функции поленился, вот и результат, "как не надо на фиг делать".

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

[sutra]

Дарк, я тут забубенил свой файндимидж (я уже говорил). Решил проверить как будет работать на 1000+ картинок, вместо вызова внешней проги (которая джипеги смотрит). Пока толком не тестировал на скорость, но присобачил элемент самообучения. Идея такая, может тебе пригодится. У меня deviation не в %, а разности каналов RGB, с точностью до 1. Использую файл конфигурации, в который записывается этот deviation. Ищет например с нулевой погрешностью, если не находит картинку, увеличивает погрешность и так пока не найдёт картинку. Результат записывает в файл конфигурации и в дальнейшем использует именно эту погрешность. Смысл? Чем меньше погрешность, тем быстрее осуществляется поиск. На большом объёме картинок прирост уже проявляется. Раньше просто делал погрешность с запасом, теперь ровно такая, какая нужна.

Предположительно (когда все картинки соберу) скорость поиска будет максимум 2-3 сотых секунды, сопоставимо с той какая у меня сейчас, но есть плюс - алгоритм железобетонный, будет искать как надо со 100% вероятностью надёжного поиска.

[sutra]

Попробовал подключить модуль lua, ничего у меня не получилось.

[DarkMaster]

У меня deviation не в %, а разности каналов RGB, с точностью до 1

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

Попробовал подключить модуль lua, ничего у меня не получилось.

Как подключал, что не получилось?

Правильным будет создание файла в котором будет описана некторая функция/массив функций/параметров. В конце файла просто делается return с этим творением(функцией/массивом).

Сообщение отредактировал DarkMaster - 12.12.2018, 11:40

[sutra]

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

Грубо говоря без хотя бы простенького примера думаю не разберусь. 2 вопроса. Что нужно изменить в самом файле? Про ретурн уже понял. Но всё равно нужен примерчик. И как подцеплять типа require.

[DarkMaster]

Код

local my_func = {}

my_func.show = function()
    ...
end

my_func.hide = function()
    ...
end

return my_func

ну и уже во кладках подгружаем:

Код

local f = require [[lua_plugins\my_func]]

f.show()
f.hide()

[DarkMaster]

Использую файл конфигурации, в который записывается этот deviation. Ищет например с нулевой погрешностью, если не находит картинку, увеличивает погрешность и так пока не найдёт картинку. Результат записывает в файл конфигурации и в дальнейшем использует именно эту погрешность. Смысл? Чем меньше погрешность, тем быстрее осуществляется поиск. На большом объёме картинок прирост уже проявляется. Раньше просто делал погрешность с запасом, теперь ровно такая, какая нужна.

Точно так же будет влиять и точность. По большму счету тут точность основопологающий параметр, поднимая дивиэйшн мы просто начинаем попадать в эту самую точность и получать обработку бОльшего количества пикселей пока из-за точности не оборвется. Это я к чему. Увеличивая точность можно добиться так же очень хорошего роста производительности. И тут уже нужно подбирать верное соотношение этих параметров. Т.е. я предлагаю анализировать не только deviation, но и accuracy и их сочетания. Да, будет дольше проверять, но тем не менее.
Так же по личному опыту могу сказать, что, как правило, гораздо бОльшее значение имеет задание минимально возможной области поиска и минимально возможного изображения. Так же обработка изображения чрезвычайно повышает производительность. Под обработкой имеется ввиду обрезка и закраска не несущих полезной информации частей. Если делаешь подобный анализ, то крайне рекомендую сохранять изображения с явным указанием на совпавшие части и не прерывать его по accuracy во время анализа для сохранения отпечатка, который совпал. Это очень сильно поможет в понимании происходящего и того, какие действительно параметры нужны и как следует обработать изображение.

[sutra]

Спасибо Дарк за инфу. Пробовать буду завтра (точнее уже сегодня, но позже).

Т.е. я предлагаю анализировать не только deviation, но и accuracy и их сочетания

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

Ну а скорость меня теперь уже мало интересует, если знать чего искать, да хоть 10 тыс. картинок за 2 сотых перелопачу, если их проиндексировать. Благо в lua нет проблем по скорости с циклами. Индексировать можно по чему угодно, по месту применения в скрипте ... по количеству фона в картинках (что например может говорить о количестве символов в картинках содержащих текст), ну и т.д. Для себя я этот вопрос однозначно решил, всё меня устраивает.

Увеличивая точность можно добиться так же очень хорошего роста производительности

Ну и поскольку я не знаю как реализован алгоритм этой точности, у меня его естественно нет. Всё-таки повторюсь, тут Кнайт просто хотел добиться универсальности поиска, ну чтобы ИСКАЛО. Но по скорости он сильно уступает СИ-шным массивам, поэтому тут вообще не возникает вопросов чем пользоваться.

[DarkMaster]

не понимаю принципа работы параметра accuracy

Количество_совпавших_пикселей / Количество_пикселей_в_картинке_кроме_фона

Ну а скорость меня теперь уже мало интересует

А я тут хотел предложить еще и распраллелить =)

[sutra]

Количество_совпавших_пикселей

Ну и как мы будем отличать 0 от О.


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

А вот deviation моментально бы нашёл отличия. Не понимаю почему скорость зависит от его значения.

[DarkMaster]

общая схема работы в моем понимании такова:
Пусть у нас дано изображение из 10 полезных пикселей.
Задна accuracy 90. Т.е. в нашем случае требуется совпадение не менее 9 пикселей.
Область дана в которой изображение может быть найдено в 20 наборах координат.
Финдимидж берет первую точку в заданной области и начинает попорядку сверять все 10 пикселей.
Как только количество допустмых ошибок превысит ограничение (у нас это 10-9=1), то происходит переход к следующей точке.
Справедливо и обратное, как только найдено 9 сопадений, то попытки найти 10 не будет - засчитается совпадение.

Таким образом, поскольку минимальное количество несовпадающих пикселей для позиции равно 2, а позиций у нас 20, то как минимум будет проверено 40 точек (при условии, что вообще нет никаких совпадений по цветам).
Допустим мы уменьшим параметр accuracy до 70. При этом количество ошибок должно быть не менее 4 (10-10*70%+1), чтобы изображение считалось не совпавшим. Позиций у нас все так же 20, но теперь количество проверок точек уже будет не менее 4*20=80. Вот таким не хитрым способом мы посадили производительность до двух раз.

Тем не менее очевидно, что у нас будут не только крайние случаи, но и частично совпавшее начало и отбраковка уже на середине. Напрмер, 3 пикселя в начале совпало, а только потом 4 уже были отбракованы.

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

[sutra]

Причем тут deviation?

Да как причём? Пока таким способом искать количество, deviation отбракует вариант на ПЕРВОМ же неугодном пикселе. Ну или я тупой вообще, но реальный поиск у меня работает ну просто на ура.

[DarkMaster]

Да как причём? Пока таким способом искать количество, deviation отбракует вариант на ПЕРВОМ же неугодном пикселе. Ну или я тупой вообще, но реальный поиск у меня работает ну просто на ура.

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

[sutra]

Да, 100

Возможно есть хитрые картинки, не знаю. Если картинки сильно плавают - ничего не поможет. В любом случае будут якоря.

Точнее у меня нет аккуратности, я просто анализирую заданную разность RGB.

Код

--lua
local ffi=require "ffi"                                                        -- Использование модуля ffi для использования СИ структур
local rmem=ffi.cast                                                            -- Использование функции чтения из памяти модуля ffi
ffi.cdef[[typedef struct{uint16_t x,y; uint8_t red,green,blue;}xyrgb]]         -- Определение структуры массива чтения данных из памяти образа картинки
local function ImageToArray(addr,len,scrX1,scrY1,fx1,fy1,fx2,fy2)              -- ЧТЕНИЕ ВСЕХ ПИКСЕЛЕЙ В ОБЛАСТИ ПАМЯТИ
  local n=(fx2-fx1+1)*(fy2-fy1+1)                                                -- Определение максимальной размерности возвращаемого функцией СИ массива считанных пикселей
  local arr=ffi.new("xyrgb[?]",n)                                                -- Инициализация СИ массива искомых пикселей (используя ранее описанную структуру)
  local s=ffi.new("uint8_t[3]")                                                  -- Инициализация СИ массива из 3-х элементов типа беззнаковый байт для чтения из памяти значений пикселей RGB
  local k,indY,ind,r,g,b=-1
  for i=fy1,fy2 do
    indY=addr+(i-scrY1)*len
    for j=fx1,fx2 do
      ind=indY+(j-scrX1)*3
      s[2]=rmem("unsigned char*",ind)[0]
      s[1]=rmem("unsigned char*",ind+1)[0]
      s[0]=rmem("unsigned char*",ind+2)[0]
      k=k+1 arr[k].x,arr[k].y,arr[k].red,arr[k].green,arr[k].blue=j,i,s[0],s[1],s[2]
    end
  end
  return arr,k
end
local function ImageCompare(pl,wl,hl,ll,pg,lg,x,y,fx1,fy1,fx2,fy2,dev)
  local arl,arg,kl,kg={},{}
  arl,kl=ImageToArray(pl,ll,0,0,0,0,wl-1,hl-1)
  arg,kg=ImageToArray(pg,lg,x,y,fx1,fy1,fx2,fy2)
  for i=0,kl do
    if math.abs(arl[i].red-arg[i].red)>dev or math.abs(arl[i].green-arg[i].green)>dev or math.abs(arl[i].blue-arg[i].blue)>dev then
      return 0
    end
  end
  return 1
end 

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

pl - адрес картинок pg - адрес getimage соответственно ll и lg - длина для них и т.д. разберешься в общем.

Конечно там доделывать всё надо, это чисто для тестов. У меня на вскидку получилось в 130 раз быстрее.

Фона нет, по барабану. Поиск до первого "неугодного" пикселя.

И смею заметить это ещё лишнее движение по получению массива из образа. Хотя его можно получить только один раз. Ну чисто для теста, не доделано. Следовательно будет ещё быстрее.

Загрузка картинок в память выполняется намного медленнее самого поиска, примерно вот так.

Код

tmc=os.clock()
for j=1,100000 do
  for i=1,19 do
    if 1==ImageCompare(U[i],uw[i],uh[i],ul[i],p,l,455,915, 461,925,489,932, 153) then nnn=i break end
  end
end
log(os.clock()-tmc)  -- 9,424 сек.
log(nnn)

Здесь deviation 153. Сделал 5 - результат ТОТ ЖЕ. Видимо картинки качественные.

Эх! Забыл, искалась картинка №18, ну почти по максимуму.

[cirus]

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

Это разовая операция. Да хоть секунду пусть грузятся, потом всё равно работа с памятью.

[sutra]

Это разовая операция

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

Картинки кстати, те, которую из них и ты тестил на Кнайтовском финде.

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

Конечно от камня сильно зависит, но у тебя cirus будет всё однозначно лучше.

[sutra]

local my_func = {}my_func.show = function()

Спасибо Дарк. Всё как обычно просто (когда уже знаешь). Всё работает. По привычке тестанул новые возможности. Тормозов при использовании внешнего файла не выявлено, потерь скорости нет, а вот плюс очевиден. Ещё раз огромное спасибо.


Закинул свой файл в папку Scripts и забыл... Во всём люблю порядок.

[sutra]

Ловить количество пикселей - очень рискованная идея. А вот такие вещи как будет отличать 1 или l (единица или L) особенно если посмотреть на их шрифт в том же Пилоте. Не пробовал, просто лень, но если ищет количество пикселей, то ни хрена не отличит.

И не только в Пилоте, гляньте на шрифт цитат...

А мой убогий алгоритм отличит железобетонно.

Думаю ты ошибаешься Дарк, если приоритет количество пикселей, тогда при поиске таких картинок "123" и "321" количество пикселей будет практически одинаковым. Сдаётся мне там более хитрый алгоритм.

Во всяком случае, чисто для борьбы с рендерингом достаточно параметра deviation. А вот если гамму отлавливать - это другая песня.

[sutra]

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

Кнайт, снимаю шляпу. Надо вывихнуть себе мозги, чтобы не дай бог у юзера что-нибудь не случилось с головой.