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

[sutra]

На мой вгляд (на перспективу, вдруг добьёшь компиляцию) надо сделать 2 раздельные функции, для неприхотливых сделать скромную SingleFind (скоростную) и не рекламировать её, просто пусть будет. А для всех остальных сделать функцию SmartFind.

[sutra]

Нет, не сингл, а SpeedFind.

Выбор чем пользоваться оставить за юзером.

Юзер попробует и сделает для себя вывод ... юзер он или лузер. (IMG:style_emoticons/default/biggrin.gif)

[DarkMaster]

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

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

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

Почему? Пиксели то дожны быть на своих позициях. Написать вместо 123 321 для скрипта примерно тоже самое, что вместо 123 написать 824 (сглаживание, рендеринг не трогаем). Все гораздо хуже бывает в 3 и 8, 4 и 1, 7 и 1, самый ужас O и Q. И вот там действительно большие ограничения. От шрифта еще очень много зависит. В целом для текста я ставлю обычно 97-98% точность, при крупном кегле можно до 95 сбросить. Так же очень важно бывает правильно обтравить изображения. Поэтому я и говорил, что подобный анализ не помешал бы.

[sutra]

Все гораздо хуже бывает в 3 и 8, 4 и 1, 7 и 1

Знаю, знаю. Ещё хуже когда стоит цифра между 2 или 7. Типа 282 или 787. Двушки портят низ, семёрки верх. Но я говорил, я просто по реперным точкам смотрю. Для той же Q - есть своя "неубиенная" точка. И повторюсь, мой нехитрый и при этом быстрый алгоритм ну никак он не пропустит хвостик от Q даже с диким deviation. Конечно сейчас я говорю во многом голословно, может есть очень хитрые тексты. При случае обязательно поэксперементирую. Для моего алгоритма болезненно если реально плавают символы. Специально соберу коллекцию таких текстов и что-то мне подсказывает, что проблема возникнет и у Кнайтовского финда. Как уже говорил, на мой взгляд, понадобится несколько вариантов написания символов. И опять же, вот допустим рядовой, тупой юзер. Ну как он будет определять сколько дать аккуратности, а сколько погрешности. Я уж не самый тупой и то не очень понимаю.

Я поначалу (когда был совсем тупой) пробовал всяко и частенько финд либо не мог найти, либо находил не то, что требовалось, а это ещё хуже. Должно искать, искать железно, 100%. Я решил эти вопросы - мгновенно и 100% (конечно благодаря lua) В Пилоте тоже было 100%, но требовалось до 7 десятых секунды.

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

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

[sutra]

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

Ну а для поиска реальных картинок, могу конечно ошибаться, но сколько не пробовал мой вариант однозначно ищет 100% и как минимум быстрее. Потому что у Кнайта использование deviation начинает очень сильно тормозить.

Сильно тормозить - это в разы, а не на 15-20%.

[sutra]

Не поленился ещё раз потестил:

Код

tmc=os.clock()
local argg,kg=fn.ImageToArray(p,l,455,915,461,925,489,932)
for j=1,10000 do
  for i=1,19 do      -- картинки размером 29 х 8
    if 1==ImageCompare(U[i],uwid[i],uhei[i],ulen[i],argg, 27) then nu=i break end
  end
end
log(os.clock()-tmc)                   -- 0.477 сек.

local ar,err={}
tmc=os.clock()
local p1,w,h,l=getimage(461,925,489,932,ok[1][1])
for j=1,1000 do
  for i=1,19 do      -- картинки размером 29 х 8
    ar,err=findimage(0,0,27,8,{U[i]},p1,100,1,0)
    if err==100 then nk=i end
  end
end
log(os.clock()-tmc)                    -- 5.628 сек  (в 10 раз меньше картинок)

for j=1,1000 do
  for i=1,19 do      -- картинки размером 29 х 8
    ar,err=findimage(0,0,27,8,{U[i]},p1,100,1,7)
    if err==100 then nk=i end
  end
end
log(os.clock()-tmc)                    -- 13.644 сек  (в 10 раз меньше картинок)

Как и говорил, deviation действует на алгоритм гипнотически, причин я не понимаю, видимо действительно вторичный параметр, что НА МОЙ ВГЛЯД неправильно.

Именно тормоз deviation заставил меня рисовать свой финд.

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

[DarkMaster]

Вот плавающие символы, вот тут да, мой алгоритм начнёт тупить, потому что та же единичка рисуется 2-3 мя палками.

Даже при кнайтовском финде словарь доходил до 250 картинок и не 100% результате.

Я же наоборот рассматриваю фон, как рабочий пиксель.

Полупрозрачный игровой чат со сглаживанием и рендерингом. Без deviation и accuracy можно не пытаться (IMG:style_emoticons/default/smile.gif)
Я не спорю, есть частные случаи, но они, к сожалению, на то и частные, что встречаются не всегда.Финдимидж комбайн и им можно очень много сделать. На мой взгляд этому комбайну не хватает изначальной задумки с яркостью (соотношением каналов). По части скорости... Я допускаю, что там могут быть какие-то существенные тормозящие моменты, но у меня есть сомнения. Скорее всего в первую очередь все обусловлено именно площадями, точностью. Там кстати есть еще предварительный анализ искомого изображения, что негативно скажется на большом количестве вызовов в маленькой области. В целом - знает только кнайт. Вообще учитывая, что в примитивном виде код очень невелик, а финды так и не пересобрались из-за масштабности работы, то видимо там все не очень просто, возможно связано со старым синтаксисом, но это мои догадки.

Сообщение отредактировал DarkMaster - 14.12.2018, 2:17

[sutra]

Полупрозрачный игровой чат со сглаживанием и рендерингом

Я бы даже не думал - однозначно для такого случая анализ реперных точек. Извращаться с имиджем при таких условиях - дело неблагодарное.

Стандартными средствами в любом случае будет небыстро, имея на руках СИ-шный инструментарий, придётся конечно ковыряться, но задача 100% решаема, со 100% результатом.

[DarkMaster]

 0_big.bmp ( 66,05 килобайт ) Кол-во скачиваний: 181

Вот и что с одним deviaton тут делать? Вот эта вот радуга фактически может в любую сторону плавать. При комбинации с accuracy получается хотя бы проглатывать крайние положения.

[sutra]

Вот и что с одним deviaton тут делать?

Вопрос как плавает радуга по цветам, НО пиксели фона - они и могут решить проблему. И всё-таки я ошибался, когда говорил, что у Кнайта погрешность вторичный параметр, просто по логике он не может быть вторичным. Как раз он первичный и чем меньше он пикселей забраковал, тем ДОЛЬШЕ с ними возится параметр аккуратности, отсюда и тормоза. Кстати, есть у меня такие радуги, вроде как всё у меня ищет. Да посмотри, я даже тестовый пример приводил, я там ищу с погрешностью 153 - это +- 153 (более половины всего диапазона) и находит без ошибок. Я дал конкретный код, ты пробовал им??? Я конечно не Кнайт, я и 10% не знаю, того, чего знает он. Но надеюсь, что мои доводы, помогут ему найти сбалансированное и эффективное решение.

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

[DarkMaster]

я там ищу с погрешностью 153 - это +- 153 (более половины всего диапазона) и находит без ошибок.

Проблема в том, что меня интересуют те случаи, когда deviation в +/-7%, т.е. +/-18rgb приводят к ложным срабатываниям. Ну вот такая вот там хрень.

Но надеюсь, что мои доводы, помогут ему найти сбалансированное и эффективное решение.

Как минимум меня заинтересовал и я сидел в фоторедакторе и искал способы решить поставленную задачу. Вроде даже решил. Остался вопрос самому огород городить либо все это запихается в find(бабушкааа).

[sutra]

в +/-7%, т.е. +/-18rgb

А аккуратность при этом КАКАЯ???

Остался вопрос самому огород городить либо все это запихается в find(бабушкааа).

Аналогично!


Просто не стоит ещё доверять собственному субъективному мнению. Логику процесса я озвучил. Искать с увеличением погрешности, до тех пор, пока не найдёт. Будут ложные срабатывания - значит нужна дополнительная картинка с новым вариантом. Главное скорость то позволяет лопатить без ограничений.

И ещё раз повторюсь, да не получится нарисовать финд, который будет искать всё. Это всего лишь прога (алгоритм), просто теоретически метод поиска чисто путём тупого перебора не способен искать как надо. Что мы первые что ли озадачились этим. А как файнридер ищет? А как распознавание лиц?? Только по реперным точкам. А вот где эти точки выставить, вот тут нужны мозги, статистика и труд...

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

Я полностью переделал все свои поисковые функции, даже аналог if 100 100 2345 сделал свой (кстати родной в lua не работает).

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

[cirus]

А как файнридер ищет?

OCR - оптическое распознавание символов. Там вообще не влияет шрифт, его размер или цвет.

[sutra]

Там вообще не влияет шрифт

Естественно, отличается фон от остального. Там много чего наворочено, потому и работает в 10-ки раз медленнее наших алгоритмов, которые заточены под конкретику.


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

[DarkMaster]

А аккуратность при этом КАКАЯ???

А там уже пофигу. Шмное изображение с очень маленькой градацией оттенка.

[sutra]

Показательно в этом случае распознавание лиц. Там однозначно реперные точки. Алгоритмы тоже на протяжении десятков лет совершенствуются.

А там уже пофигу.

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

[DarkMaster]

 cross.bmp ( 361,22 килобайт ) Кол-во скачиваний: 168

Вот пример. Наложен фильтр оттенка. Примерно так видит в данном случае deviation.

[sutra]

В нашем случае шрифт известен. Сглаживание - это тоже алгоритм, для своего случая я его вычислил на 100%, не более 7 вариантов написания символа, в зависимости от соседних, рендеринг побеждается погрешностью. Никаких проблем не вижу. Так у меня ещё и текст центрированный, мне приходится искать и начало и конец текста. И всё работает. Поначалу много было неизвестных, но статистика собиралась, неизвестные варианты добавлялись. В lua проблем нет. Распознаватель на 5 страницах, но работает быстро.

[DarkMaster]

Распознаватель на 5 страницах, но работает быстро.

А мой чем не устроил?) Скоростью из-за стандартного финда?

[sutra]

Вот пример. Наложен фильтр оттенка

Круто, я думал я самый упёртый, ан нет. Но если серьёзно, да мне всё равно, что там кто видит. Находит, значит видит, не находит, значит нет. У меня находит, возможно у меня намного более простые шрифты и "тепличные" условия. Значит мне повезло. Спорить я ни с кем не собираюсь. Я хотел бы только одного, если Кнайт сделает компиляцию, чтобы он оставил возможность что-то делать самому, просто сделав отдельную функцию без наворотов. Но если и не сделает, не вопрос, если уж я без lua изголялся и пусть небыстро, но решал практически любые задачи, то уж c lua думаю разберусь и с заковыристыми вопросами. Так что давайте закроем эту тему.

Перебор методом тыка сразу 2-х параметров - с одной стороны вроде плюс, а с другой стороны возникает куча побочных эффектов и главное как всё это отслеживать и отлавливать. Я привык к простоте. Не пашет - купи новый комп. Долго? Сделай индексы. Но всё должно оставаться простым и понятным. Это путь к избежанию ошибок. Я то пожил слава богу, а вот если горе специалисты угробят атомную станцию или ещё чего похлеще натворят. Нет, всё должно быть неубиенно - это мой принцип.