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

[sutra]

Ну и ещё раз с чего начал этот пост. Ну вот я без проблем со 100% результатом искал картинку даже на затенённом экране (стандартное затенение 20%) используя только относительный deviation, без всяких ухищрений. Главное, чтобы передний план был более менее стабильным. Ну а так надо пробовать конечно. Я так понимаю у тебя проблема - это всё-таки поиск текста. Там лучше использовать свой подход.

Глянуть бы хотя бы разок на пару вариантов твоих проблем, на какие-нибудь варианты хитрых фонов.

Ну не видел я своими глазами таких сложностей. (IMG:style_emoticons/default/biggrin.gif)

[DarkMaster]

Эх! Блин! Ну зачем же так?? ЕЩЁ РАЗ!!! Абсолютная погрешность 10% - это +-25 к КАЖДОМУ каналу, то есть на экране будут искаться 175-225, 75-125, 25-75 - это быстро, но не совсем правильно. Относительная погрешность 10% - это 200+-10%, 100+-10%, 50+-10% ТО ЕСТЬ на экране будут искаться 180-220, 90-110, 45-55..... Напрягись и пойми разницу. Погрешность, а не разность между каналами. Для каждого пикселя из массива искомых будут свои граничные значения... всё будет искаться так, как надо!!!!!!!

Вот поэтому мы и не могли друг друга понять. Я очень хорошо, слшиком хорошо понимаю разницу. Поэтому я и настаивал на двух вариантах deviation.

понадобится как минимум сочетание

ура. Это та ключевая мысль которую я пытался донести.

Дарк, ты явно перемудрил. У нас картинка 24 бита, чего мы будем заморачиваться на искусственный альфа канал. Хватит нам обычного анализа RGB.

Беда в том, что изображение у нас как раз не 24, а 32 бита, но получаем мы только 24, т.е. без альфаканала. Мы его не искуственно придумываем, а воссоздаем.

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

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

// На заметку. Твой относительный вариант лучше дать задавать не только как +/-, но и как только +N или -N. Причина проста - при наведении на плашки цвет уходит только в одну сторону

Ну не видел я своими глазами таких сложностей.

Я видел. Особенно после апдейтов. На глаз тоже самое, рендеринг съехал. Один велосипед в течении 4 месяцев погрешности правил и рисунки переделывал, дублировал пока он начал стабильно себя вести. 4 месяца! Не скажу, что каждый день, но пару дней в неделю минимум.

[sutra]

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

Особенно после апдейтов

Ха, на то они и апдейты, запросто могут и шрифт поменять.

Особенно после апдейтов. На глаз тоже самое, рендеринг съехал

Так вот для таких случаев и надо выделять чётко и грамотно "стабильные" пиксели.


Ладно, всё понятно. Давай делай, только мне то примеров не дал. Я бы рискнул сделать проще.

Блин 4 месяца. Я с нуля lua более менее освоил, скрипт перерисовал почти. Что-то тут не так. Видимо ходили вокруг проблемы а надо? "Зреть в корень".

Короче, будет время - давай мне свой альфа канал, я сверну ему шею и 24 битами.

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

Вот только для меня остаётся загадкой, а на кой он нужен этот чат? Видимо вы там искусственный интеллект делаете. Неужто многие так делают?

но и как только +N или -N. Причина проста - при наведении на плашки цвет уходит только в одну сторону

До меня только дошло, сорри, "ваще" нет проблем. Если заранее известно, что будет изменение яркости, ЧТО МЕШАЕТ сразу подправить (примитивный пример уже тоже давал). Надо значит задавать параметр изменения яркости и не надо ничего придумывать. Затенилось всё на 20% тупо все каналы делим на 5. Точнее типа вот так raz=rmem("unsigned char*",pg)[x]-rmem("unsigned char*",pl)[x]+rmem("unsigned char*",pl)[x]/5

[DarkMaster]

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

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

[sutra]

Вот кувалдой и правил микроскоп

Я понял, решение есть, как видишь опять не совсем стандартное. Но можно и к стандарту прикрутить. Только лучше всё-таки задать отклонение яркости, чем шерстить всё подряд, да при этом ещё и сильно ухудшая поиск.


Ну ты понял суть, ничего тут сложного нет. Так что мы этот альфа канал согнём в бараний рог.

Пример с компенсацией яркости я привёл реальный. Лень было делать как надо вставил отдельной функцией. Но прикрутить несложно.

изменяющие яркость и цвет при фокусировке, имеющие промежуточные положеня

Ну ведь зависимость то есть? Наверняка прослеживается. Видишь какой интересный момент. Конечно руками можно 100% сделать легко и просто, а вот если автоматизировать, получается что ещё тогда нужен параметр градиента. Короче на все случаи жизни будем делать до конца жизни!
(IMG:style_emoticons/default/blink.gif) (IMG:style_emoticons/default/biggrin.gif)

[cirus]

только мне то примеров не дал

[sutra]

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

Сайрус, распознать буквы или найти целиком?

Очень абстрактно. Что без всякой зависимости так меняется фон?

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

[cirus]

Сайрус, распознать буквы или найти целиком?
Очень абстрактно. Что без всякой зависимости так меняется фон?

Это чат в lineage2, прозрачный. Фон может быть вообще любым. Распознать буквы.

[sutra]

Автоматом вряд ли возможно сделать. Руками можно однозначно всё.

Зависимость фореграунд от бакграунд однозначная, только индивидуальный подход. Вопрос только а зачем это надо. Если конечно убить не одну неделю, можно собрать статистику, никаких картинок, делать матрицу вариантов, я бы так делал если бы ну ОЧЕНЬ БЫЛО НАДО.

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

Если я вырежу эту Н и спрошу у 10 человек что тут нарисовано, я не уверен что все ответят правильно. Так что к функции поиска вопросов быть не должно. Можно пытаться анализировать слова целиком, но для анализа чата это глупо. И главное, я так и не понял ЗАЧЕМ?

И что-то я прозрачности не заметил. Это как раз самый примитивный вариант не заморачиваться на альфа канале, а тупо играть фоном и цветом шрифта. Как хорошо, что я в такое не играю.

[sutra]

Кто ответит правильно, что изображено на картинке? Давайте опросим 10 человек.

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

Только увольте, я на эту чушь своё время тратить не стану. На спор - найду.

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

[DarkMaster]

но это опять ветвление алгоритма

Я предлагаю просто сделать километровый иф. Это очень хорошо может сказать на оптимизации. Вложенность не делать. Один доп иф на подготовку изображений едва ли сильно негативно скажется на скорости.

[sutra]

Я предлагаю просто сделать километровый иф

Ну, а почему бы нет. Вот только Сайруса задачу это не решить. Я не поленился, ещё раз всё посмотрел. Слишком мало данных. Исходя из того, что есть, я найду все 5 символов, на всех фонах. Делать массив искомых пикселей будет отдельный скрипт, как и говорил, если плывёт всё, то автоматом сделать проблематично (хотя имел ввиду невозможно). Уникальные точки есть во всех символах, даже нет смысла смотреть глазками, можно доверить это скрипту, он сам всё найдёт.


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

Я предлагаю просто сделать километровый иф

Я немного не дотянул до километра if(D or((RG or r-g>=RG1 and r-g<=RG2)and(RB or r-b>=RB1 and r-b<=RB2)and(GB or g-b>=GB1 and g-b<=GB2)))and(P or((R or r>=R1 and r<=R2)and(G or g>=G1 and g<=G2)and(B or b>=B1 and b<=B2)))then

[FREEON]

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

[+]

[sutra]

ищу от обратного закрашиваю саму букву в фон

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

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

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

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

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

[sutra]

Мы можем наглым образом объявить значения таблицы, а потом перезаписать имеющимися:Кодlocal function fcolor(my_var) local var = {n1=1, n2=2, n3=3, n4=4} for k, v in next, my_var do -- Перебираем все ключи и значения таблицы t2 local var[k]=v -- Подменяем значение с таким же ключем. endendlocal my_var = {n2=20, n3 = 30}fcolor(my_var)

Скорее привычка доводить всё до ума, чем необходимость, заставила меня попробовать и этот вариант (смотри страничку №9). Ни-хре-на не понял. Точнее мысль уловил, но не понял, что вообще даёт второй вариант. Ну, то, что тут ошибки - это понятно. Но как я не пробовал, ничего у меня не получилось. Итераций в цикле 2 - это понятно, надо исправлять на var. Вопрос про return? почему его нет, а если не нужен, зачем тогда даём в функцию my_var. У меня получилась замена ключа только если в цикле использовать OR. Тогда вопрос, а чем это будет отличаться от первого варианта?

[DarkMaster]

В данном коде оно уже не актуально. Тут даже структур то нет. Кстати а множественные вызовы rmem вместо одного вызова с созданием структуры оказались быстрее?

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

[sutra]

Кстати а множественные вызовы rmem вместо одного вызова с созданием структуры оказались быстрее?

Разброс большой, трудно однозначно сказать. Могу сказать одно - rmem не медленнее всего остального, можно использовать напрямую в ифах.

Вообще arrpix в данном виде грешен. Имхо должна поставляться битовая маска аналогичная бмп

Да думал я и на эту тему. Плохое знание синтаксиса не позволяет мне искать наилучшие решения. Я не знаю, как в lua напрямую работать с битами. Да и давно уж этим не занимался. Смысл этого arrpix в том, чтобы вместо сотни сравнений использовать на порядок меньше - это раз, а второе, мы можем задавать последовательность сравнений при поиске. Стандартно это сложновато прикрутить, а вот руками можно что угодно. Лично я сначала запускаю отдельный скрипт, работает долго, но надёжно. Скрипт сам найдёт уникальные пиксели картинки (из набора картинок). Для случая "хитрого" чата, тоже можно сделать ручной вариант, сначала задаём "скелет" (силуэт), а потом уже на его основе пытаемся сотворить arrpix. Но для хитрого чата, ну вот запросто (даже почти очевидно) может потребоваться и анализ снимка экрана. Уже говорил, пихать это непосредственно в функцию поиска считаю нецелесообразным. Ну если ты сделаешь автоматом поиск такого чата - сниму шляпу. Конечно можно вкорячить и туда IQ, но искать будет на порядки медленнее - оно надо??


Для поиска НЕ ТЕКСТА - этот arrpix - кудесник. Не поверишь, у себя, чисто для прикола, пробовал искать уникальные пиксели... Результат?? Да чем больше или хитрее картинка, тем больше таких пикселей. У меня в большинстве случаев хватает ОДНОГО пикселя. Поиск картинки в конкретной области - всего ОДНО сравнение. Вот в чём смысл. Кстати, если текст более менее адекватный - то же самое... легко найти уникальные пиксели.

Подводный камень всего один. Должна быть 100% уверенность, что на снимке экрана, уникльные пиксели могут присутствовать ТОЛЬКО ЕСЛИ НА ЭКРАНЕ картинка. Ну тут юзер сам должен смотреть.

[sutra]

В общем у меня всё очень просто. Анализирую параметр адреса - if type(p)=="table" then ... подсовываю arrpix в отдельный алгоритм, иначе вызываю стандартный. И задаю необязательный параметр bg_fg (это таблица, позволяющая задать "чёрта лысого"), различаю задан бакграунд или фореграунд и анализируя картинку создаю arrpix. Неплохо бы прикрутить в автоматику и силуэт, чтобы анализировал кроме RGB и координаты, но простого решения на этот случай у меня нет. ВОТ И ВСЯ функция.

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

[sutra]

Единственное, что на текущий момент мне сильно не нравится, что загрузка таблиц (на мой взгляд), ну очень медленная, уже почти секунда, а что будет если ещё будет больше?. При таком то винте, да ещё и со 100% кэшированием, должно хоть сотню мегабайт всасывать мгновенно. Наверное придётся плюнуть и отказаться от чтения в текстовом режиме. Убью время - сделаю как надо в двоичном.

Я это к чему? Если набор картинок сформирован и на ближайшую перспективу обновиться не должен, на фиг вообще нужны картинки, сотворил для каждой свой arrpix, сохранил в файл (файлы). При старте скрипта загрузил и ВСЁ. Будет "летать".

Кому фиолетово и скорость не нужна, ничто не мешает использовать финды по-старинке.

[sutra]

Кстати а множественные вызовы rmem вместо одного вызова с созданием структуры оказались быстрее?

Вообще, по скорости у меня вопросы возникают только при сочетании for и if , настолько нестабильно всё, что толком трудно даже однозначно протестировать. Плюс не даёт покоя сакральное число 56, которое каким-то непостижимым образом, наверное обладая даром экстрасенса, нашёл Сайрус. И которое так магически действовало на if. Почему 56 и 57 так различаются - для меня сущая загадка. Но напрягает такое незнание, так что по возможности лучше избегать таких конструкций.


Да и вообще, динамическая компиляция - такая хитрая штука, иногда просто непонятно как быстрее, раз на раз не приходится. Радует одно, всё-таки тормоза "относительные", так что на логику создания алгоритмов не сильно влияют.