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

[Madeus]

collectgarbage ('stop') потом надо его запустить collectgarbage ('restart')

[sutra]

Не, не помогает. Делал так: collectgarbage ("stop")

collectgarbage ('stop')

И так тот же результат.

[sutra]

Код (пример)

Код

local tt1=os.clock()
k,m=FindImage2(0,0,786,895,3,1)
--k,m=FindImage2(0,0,786,895,3,2)
k,m=FindImage2(0,0,786,895,3,3)
k,m=FindImage2(0,0,786,895,3,4)
--k,m=FindImage2(0,0,786,895,3,5)
k,m=FindImage2(0,0,786,895,3,6)
k,m=FindImage2(0,0,786,895,3,7)
--k,m=FindImage2(0,0,786,895,3,8)
k,m=FindImage2(0,0,786,895,3,9)
k,m=FindImage2(0,0,786,895,3,10)
k,m=FindImage2(0,0,786,895,3,11)
local tt2=os.clock()
log(tt2-tt1)  --6.88
stop_script()

Если заремарить ЛЮБЫЕ три поиска - результат 0,7 сек. Если искать все - то 7 секунд. Вот такая математика.

Искать одну - 0,047. Тоже интересно, было вроде максимум 3 сотых.

Не, норм. 47 сотых самая большая картинка, остальные ищутся за 3 сотых . Короче ... непонятно мне такое поведение.

[sutra]

Нет, сборщик мусора тут не при чём. Всяко делал, с ожиданием и без, варьировал в разных комбинациях.
Запускаю первую половину - быстро (относительно, т.к. всё равно уже есть тормозок), потом вторую - якорь, потом опять вторую - якорь, потом первую - опять быстро. В разных комбинациях. Это компиляция. Он помнит что он уже делал и как.

[Cockney]

А в чем смысл ваших экспериментов ?

[sutra]

Между 1-ой и 2-ой половиной поисков вставил вот такой вот циклик:
for i=1,100000 do
u=k+1/1.7
end

И вторая половина вместо 7 секунд искалась !!! 38 секунд !!! Потом первая половина быстро и опять вторая половина (уже без циклика) но всё равно 38 секунд. НЕТ. ОН просто помнит! Это так работает компилятор. Не надо его грузить бессмысленными комбинациями.

А в чем смысл ваших экспериментов ?

Так как в чём? В том чтобы искалось быстро любое количество картинок при любых условиях. И вот тут и возникают такие проблемы.

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

Не надо искать чёрную кошку в тёмной комнате. Надо по уму задавать параметры поиска.

[Cockney]

Так как в чём? В том чтобы искалось быстро любое количество картинок при любых условиях. И вот тут и возникают такие проблемы.

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

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

[sutra]

А в чем смысл ваших экспериментов ?

Вот абсолютно с Вами согласен. Нет никакого смысла. Надо просто давно уже было плюнуть на всё на это!

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

Вы как всегда абсолютно правы. Просто я упёртый как баран и всё хочу из ... сделать конфетку.

[Madeus]

Максимально локализовал место тормоза. Влияют друг на друга memcpy и if.
Привожу полностью локализованный рабочий код. Попробуйте заремаренные варианты.
Первое что ОЧЕНЬ бы хотелось узнать, как это работает у других, может это опять только у меня.
У меня с единичкой получается 11 и 7 секунд для двух вариантов memcpy
Ну а если кто объяснит причину этого безобразия - большой респект.

код

Код

--lua
local ffi=require "ffi"
ffi.cdef[[
  void memcpy(void *Destination,void const *Source,unsigned int Length);
]]
log 'clear' log 'mode compact'
local CI={}
  CI[0]=ffi.new('unsigned char[?]',6220804)
  CI[1]=ffi.new('unsigned char[?]',6220804)

local function Test()
  local j=0
  local sim=1
--  local sim=2
  for jj=1,1733787 do
    for i=1,21 do
      ffi.C.memcpy(CI[0],CI[1]+8,3)
--      ffi.C.memcpy(CI[0],CI[1],3)
      j=j+1  if j>sim then  break  end
    end
    j=0
  end
end

local t=os.clock()
for i=1,10 do
    Test()
end
local t2=os.clock()
log(t2-t)

Из интересного если вызов memcpy вынести в отдельную функцию скорость увеличивается в 10 раз и это с пресловутой еденичкой

код

Код

--lua
local ffi=require "ffi"
ffi.cdef[[
  void memcpy(void *Destination,void const *Source,unsigned int Length);
]]
log 'clear' log 'mode compact'
local CI={}
CI[0]=ffi.new('unsigned char[?]',6220804)
CI[1]=ffi.new('unsigned char[?]',6220804)

local function fff()
  ffi.C.memcpy(CI[0],CI[1]+8,3)
--  ffi.C.memcpy(CI[0],CI[1],3)
end

local function Test()
  local j=0
  local sim=1
--  local sim=2
  for jj=1,1733787 do
    for i=1,21 do
      fff()
      j=j+1  if j>sim then  break  end
    end
    j=0
  end
end

local t=os.clock()
for i=1,10 do
  Test()
end
local t2=os.clock()
log(t2-t)

А если if j>sim then break end поставить в начале цикла for то решается проблема с 1 и прирост от выноса memcpy в отдельную функцию не такой большой, несколько сотых.
Идею взял тут информация по оптимизации производительности Lua от создателя самого языка и тут тесты и tips&tricks для лучшей производительности

[Cockney]

Ради интереса слепил свой вариант. По сути стандартный поиск пилота с похожим синтаксисом. Прикладываю бенчмарки, кому интересно - погоняйте. Интересно, может ли он составить конкуренцию текущим реализациям. Запустите бенчмарк с ключем --h и он распишет что там как заводить, либо смотрите файл run.bat.

[cirus]

Ради интереса слепил свой вариант.

deviation не работает, не найдёт картинку если она хоть немного отличается по цвету. --d 0 и --d 100 вообще никакой разницы.

[Cockney]

Можно изображения, на которых валится ?

[cirus]

Можно изображения, на которых валится ?

 image.zip ( 32,9 килобайт ) Кол-во скачиваний: 70

Содержимое батника:

Код

findimage_benchmark_Release_x64 --s test.bmp --i pilot.bmp --a 90.0 --d 30 --sr > benchmark_log.txt

Пилот находит картинки.

Код

--lua
log 'clear' log 'mode compact'

local pilot = loadimage ([[pilot.bmp]])    -- загрузка искомой картинки
local test = loadimage ([[test.bmp]])     -- загрузка картинки, на которой искать

local accuracy = 90  -- точность поиска
local count = -1     -- сколько искать картинок
local deviation = 30  -- deviation

local t = os.clock()
local arr = findimage (0, 0, 1920, 1080, {pilot}, test, accuracy, count, deviation)
log ('Затрачено времени на поиск: ' .. tostring(os.clock() - t))

if arr then    -- если изображения найдены
    log('Найдено изображений: ' .. tostring(#arr) .. '\r\nКоординаты изображений:')
    for i = 1, #arr do
        log(tostring(i) .. ' -', arr[i][1], arr[i][2], '\t% совпадения:', arr[i][5])
    end
end

[sutra]

Идею взял тут

Спасибо, теперь хоть понятно почему так получается при работе циклов. Просто когда прикрутил функцию поиска собственно в рабочий скрипт (она как раз оказывается вне цикла), всё просто "летало".
Я посчитал что это опять лично у меня какая-то аномалия получилась, а оказывается - это закономерность. В общем я получил прирост ровно в 675 раз, по сравнению с предыдущей моей реализацией контроля шкалы микшера. На данный момент контроль 100 пикселей шкалы выполняется 25 000 раз в секунду, вот это реальный реал-тайм. Удивительно, почему у Кнайта такой медленный getimage.

[Cockney]

deviation не работает, не найдёт картинку если она хоть немного отличается по цвету. --d 0 и --d 100 вообще никакой разницы.

А если так ? Точность немного завысил, ибо находит много изображений при большом отклонении.

[sutra]

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

[cirus]

А если так ?

Позже проверю.

поэтому ещё 2 года назад перешёл на свой финд.

Которого так никто и не видел. Имеется ввиду не в виде каких-то кусков кода, а в виде полноценного модуля, с примерами использования. Скрипт, картинка, которую ищем и на которой ищем.

[sutra]

Которого так никто и не видел. Имеется ввиду не в виде каких-то кусков кода, а в виде полноценного модуля, с примерами использования

Хорошо, сделаю. Надо описание делать - лень. Может завтра допинаю.

И надо будет ещё попробовать действительно во всех циклах все "кишки" вынести наружу в виде функций.

[cirus]

Надо описание делать - лень.

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

[cirus]

А если так ?

Теперь нормально. Ищет быстро и нет такой зависимости от отклонения в цвете как в пилотном поиске.