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

[sutra]

Ещё раз про концепцию. Сейчас у нас одна проблема, мы пляшем от фона, который задаётся первым пикселем, соответственно ВСЁ остальное будет искаться, а нам зачастую надо лишь 10% от содержимого этой "каши". Надо предусмотреть параметры для задания и фона и искомого, причём предусмотреть возможность их задания и таблицами. Вот тут может понадобиться даже свой deviation для каждого элемента таблицы. Например, задаём искомое {{220,220,220,3},{R(220-250),G(0-20),B(0-40),7}} то есть задали 2 цвета для первого dev 3% для второго dev 7%.

[sutra]

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

[DarkMaster]

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

Всмысле? У нас при загрузке изображения через loadimage прилетает указатель на битовую маску. Если мы создаим некторый массив, то у нас будет тот же самый указатель. В чем разница?

Вот берём оттуда пиксель и прикручиваем к нему ОТНОСИТЕЛЬНЫЙ deviation скажем даже 10% и я уверен, других таких пикселей кроме как в капельках мы не найдём.

Абсолютный я бы не исключал как минимум из-за скорости. Относительный будет тяжелым и с этим нужно считаться.

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

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

[sutra]

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

Абсолютный я бы не исключал как минимум из-за скорости. Относительный будет тяжелым и с этим нужно считаться.

Начнём опять с этого. Я же говорил внутри функции поиска никакой математики. Всё это ПРИ ПОДГОТОВКЕ поиска. Надо будет эту погрешность прикрутить к массиву искомых пикселей... Ну и сколько это займёт для прицела?? Если я этот прицел найду ПЯТЬЮ пикселями. Сколько мне понадобится времени прикрутить к 5 пикселям погрешность и сколько потом понадобится чтобы искать??? ???

Всмысле? У нас при загрузке изображения через loadimage прилетает указатель на битовую маску. Если мы создаим некторый массив, то у нас будет тот же самый указатель. В чем разница?

Адрес на битовую маску - это число. Массив - это таблица. Просто смотрим тип параметра (AdrrArr), если таблица - значит нам подсунули массив, иначе - подсунули адрес на битовую маску. Да, к нам изначально летит указатель, мы его обрабатывая, делаем массив пикселей и в качестве параметра задаём его, а не адрес.

В функцию собственно поиска ВСЕГДА летит таблица пикселей, кроме случая сверхскоростного поиска, когда не нужен никакой предварительный анализ. Это и определяет юзер. Если в качестве параметра задано число (указатель на адрес памяти) значит просто ищем ТО, что задано.

А чем они отличаются то? Что один, что другой массив байт созданный по одним и тем же правилам

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


Правила разные. getimage даёт ВСЕ пиксели. Искомый массив - мизерная часть от того, что будем искать от полученного getimage. Может я непонятно объясняю ... сорри, ну значит придётся выкладывать конкретный код. А ещё лучше... Ставьте конкретную задачу и будем пробовать у кого как работает поиск. Можно например поискать монетки Сайруса. Может с этого и начнём? Или давай свой прицел, хотя бы несколько вариантов его позиционирования, потому, что на единичном варианте примера я его найду почти мгновенно.

Абсолютный я бы не исключал как минимум из-за скорости.

И кто сказал, что его надо исключать?? Ничего не надо исключать, для конкретных условий должен работать конкретный алгоритм, включая и порядок анализа каналов и их количество (каналов) при анализе. Как я это делал - я уже показывал, у меня пока всегда всё находилось даже при анализе только канала BLUE, только намного быстрее, разве что что погрешность чуть больше задавал (в этом случае как раз АБСОЛЮТНУЮ).


Дарк, ты посмотри повнимательнее мой последний (крайний) код поиска. Я то просил, чтобы ты его глянул и указал на огрехи алгоритма и синтаксиса. Неужели неинтересно, как я среди 1000 картинок нахожу искомую менее чем за 1 тысячную секунды???

[sutra]

Код

local function ImageCompareS(addrGet,lenGet,arrpix,fx1,fy1, r1,r2,r3)
-- r1,r2,r3 добавлены параметры порядка просмотра каналов, могут принимать значения 0,1 или 2
-- 2,0,1  сначала RED, потом BLUE, потом GREEN
  for i=1,#arrpix do                                                    -- цикл просмотра значимых пикселей
    local ind=addrGet + (fy1 + arrpix[i].y) * lenGet + (fx1 + arrpix[i].x) * 3 -- вычисление индекса в памяти
    if rmem("unsigned char*",ind)[r1]<arrpix[i][r1].s or rmem("unsigned char*",ind)[r1]>arrpix[i][r1].e then  return false
      else
        if rmem("unsigned char*",ind)[r2]<arrpix[i][r2].s or rmem("unsigned char*",ind)[r2]>arrpix[i][r2].e then  return false
          else
            if rmem("unsigned char*",ind)[r3]<arrpix[i][r3].s or rmem("unsigned char*",ind)[r3]>arrpix[i][r3].e then  return false  end
        end
    end
  end
  return true
end --------------------------------------------------------------------------------

Конечно могу ошибаться, но думаю, что это самые быстрые "кишки" при использовании собственно lua. Что может быстрее искать?? Главное максимально грамотно задать массив искомых пикселей картинки.

В общем, у меня нет проблем с поиском. Попробуйте мне их создать. Я подумаю и сотворю нужный массив поиска (arrpix), задам нужный порядок поиска (для прицела первым будет канал RED). И попробуйте найти быстрее...

[DarkMaster]

Я же говорил внутри функции поиска никакой математики. Всё это ПРИ ПОДГОТОВКЕ поиска.

В рамках относительной прогрешности так не получится. Т.к. имея некоторое соотношение каналов на искомом изображении для пикселя, например, 10/20/33 нам необходимо сравниить с аналогичным соотношением на экране - экран обсчитывать все равно придется, а это шесть операций математических над каждым пикселем.

Если я этот прицел найду ПЯТЬЮ пикселями.

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

Просто смотрим тип параметра (AdrrArr), если таблица - значит нам подсунули массив, иначе - подсунули адрес на битовую маску.

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

Первый - это массив, на который указывает адрес в памяти, второй - это таблица, у неё конечно тоже есть адрес в памяти

Луашная таблица что ли? Значит конвертировать. Кстати на нее адерс можно получить обычным tostring. Хз как она внутри себя хранит элементы, то возможно их напрямую можно будет обрабатывать.

Может с этого и начнём?

Имхо частные случаи вообще можно уже отставить. В частном порядке мы найдем все с разной степенью упорности необходимой для этого. Речь о функции в общем виде. Так, что предлагаю начинать ее писать именно в общем виде. Взять твою готовую базу, докрутить к ней acc и deviation, приркутить буферизацию(кстати можно уже конвертированных изображений). Готово.

Дарк, ты посмотри повнимательнее мой последний (крайний) код поиска. Я то просил, чтобы ты его глянул и указал на огрехи алгоритма и синтаксиса. Неужели неинтересно, как я среди 1000 картинок нахожу искомую менее чем за 1 тысячную секунды???

Я его смотрел, замечаний особо не было. Имхо просто сейчас заходим не с той стороны. Есть куча тонкостей и идей, которые нужно прикручить в уже какую-то существующую базу, основу. У нас этой основы еще нет. Имхо нужно написать именно основу с deviation, acc, прилизать немного синтаксис параметров передаваемых. После чего можно добавлять ифы и жить спокойно. Поэтому я еще раз говорю: дай какой-то код из последних вариантов актуальный на базе которого будем строить. По большому счету там все, что нужно сделать - раздуть if доп условиями.

могут принимать значения 0,1 или 2

-- 2,0,1 сначала RED, потом BLUE, потом GREEN

Порядок имхо нужен обратный - RGB 012 или для простоты 123. Их можно при входе в функцию и конвертнуть при обработке синтаксиса.

Главное максимально грамотно задать массив искомых пикселей картинки.

Суть в том, что, как правило возиться с каждой картинкой и вымерять все по пикселям - это большая трата времени. Индивидуально обработать десяток изображений мелких, с тестами это может и весь день уйти. Вырезать куски 10*10 и покрутить при этом погрешности - 30 минут. Нужно понимать, что никто не будет вымерять изображение, как ты по пикселям пока не припрет. В этом и смысл универсальных функций (IMG:style_emoticons/default/smile.gif)

Итого: взять твой код наиболее актуальный, впихнуть в него acc, deviation1, deviation2 - бета релиз готов.

[sutra]

имея некоторое соотношение каналов на искомом изображении для пикселя, например, 10/20/33 нам необходимо сравниить с аналогичным соотношением на экране - экран обсчитывать все равно придется, а это шесть операций математических над каждым пикселем.

И опять ты меня не понял. Я же дал кишки !!! Это один из конечных вариантов. Ещё раз (делается НЕ РУКАМИ). Предфункция обрабатывает запрос, в качестве параметра в неё задаётся цвет(а) пикселей, из которых будет составлен массив (я его обозвал arrpix). Пример, задаю ... FirstPass(... , ... , "R(180-255)G(0-50)B(0-50)", ...). Эта функция просматривает картинку (например прицел 10х10) и создает массив в которые попадают только пиксели с заданными значениеми каналов RGB (то бишь красные). Так вот ТОЛЬКО к ЭТИМ пикселям мы применяем deviation, создавая элементы arrpix[i].r1 arrpix[i].r2 arrpix[i].g1 и т.д. То есть задаём именно те параметры которые и будут границами поиска пикселей на экране. Как понятнее объяснить не знаю.

[sutra]

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

Да для подавляющего большинства картинок (90% случаев) вообще ничего не надо делать, а искать алгоритмом №1, простым просмотром пикселей с абсолютной погрешностью. Алгоритм, про который я толкую и предназначен для поиска "хитрых" картинок, которых никаким стандартным способом не найти. Ну вот для монеток ... что за работа? Вырезать картинку, пихнуть в редактор, глянуть на цвет ТРЁХ пикселей, глянуть на их координаты, 2 минуты чтобы создать таблицу для 3-х элементов и всех делов. Однако, чтобы даже и этим не заниматься, вот для этого и предусматривается автоматизация. Я уж не говорю, что можно составить скрипт, который сам всё просмотрит и сам составит массив искомых пикселей. Чисто для функциональности и нужно оставить возможность подсовывать в функцию поиска вместо адреса картинки готовый искомый массив.

[sutra]

Мне просто лень доделывать FirstPass (первый проход). И главный момент, любая обработка перед собственно поиском всё равно требует времени. Поиск прицела на огромном экране задача в принципе не быстрая, даже если искать по 5-ти пикселям, поэтому убивать время на любые лишние движения недопустимо. Один раз, при старте скрипта получили (например из файла) таблицу для поиска и всё. Далее тысячи раз используем её и то будет искать около 2 сотых сек. - это у меня, а у кого чахлые камушки?? Плюс ещё время на создание снимка экрана, а он как я уже тоже показывал, весь экран снимает тоже ОЙ как не быстро. Вот и думайте господа, что нужно юзеру, и что мы ему можем дать.

Для поиска текста, алгоритм с использованием arrpix тоже является идеальным, даже бороться со сглаживанием шрифтов не придётся. Первый проход фактически создаёт виртуальный силуэт символа. Достаточно иметь 2 варианта картинок любого символа, которые фиксируют крайние отклонения (влево - вправо) пикселей с базовым цветом и всё. Рендеринг легко преодолеваем параметром deviation. Если есть радуга, то сначала преобразование в монохром, далее всё также.

[sutra]

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

[DarkMaster]

Я же дал кишки !!!

Где? О.О
https://forum.uokit.com/index.php?s=&sh...st&p=430651
Это что ли?
Просто это очень сильно отличается от того, что было. Виноват. Я думал, что это микро-вариант для теста новых плюшек. Код настолько похудел, передача deviation таблицей стала... Я в шоке) Мой косяк.

Мне просто лень доделывать FirstPass (первый проход).

Постараюсь что-нибудь полезное накатать. Со временем сейчас катастрофа. Уже бы, наверное, сам написал львиный кусок и отдал на тесты и оптимизацию.

[sutra]

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

Код настолько похудел

Краткость - сестра таланта. Ничего нового тут придумать нельзя. Скорость зависит от количества математики. Наша задача по возможности сократить математику. Конечно если юзер туп, как пробка, мы ему не поможем. Если он всё будет искать по координатам 1920х1080 (я уж молчу про UHD), ну и пусть сидит и ЖДЁТ. Я бы и с прицелом разобрался, стопудово можно достаточно точно прогнозировать его местоположение и никаких проблем быть не должно, гораздо труднее искать КОГО мочить.

[DarkMaster]

Я бы и с прицелом разобрался, стопудово можно достаточно точно прогнозировать его местоположение

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

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

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

[sutra]

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

Так ведь вообще то предусматривается это делать ОДИН раз. Если нет, то и смысла особого нет. Хоть так, хоть сяк - либо скорость, либо точность.

Я это придумывал, чтобы только в первый раз запускать первый проход, если картинка будет требоваться на протяжении всего скрипта, то далее всё будет быстро, ОСТАВЛЯТЬ готовый массив в памяти.

Кому интересно ... выводы по скорости getimage. До 32К - практически одинаково. Если зона захвата 256К - это уже в 2 раза дольше. То есть если зона снимка более 256К надо уже смотреть, возможно будет быстрее вызвать два раза getimage с меньшими зонами снимков.

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

А вот если нужна и скорость и точность. ВОТ я и предложил вариант, да, надо будет напрячь мозг юзеру. Но если такового нет - ну значит будет юзером-лузером.

Естественный отбор никто пока не отменял.

В конечном итоге всё зависит от стоящей задачи (про типы задач я уже говорил). Вот лично меня, аж гордость распирает. Ведь сделал поиск среди даже 2000 картинок (весьма не маленьких, 500х25) менее 1 тыс. секунды - вот это РЕЗУЛЬТАТ. Естественно нестандартным решением.

Если бы не твой rmem Дарк, то так бы и скал до сих пор джипегами, хотя и там скорость менее 2 сотых.

Принцип прост - надо искать уникальные пиксели. Вот помнишь рассуждали про "O" и "Q". Так вот этот хвостик у Q и есть уникальность, которую ни с чем не перепутать.

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

Вывод. Автоматом всё не сделать. Сделать добротный скелет, оставляя возможность юзеру самому управлять процессом поиска.

[DarkMaster]

Так ведь вообще то предусматривается это делать ОДИН раз. Если нет, то и смысла особого нет

Раз то один, но на все искомое изоражение и на весь кусок экрана в котором ищем. Т.е. это большие площади = тормоз. Одна та причина по которой я не хочу убирать относительную погрешность - она работает намного быстрее. Инструмент должен быть универсален.

Я это придумывал, чтобы только в первый раз запускать первый проход, если картинка будет требоваться на протяжении всего скрипта, то далее всё будет быстро, ОСТАВЛЯТЬ готовый массив в памяти.

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

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

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

[sutra]

и на весь кусок экрана в котором ищем

Или я не понимаю твоих сверхпродвинутых мыслей или вообще плохо понимаю. Ну разъясни. А зачем нам экран? Где ты видел, чтобы я хоть ЧТО-ТО делал с экраном?


Deviation и компенсирует разницу между тем, что есть в картинке и тем, что есть на экране.

Всё-таки ты, Дарк, не улавливаешь мою мысль. Хоть всё по новой начинать объяснять. Давай-ка сначала определимся. 1) Пока забыли про поиск текста. На эту тему я могу отдельную диссертацию оформить.

Какие фокусы могут быть с обычной картинкой? Всего ДВА. Уплыл ФОН или уплыла сама картинка. Вот и давай напрягать мозги.

Следовательно задача №1 отделить фон от не фона.

Здесь только один момент кривой. Если и фон не пойми какой (полупрозрачный) и не фон кривой. МОЙ ОДНОЗНАЧНЫЙ вердикт - стандартно найдёт только свехкомпьютер, на наших "чахотках" нет смысла даже заморачиваться.

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

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

Эх! Отвлекли, чуть позже продолжу ...

[sutra]

Быстренько в 2-х словах про аккуратность. Если просто считать пиксели, то хвостик от "Q" мы не найдём. Вывод - значит так делать не надо. Вариант 2). Считать не пиксели, а скажем отклонение какого-либо канала от нормы, то есть нашли явно не фон, но и от цвета (так обзову фореграунд) сильно отличается. Тут момент интересный, одно понятно - лишние и не хилые тормоза для анализа этой ситуации обеспечены - это раз. А главное, а что мешает поискать при большей погрешности? Я вот так думаю, если при помощи параметра deviation (в его ОТНОСИТЕЛЬНОМ варианте) найти картинку не получается, не надо изобретать велосипед, нехай юзер просто добавит новую картинку в набор, ВОТ И ВСЁ!!

Конечно можно оставить и аккуратность и даже прикрутить к ней хороший алгоритм анализа, только честно предупредить юзера, что это ДОЛГИЙ и не лучший путь. Если ленивому юзеру торопиться некуда, не вопрос. Главное, чтобы неленивый понял, что так лучше не делать.

По большому счёту нужно сделать возможность задавать фон таблицей (можно даже с собственным deviation для каждого элемента), возможность задавать таблицей фореграунд (...). Можно даже предусмотреть направление анализа (сверху-вниз, наоборот, рэндомно ...), можно предусмотреть ШАГ, для уменьшения массива искомых пикселей И ВСЁ!!! Не находит??? Делай новую картинку!

И естественно оставить обычный алгоритм перебора, в большинстве случаев и он отрабатывает на ура.

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

Теоретически, уж не знаю есть ли в этом смысл, можно одновременно искать сразу 2-3 картинки, тоже можно чуток быстрее искать, вот только вопрос, а оно надо?

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

Ну а если чего у кого не будет искаться - спросят ... найдём! Тут вообще по детским вопросам спрашивают и то ничего, отвечаете. А тут высокоинтеллектуальная (для обычного юзера) вещь - спросят, ответим.

А твою мысль я вроде понял, Дарк. Ну что же, тоже имеет право на жизнь. Конечно анализ контрастов и картинки и экрана ... - понятно, что результат будет круче. Ну и прикрути отдельным алгоритмом с параметром SMART. Пусть сидят и ждут, пока алгоритм будет "думать".

Даже интересно потом будет сравнить насколько smart окажется умнее ... думается, что разница будет невелика.

[DarkMaster]

Или я не понимаю твоих сверхпродвинутых мыслей или вообще плохо понимаю. Ну разъясни. А зачем нам экран? Где ты видел, чтобы я хоть ЧТО-ТО делал с экраном?

Если будем искать через deviation в % соотношении между каналами, то нам придется это делать, т.к. этих данных просто нет, а таблицу составить на исходное изображение не представляется возможным. Поясню на примере:
Есть у нас некоторый пиксель:
200 100 50
Если мы допускаем погрешность в 1% в _соотношении_ каналов, то пиксель на экране:
100 50 25
будет идеальным совпадением. И его придется обсчитывать.
Абсолютная же погрешность важна еще в том плане, что необходимо будет отсекать относительную при очень больших смещениях. У нас есть все тот же пиксель:
200 100 50
и дана все та же погрешность 1%. Беда в том, что мы получим совпадение при пикселе:
2 1 5
Причем совпадение это будет опять же идеальным. А это уже просто какое-то черное пятно и его уже никак нельзя автоматом приравнивать к исходному. Чтобы этого не допускать необходимо использовать ограничения в абсолютных значениях каналов либо ограничения по яркости

Код

(r+g+b)

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

Код

(r+g+B)/100

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

Всего ДВА. Уплыл ФОН или уплыла сама картинка. Вот и давай напрягать мозги.

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

А твою мысль я вроде понял, Дарк. Ну что же, тоже имеет право на жизнь. Конечно анализ контрастов и картинки и экрана ... - понятно, что результат будет круче. Ну и прикрути отдельным алгоритмом с параметром SMART. Пусть сидят и ждут, пока алгоритм будет "думать".

Даже интересно потом будет сравнить насколько smart окажется умнее ... думается, что разница будет невелика.

Если я правильно понял, как ты меня понял и допустить, что понял ты меня верно (IMG:style_emoticons/default/biggrin.gif), то для меня весь смысл затеи искать в первую очередь не по цвету пикселя, а по значениям
r/g g/b b/r
Мне вот эти три циферки надо, и надо ограниченить их абсолютным смещением по яркости.

можно предусмотреть ШАГ

в колоре есть параметр шага. На практике использовал полтора раза.


Сообщение отредактировал DarkMaster - 28.1.2019, 14:41

[sutra]

200 100 50

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

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

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

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

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

[sutra]

Попробую ещё на реальном примере объяснить. Вот есть у нас картинка 9х9 на ней есть скажем знак "+" Так вот, если мы изначально корректно зададим силуэт этого плюсика, то в дальнейшем при поиске даже если в координатах 0,0 или 0,1 и т.п. встретится даже абсолютно идентичный пиксель пикселю плюсика, при поиске он будет проигнорирован. Главное изначально верно задать фореграунд. Как и говорил универсально сделать автоматом будет не всегда возможно. Но это редчайший, сложнейший случай, который будет встречаться раз в пятилетку...