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

[sutra]

Короче надо делать 2 копии образа и 2 копии картинки и сравнивать минимумы и максимумы. Так наверное быстрее всего и абсолютно универсально.

[DarkMaster]

Найти все монетки.

Распознать время.

[sutra]

Найти все монетки

А что? Не ищется?


Ну 2 серьёзных отличия я нашёл, не знаю справится ли поиск. Гигантский рендеринг, хотя я бы попробовал поискать даже своей функцией. Задать попробовать погрешность типа 120. Надо пробовать. Но сразу скажу, зона рендеринга ОЧЕВИДНА. Сделай картинку поменьше и моей убогой функцией 100% найдёшь.

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

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

[DarkMaster]

А так?

[sutra]

Конечно тема поиска типа монеток, НО, вопрос стоял найти количество монеток. Я бы искал хвостик, куда тычется картинка с монетками. Хвостик должен искаться.

А так?

У меня это тоже была первая мысль, но принципиально решил не искать лёгких путей.

[DarkMaster]

Искать однозначно черную галку которая образуется на стыке монет + контраст белого над ними.

У меня это тоже была первая мысль, но принципиально решил не искать лёгких путей.

Создание легкого пути есть цель приведения финдимиджа к должному виду.

[sutra]

Искать однозначно черную галку которая образуется на стыке монет + контраст белого над ними.

Именно её я и кинул размером 11х11, для скорости.

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

[cirus]

А не было бы галки...
Вообще уменьшение цветности в некоторых случаях помогло бы.
У одного из конкурентов есть такая функция.

[sutra]

В каждом случае нужно внимательно смотреть что искать. Как сказал Дарк, главное чтобы искало, нет цели "рисовать" искуственный интеллект.

[DarkMaster]

короче сидел крутил изображение - тот вариант чернобелый самый хороший. Это по синему каналу либо по минимально - в данном случае результат один.

[sutra]

А не было бы галки...

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

короче сидел крутил изображение

Ну видишь, надо засунуть конкурентов, значит надо по любому расширять функционал. Из расчёта, что юзер думать не должен.

С аккуратностью должен будет искать. Всё равно картинка уникальна. Ничто ведь не мешает задать аккуратность скажем 60% . И найдёт ... аналогичных изображений ведь нет. Уверен - НАЙДЁТ.

Собственно говоря - аккуратность - это и есть элемент интеллекта.

[DarkMaster]

У одного из конкурентов есть такая функция.

Если это тот про которого я думаю, то там оно очень печальное и по сути является набором фиксированных частных случаев deviation'на.

Пока у нас нет такого алгоритма

В голове он есть =) Элементрано дописать пачку and на соотношение каналов, мин/макс. Фон первый в условие ставить через or (так быстрее). А вот дальше уже сидеть и крутить, как оно быстрее будет.

[sutra]

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

[sutra]

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

Код

-- структура массива искомых пикселей arrpix {x,y,r1,r2,g1,g2,b1,b2}
-- x,y координаты пикселя в картинке r1,r2 граничные значения поиска канала (считаются учитывая dev)
for i=1,#arrpix do                                     -- цикл просмотра значимых пикселей
  ind=addrGet + ... arrpix[i].y * ... arrpix[i].x ...   -- вычисление индекса в памяти
  blue=rmem("unsigned char*",addrGet)[0]
  if blue>=arrpix[i].b1 and blue<=arrpix[i].b2 then
      green=rmem("unsigned char*",addrGet)[1]
      if green>=arrpix[i].g1 and green<=arrpix[i].g2 then
          red=rmem("unsigned char*",addrGet)[2]
          if red<arrpix[i].r1 or red>arrpix[i].r2 then
            acc=acc+1
          end
        else  acc=acc+1
      end
    else  acc=acc+1           -- увеличение параметра пропущенных пикселей
  end
  if acc > accuracy then return 0  end   -- если число пропущенных превышает допустимое
end
return 1

Так что с поиском всё предельно просто. А вот грамотно подготовить массив для поиска, вот тут полно вариантов. Как сделать красиво и универсально я даже не знаю.

[sutra]

Вот если взять конкретный пример Сайруса с монетками, там предельно просто. Выделяем практически любую область под картинку. Конечно чем она будет меньше, тем быстрее. Но с точки зрения поиска абсолютно фиолетово. И создаём массив искомых пикселей скажем используя только цвет RGB 44,21,19 +- погрешность. То есть в качестве массива будет выступать окантовка. Ну ладно если допустим ещё 1 цвет добавим к искомым пикселям (в случае с монетками например 220,220,220 - условно белый фон внутри канта). А если надо 5 цветов, как их задавать? Конечно можно подготовить картинку и брать оттуда цвета. В общем тут масса вариантов.

[sutra]

Дарк, идея в принципе такова. Ну давай на примере прицела. Предположим картинка прицела 40х40. Мы будем крутить цикл не 1600 итераций, а всего скажем 35 (в массив лягут только красные пиксели со своими значениями x,y и граничными значениями цвета по RGB). Надеюсь ты понял мою мысль.

То есть всё, что не попало в массив значимых пикселей считается фоном и естественно не анализируется.

[sutra]

Короче, надо тщательно готовить картинку. Убирать из неё всё не нужное. Или как вариант задавать не прямоугольную, а чётко описанную область картинки цвета которой попадут в массив искомых пикселей. На примере монеток. Убирать все пиксели вокруг окантовки монеток, иначе эти пиксели всё испортят. В общем тут полно вариантов, начиная от грамотного определения области для картинки и заканчивая её ручным редактированием, либо прямо задавать массив x,y пиксели которых лягут в искомый массив.

Ладно, пора закругляться. Идея ясна, сделать можно, но уж точно не сегодня.

[sutra]

Дарк, продолжая тему про поиск в разных окнах, не засоряя темы других пользователей, перешёл в свою. Используя твой опыт по обработке памяти, переделал весь свой код, даже в мелочах, результаты просто супер. Раньше перезагруз браузера, анализ начальных условий, выполнялся до 10 секунд. Сейчас на порядок всё быстрее, как говорил, даже клики мышкой теперь используют анализ изображений в памяти. Вот ЧИСТО ДЛЯ ПРИМЕРА маленький кусочек кода...

Код

local WrM=1                                                                    -- Объявление и инициализация параметра № рабочего монитора
if x>1900 then  WrM=2  end                                                     -- Если начальная абсцисса окна браузера соответствует отображению на 2-ом мониторе
local mic=findwindow("Микшер")                                                 -- Поиск хендла окна Микшера громкости
if mic==nil then                                                               -- Если окно Микшера громкости не найдено
  f.LeftWait(1810,1060,1830,1025,1840,1030,0)                                    -- Клик на пиктограмму динамика в системном трее (анализ появления изображения шкалы громкости)
  f.LeftWait(1810,1005,1830,1025,1840,1030,0)                                    -- Клик на надпись "микшер", для вывода на экран окна Микшера громкости (анализ исчезновения изображения шкалы громкости)
  mic=findwindow("Микшер")                                                       -- Поиск хендла окна Микшера громкости
  windowpos(100,100,800,0,mic[1][1])                                             -- Растягивание окна Микшера громкости, для гарантии отображения всех устройств
  local x,y=f.FindImage(235,30,800,145,[[СКРИНЫ\_mic.bmp]],mic[1][1],10)         -- Поиск нужного устройства звука в окне Микшера громкости, для определения его позиционирования (погрешность 10)
  if x~=-1 then                                                                  -- На всякий случай, во избежание ошибки скрипта
    windowpos(WrM*1920-292-math.modf((x-245)/110)*110,810,800,0,mic[1][1])         -- Позиционирование окна микшера громкости в соответствии с найденной позицией картинки
  end
end

[sutra]

Я правильно понял?? windowfrompoint в lua не работает?? Пришлось в цикле перебирать окна для сворачивания используя перемещение мыши и windowfromcursor().

Не актуально. Разобрался с windowfrompoint.

[cirus]

Всё что есть тут http://uopilot.tati.pro/index.php?title=Список_функций_(Lua) работает в 2.41. Если какой-то команды нет, значит не работает или работает не так как должно.
Что касается windowfrompoint, она возвращает строку с хендлами вместо массива.

Код

--lua
local tmp = windowfrompoint(800, 500, "all")
local h = {}

for w in tmp:gmatch("%d+") do
    h[#h+1]=tonumber(w)
    log(w)
end
-- на выходе таблица с хендлами