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

[cirus]

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

Проще указать отдельным параметром.

[DarkMaster]

крест без исключения фона стабильно находить не получится. Фон может быть любым от белого до черного.

Проще указать отдельным параметром.

А смысл? Все равно фон красить, все равно запускать редактор.

[sutra]

А смысл? Все равно фон красить, все равно запускать редактор.

Блин, ну вы даёте. Дарк, вот скажи? Кто ещё будет красить фон кроме тебя? Тут кнопку Старт не все знают.
(IMG:style_emoticons/default/biggrin.gif)

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

На фиг Пайнт. У меня для вот таких случаев есть древнейший PSP. Типа Пайнт Шоп Про. Вполне хватит чтобы закрасить фон, да и не только. Стоит он, установки не просит, маленький, но удаленький. Ну короче вместо полноценного Шопа.

И мне кажется Дарк, ну ты реально ну сильно усложняешь задачу. Твой как ты говоришь полупрозрачный и не очень фон, да я "победю" просто используя относительную погрешность. Ну насколько он меняется твой фон? Я говорю, тема фона очень неоднозначная, стоит ли его (фон) ставить в такой приоритет. Ну что? Есть реальные задачи, когда фон ну прямо всеми цветами...?

Первый пиксель в качестве фона - это ну просто придумка, ну весьма неплохая, НО, как я всегда, всем и везде говорю. ДОЛЖНА быть возможность в 9-ой вкладке, мелким шрифтом выбрать кнопочку advanced.

Всё должно быть гибким. С фоном, без фона и т.д. Кстати, а вот давай сделаем опрос, кто вообще понимает использование фона в финде? Я первый респондент - отвечаю, мне он пока не был нужен. Отвечаю, я не сразу даже сообразил как всё это работает. Отвечаю, только после десятков экспериментов, обсуждений на форуме я стал понимать как вообще это работает, да и то возможно не полностью. Я конечно не корифей, но уж и не совсем вроде дурак.

А ещё можно спросить что такое RGB. И я вот не уверен, что ответят. Не все знают даже кто воевал в 1945.

Работа с фоном (а я уже говорил, что и не только с ним) при поставленных задачах должна исходить из ОТНОСИТЕЛЬНОЙ погрешности и никак иначе. Если фон статичен, то тут и вопросов никаких нет. Есть допустим фон 0, 255, 255. Что это значит? Это значит, что погрешность для красного канала мы дадим, ну скажем исходя из того, что он 1. Про нуль мы говорили - ничего не значащее число. То есть погрешность будет распространяться практически только на зелёный и синий каналы, иначе говоря все наши красные пиксели останутся значимыми, даже типа таких как 4, 100,100

[sutra]

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

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

[DarkMaster]

Дарк, вот скажи? Кто ещё будет красить фон кроме тебя?

Я тоже так думал. Как не поразительно, но его действительно красят.

И мне кажется Дарк, ну ты реально ну сильно усложняешь задачу.

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

Ну насколько он меняется твой фон? Я говорю, тема фона очень неоднозначная

Там где нет полупрозрачности/сглаживания/рендеринга я if color'ом обойдусь в 95% случаев и смысла в финде там просто не будет. В данном случае шустрый код решает 1 задачу из 3, пусть и очень шустро. В реальных боевых условиях на текущем финде я неоднократно получал пробелемы из-за высокого deviation. В том, что они возникнут и с accuracy 100% я не сомневаюсь ибо все это уже перепробовано.

Кстати, а вот давай сделаем опрос, кто вообще понимает использование фона в финде?

Прочитавший абзац в справке (IMG:style_emoticons/default/smile.gif)

я стал понимать как вообще это работает, да и то возможно не полностью

Все точки цвет которых равен цвету левого верхнего пикселя при поиске не учитываются. Т.е. картинка выглядит, как дуршлаг.

А ещё можно спросить что такое RGB. И я вот не уверен, что ответят. Не все знают даже кто воевал в 1945.

Ну не все и до 10 считать умеют (IMG:style_emoticons/default/smile.gif) Бывает. RGB понимают практически все, подозреваю, что это связано с уроками биологии в школе ибо схема по сути та же.

при поставленных задачах должна исходить из ОТНОСИТЕЛЬНОЙ погрешности и никак иначе.

Я так и хотел изначально и говорил, как мы не поняли друг друга с кнайтом. Тем не менее необходимо понимать, что отностильная погрешность - это изменение яркости/гаммы(хз как оно тут правильно будет зваться), в то время, как абсолютная погрешность - это полупрозрачности. Это разные инструменты для разных целей. Оставляя только один из них мы либо бюстом болты заколачивать будем либо гаячным ключем эти бюсты ваять. Они нужны оба и они должны дополнять друг друга. Эта концепция родилась лет 10 назад и у меня было время и возможность в ней убедиться.

[sutra]

крест без исключения фона стабильно находить не получится

Не знаю конечно как по скорости, надо пробовать. Искать колором например (не считал) 30 пикселей красного цвета и смотреть разницу координат (которая присуща только кресту), между первым и последним пикселем. Я бы наверное сделал отдельную функцию. Сначала искать первый красный пиксель, затем проверять сразу другой граничный пиксель, если отстоит от первого например на 30 пикселей (не считал, чисто для примера). То наверняка уже нашли. Проверить на всякий случай ещё пару строк пикселей, собственно вот всё. Что-то мне подсказывает, что у меня проблем бы не было. У меня очень похожая задача, ТОЛЬКО ещё и цвет искомый сильно плавает, поэтому я ищу разницу R-G.


Если уж универсально делать, потребуется 3 параметра: для фона1 и фона2 (devF1 и devF2), и ещё 1 параметр devColor. То есть погрешность будет индивидуальная для каждого параметра. Если закрасить фон для эталона, то тогда конечно второй параметр фона не нужен. При тяжёлых условиях поиска использовать относительную погрешность.

Тут вот ещё есть какая фишка. Реально есть 2 задачи: 1) Найти; 2) Поискать. Возможно тоже нужно иметь 2 разных алгоритма обработки. В первом случае алгоритм может сам "поиграть" погрешностями. Во втором случае "можно доиграться". (IMG:style_emoticons/default/blink.gif)

Ещё раз про крест. Он ведь не сам по себе по экрану шастает. Значит мы можем прогнозировать его зону нахождения, а значит скорости поиска однозначно будет достаточно. Точное наведение на цель в цикле думаю будет выполняться быстро. В Пилоте бы конечно это были жуткие тормоза. В lua это всё должно работать как часы.

У себя я различаю задачи найти и поискать и это сильно упрощает всё и исключает ошибки.

Немного потестил. С относительной погрешностью (отдельно по каждому каналу) фон начинает мешать в разы меньше.

В общем я не знаю, у меня всё вроде находится без проблем, даже на градиентном фоне.

Вчера вот человека обманул, сказал, что без мышки нельзя число из окна получить. Хотя из обычного окна, с обычным фоном задача проще пареной репы, но в 2-х словах не объяснишь.

[sutra]

полупрозрачности

Полупрозрачности если задавать относительной погрешностью тоже даст огромный прирост достоверности поиска. Смысл то остаётся понятным фон - на то и фон, что он СИЛЬНО отличается от не фона. Вопрос стоит так а ЧЕМ ОН ТАК СИЛЬНО отличается. Вот относительная погрешность успешно решает этот вопрос.

Минус только один - алгоритм работает намного дольше, но при небольших областях поиска и если не крутить 1000 картинок, то всё будет хоккей.

[DarkMaster]

фон - на то и фон, что он СИЛЬНО отличается от не фона

Вот тут сильное заблуждение (IMG:style_emoticons/default/smile.gif)
Во первых если мы рассматриваем чаты игр, то там альфа канал может быть и 90% и 100%. Соответственно фоном является окружающая среда, которая может иметь любой цвет и текст может становиться тяжелочитаемым даже для человека.
Во вторых есть вероятность распознать не то окно. Например, у нас есть некоторая динамичная картинка (галерея скринов/3д мир/видео/что-нибудь еще), мы делаем некоторый клик и поверх этой динамической картинки должно появиться наше окошко, зачастую полупрозрачное. Нам нужно задетектить открытие такого окна, нужен якорь. Очень часто это просто серое полупрозрачное окно с каким-нибудь текстом со сглаживанием шрифтов. Вот тут и начинаются проблемы. Подложка сложная, якорь плавает. С одной стороны нам нужно увеличить погрешность, чтобы точно задетектить, с другой стороны, если мы так сделаем, то будем ловить ошибочно фон. При отсутствии возможности достоверно отделить динамическое изображение от фона приходится описывать дополнительные конструкции которые уже очень сильно тормозят скрипт. В частности самым надежным способом в данном случае для меня является наличие нашего якоря на экране N секунд без исчезновения даже на один прогон поиска. Тонкая настройка в данном случае очень поможет, а вот скорость самого поиска никак не повлияет, т.к. нам все равно приходится висеть N секунд и проверять. Будет за это время проверено 50 или 50 000 изображений разницы по сути никакой. На самом деле последние года два я пишу примерно 30% финдов именно с таким ожиданием, что достаточно сильно удручает.

[sutra]

Кнайт, в общем лично мой опыт позволяет сделать такие выводы по теме поиска картинок. Если искать только значимые пиксели (например при поиске текста) ну или грубо говоря ищем силуэт, не учитывая цвет объекта, то тогда deviation действует только на анализ цвета фона. Если же ищется также и цвет объекта, то наверное нужны ДВА параметра (погрешность для фона и погрешность цвета значимых пикселей объекта). Хотя меня устроил бы и один параметр. Как лучше обозвать (и описывать в справке) эти параметры, тут решать не мне. По логике погрешность должна считаться для всех каналов отдельно, т.е. должна быть относительной и это должно быть по умолчанию. НО оставить возможность задания абсолютной погрешности (для критичных к скорости поисках) тоже надо. Придумывать что-то большее наверное нет смысла, всё равно на все случаи жизни вряд ли получится сделать. Аккуратность наверное нужна только для поиска силуэтов, поэтому её тоже надо отключать внутри функции, если она не задана или задана, как 100%. Какова будет реализация аккуратности тоже решать не мне, но если не делать анализа по строкам, то действительно трудно будет отличать O от Q.

[DarkMaster]

Ещё раз про крест.

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

[sutra]

текст может становиться тяжелочитаемым даже для человека

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

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

Дарк, ты сможешь всё. Я, если подумаю, пусть нестандартно и только под свои нужды, но тоже сделаю. Пока не встречал нерешаемых задач.

Относительная погрешность результат даст на 90% случаев всё будет искаться.

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

Зону чата тоже ведь не от балды подбирают. В общем я своё мнение высказал. Решать не мне. Тебе Дарк ещё раз отдельное спасибо за ИНСТРУМЕНТ. Лично я с ним найду всё, даже текст 254 254 254 на фоне 255 255 255.

Ну а если уж ну ОЧЕНЬ надо. Для такого случая можно задавать цвета и погрешности значимых пикселей таблицей, всё остальное считать фоном. Вопрос решить однозначно можно, стоит ли из-за таких нетривиальных случаев портить стандартную вещь. Кому надо, тот реализует. Сложного то ничего нет, никаких специальных знаний не нужно. Минимальные знания и всего 2 оператора.

[DarkMaster]

Дарк, есть всякие ситуации, всегда можно найти конкретное, частное решение.

Можно, и это приводит к тому, что:

Всегда встаешь на какой-нибудь хреновине, где не хватает чуть-чуть и на это тратися в итоге больше времени, чем на весь остальной код. Так всегда. Без исключений.

Нужно понимать, что нерешаемая задача, сложная задача и сложная задача из-за отсутствия стандартизированного алгоритма вещи разные. Можно все описать, все написать. Но если начинать колорами описывать зависимости расстояния пикселей и создавать АИ вместо закрашивания фона, то мы придем в итоге к тому, что автоматизацию будем писать дольше, чем делать это руками. Я уже очень давно прошел ту фазу и мандражи "а вдруг не смогу написать". Я знаю, что смогу. Просто это может занять значительное время. Речь об автоматизации процесса.

Относительная погрешность результат даст на 90% случаев всё будет искаться.

В итоге возвращаемся все туда же:

Всегда встаешь на какой-нибудь хреновине, где не хватает чуть-чуть и на это тратися в итоге больше времени, чем на весь остальной код. Так всегда. Без исключений.

Вообще то в нормальных прогах

Не видел ни одну. Вообще ни одну. Везде свои косяки в той или иной степени. Выкинуть компьютер?)

стоит ли из-за таких нетривиальных случаев портить стандартную вещь

Случаи на самом деле тривиальные. А вот портить не стоит, да. Стоит делать форк и тут мы вроде даже к согласию пришли.

[sutra]

Да согласен я с доводами Дарк. Проблема то ещё в чём. Есть 2 варианта: либо сильно плавает фон, а значимое изображение стабильное; либо наоборот. И тогда реализация сильно отличается. А что будем делать если плавает ВСЁ? Тут только тащить минимум 2 параметра, а то и все 4 (2 для образа, 2 для эталона). А мне тогда что делать, плавает вообще всё, в том числе даже геометрия изображения. Поэтому я не стал ломать мозги, ищу колором, считаю найденные пиксели, смотрю их координаты, не так долго я это и делал. Универсальную функцию делать однозначно труднее. И давай не будем забывать что колором получается намного быстрее, иногда это становится решающим фактором.

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

[DarkMaster]

А что будем делать если плавает ВСЁ?

Лично мной убито 3 суток на одно из изображений которое вот так вот плавало. При этом сейчас я четко понимаю, что в том конкретном случае помог бы deviation заданный отдельно по каналам, так же подозреваю, что очень положительно бы сказался вариант с мин/макс/средним каналом. И былобы не трое суток а 15 минут (IMG:style_emoticons/default/smile.gif) Изображение было что-то вроде полосато-цветастого значка квейка второго, фон полностью динамичный, изображение имело очень большие отклонения по рендеру, само изображение было огромных размеров, но рендер настолько сильно плавал, что постоянно были ложные срабатывания. При этом еще и искало его 1-3 секунды. Хорошо, что хоть место не критичное по скорости было. Но попал я тогда знатно (IMG:style_emoticons/default/smile.gif)

Сообщение отредактировал DarkMaster - 29.12.2018, 20:31

[sutra]

Хотя, если прицел не плавает, то можно искать и картинкой, только правильной картинкой, например 9 центральных пикселей, вроде такой комбинации красных пикселей не встречал. Только опять же колором эти 9 пикселей найти ещё проще.

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

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

[DarkMaster]

например 9 центральных пикселей, вроде такой комбинации красных пикселей не встречал.

Рамочки вражеский целей могут накладываться и образовывать "пятно". Пятно размером с крест я бы не рассматривал, как совсем из ряда вон, но брать только центр бы не стал (IMG:style_emoticons/default/smile.gif)

Только опять же колором эти 9 пикселей найти ещё проще.

Прицел это только пример той задачи, которая решается фоном и может быть легко решена в текущем имидже (по сути закрасить два десятка пикселей и готово) и костыльными фантазиями, если его не использовать. Когда-то в стародавние времена не было финдов вообще. Решали тогда сочетанием ифов на несколько точек, get color'ом вместо getimage'а собирали массив точек (при этом скорость была не более 30 точек в секунду). И решали задачи, и даже это работало. Причем тогда создать полноценный getimage либо findcolor/findimage было гораздо сложнее, чем решить конкретную задачу и все дружно решали конкретные задачи. Однако сейчас едва ли кто-то скажет, что это разумно (IMG:style_emoticons/default/wink.gif) Сейчас новый виток тех же самых проблем и идей.

как их запихать в один алгоритм я не знаю.

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

[sutra]

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

Рамочки вражеский целей могут накладываться и образовывать "пятно".

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

Если есть желание можем вместе накидать что-то вроде прототипа функции, которая будет работать с правильной логикой.

Посмотрим. Я так своё и не доделал, а там есть над чем поломать голову. Может мысли появятся. Хотя чем я тебе могу быть полезен? Неужели сравнить твой опыт и мой. То, над чем я буду сидеть часами, ты забацаешь за полчаса.

Плюс ты знаешь и понимаешь структуру кода на lua. Моя структура - это Паскаль, тебе такое будет неинтересно. Мысли мои на эту тему ты знаешь на 100%. Будут новые идеи - поделюсь.

[DarkMaster]

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

В реализации кнайта как раз указывая % фактически указываешь количество пикселей. Фон при этом не учитывается. Т.е. если у нас 20 пикселей не фона, то можно указать 90% и это будет означать не менее 18 пикслей. Хотя в данном конкретном случае точность 100% полностью оправдана и deviation 0, т.к. все пиксели прицела будут всегда видны и отклонения по цветам не будет. В данном случае я считаю допустимым исходить из того, что цвет фона не сможет образовать столь большое пятно, чтобы полностью повторить прицел. При этом допущении Стандартный финд даст 100% корректность распознавания. Если же мы не имеем возможности выкинуть фон, то у нас действительно получаются страшные коллизии =)

Моя структура - это Паскаль

Я никогда его в глаза не видел) Даже ide проходя мимо чужого монитора либо скриншот. Ну не пересеклись мы (IMG:style_emoticons/default/smile.gif) Разве что мое переписывание интерфейса плагинов с делфи на си, когда я не знал еще ни того ни другого (си очень поверхностно).

[sutra]

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

Ну и как везде аккуратная работа с памятью. В lua думать на эту тему почти не надо, хотя при использовании ffi словить этот косяк легко, что я уже успешно и делал.

[DarkMaster]

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

В луа таблицы есть суть деревья, а массивы чуть ли не частный случай с виду почти не отличающийся (в потрахах отличается сильно). Лично мне очень легко далась эта информация, т.к. всю жизнь работаю с огромной таблицей/деревом - файловой системой. Вот те самые папочки идеальный наглядный пример того, как выглядит и работает таблица.

хотя при использовании ffi словить этот косяк легко

Тут хотелось бы оговориться, что ffi это не формально не луа. Это расширения о команды luajit, которое не является формально куском луа. Это есть интерфейс в виде модуля/плагина/расширения (выбрать то, что больше нравится). Изначально он разработан для биндингов (импорта дллков сишных без какой-либо их адаптации). То, что мы сделали морду кирпичем, сказали, что самые умные и давай фигачить на нем свои функции - это исключительно наши проблемы (IMG:style_emoticons/default/smile.gif) Взять по сути кусок си и негодавать, что на си приходится писать, как на си, а не как на луа было бы странно (IMG:style_emoticons/default/smile.gif)