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

[_LESTAT_]

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

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

dec R G B
556106 74 124 8
277797 37 61 4

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

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

[DarkMaster]

Подсвеченную так же можно найти get color'ом. Так же есть прекрасное сочетание crtl+b, которое обновляет цвет, снятый по ctrl+a.

Цель разложить цвет на ргб и найти такую же пропорцию? Тогда неизбежно возникает вопрос производительности. Безусловно можно просканировать весь экран, однако это займет достаточно много времени. Чтобы все это сделать адекватно быстро надо бы иметь ограничение хотя бы на один канал хотя бы одной точки. Например мы точно знаем что красный у нас бывает 64, 96 и 128, тогда мы сможем найти подходящие красные точки финдколором и проверить их на другие каналы, а так же точки со смещением.
Насколько разнообразна палитра точек? Не проще сделать набор частных случаев?

https://forum.uokit.com/index.php?s=&am...st&p=176418
разложение на каналы. Кстати можно упростить. Посмотри формулы, там можно подставить значения каналов, чтобы уменьшить количество математики.

Пришла в голову интересная идея. Делаем скриншот среднего состояния, вырезаем кусок с тремя точками. Залазим в paint, все кроме этих точек заливаем одним цветом, в том числе ОБЯЗАТЕЛЬНО левый верхний пиксель. После чего у нас получится рисунок готовый к поиску через findimage. Есть шанс поймать левые изображения, однако их уже гораздо проще и быстрее будет отсеять.

[_LESTAT_]

Объясняю задачу более подробно.
1)Есть рамка(например размером 50 на 55 пикселей),, шириной в 1 пикс, она всегда одного цвета, ее мы легко можем найти в любой момент, она окантовывает картинку, которая изменяется. Она может менять положение на экране, но найти рамку на экране нетрудно,картинка в нутри ее может иметь разную яркость. В одном случае она примерно в два раза ярче, чем в другом. На экране обычно примерно 4-6 таких рамок, каждая со своей картинкой, но нам нужна лишь одна из картинок, для сравнения ее с контрольной. Поэтому мы проверяем все их поочереди. Находим верхний левый угол рамки, и относительно его(внутри рамки) проверяем, три набора координат, например первый 17*17 , второй в центре 25*27 , третий 40 * 47 . Сранивая пиксели в этих координатах, с считающимися контрольными, определенными чуть ранее гет колором, записаными в массиве . Если совпали все три пикселя, значит нашли нужную картинку.
2)Внутри этой рамки могут появляться разные картинки, но всегда одних и тех же размеров, скажем 49 на 54px, вариантов картинок не ограниченно(скажем более 100), многие из которых мне пока не доступны а значит узнать их цвета я пока даже не могу. Поэтому снять разные состояния для каждой картинки не представляется возможным. Зато мы почти на 99.9% уверены, в других картинках, на тех же местах, что эти(хотябы один из трех) пиксели, в тех же координатах, имеют другие цвета, а это значит что с другими картинками мы нужную нам не перепутаем, при этом не имея нигде не винте заготовленых бмп, и заранее сохраненных в файле данных.

Таким способом, создавал массивы для поиска например 10 нужный, среди например 80 разных картинок, по трем статичным пикселям. Это удобно. Намного проче чем юзать финд имейдж и сохранять заранее часть картинки(много же придеться сохранять, картинок ). В одном случае нужны одни предметы, в другом другие, потому, чтобы это сделать придеться емееть 80 маленьких бмп файлов, и сравниватьих друг с другом. Невариант правда ?? Куда проще емть массив, где сохранеты цвета трех пикселей(на статичных координатах), с каждой из картинок. Первичное сохранение кстате тоже делаеться с помощью, автоматически, так что не нужно возьться с принскином и пейнтом, вс каждой из 80 картинок.

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

[DarkMaster]

Тогда вообще не вижу проблемы. Берете три точки, находите коэффициенты, сравниваете.

есть три точки
10 15 20
11 16 21
12 17 22

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

Самый жирный канал у нас получается 22000. Находим коэффициенты относительно других точек:
22000 / 10 = 2200
22000 / 15 = 1466
22000 / 20 = 1100

22000 / 11 = 2000
22000 / 16 = 1375
22000 / 21 = 1047

22000 / 12 = 1833
22000 / 17 = 1294
22000 / 22 = 1000

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

Сообщение отредактировал DarkMaster - 23.10.2012, 15:12

[_LESTAT_]

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

Самый жирный канал у нас получается 22000. Находим коэффициенты относительно других точек

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

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

[DarkMaster]

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

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

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

R=rgbDec-rgbDec/256*256
G=(rgbDec-rgbDec/256/256*256*256)/256
B=rgbDec/256/256

это полноценные формулы для вычисления каналов. Только числа десятичные подставить и все готово.
Можно немного упросить вычисленя:
R=rgbDec-rgbDec/256*256
G=(rgbDec-B*65536)/256
B=rgbDec/256/256

[DarkMaster]

Давайте с примером. Есть три эталонных цвета:

Код

log mode compact

set %color [ 1 1 ] 12642802
set %color [ 2 1 ] 9821212
set %color [ 3 1 ] 6857136

//Для начала разложим их на каналы

for #i 1 3 1
    set %colorRGB [ #i 1 ] %color [ #i 1 ] / 256 / 256 // Синий
    set %colorRGB [ #i 2 ] ( %color [ #i 1 ] - %colorRGB [ #i 1 ] * 65536 ) / 256 // Зеленый
    set %colorRGB [ #i 3 ] %color [ #i 1 ] - %color [ #i 1 ] / 256 * 256 // Красный
log [ #i 1 ]    %colorRGB [ #i 1 ]  
log [ #i 1 ]    %colorRGB [ #i 2 ]
log [ #i 1 ]    %colorRGB [ #i 3 ]
end_for

// Теперь вычислим коэффициенты. Для еще большего упрощения возьмем первый канал первого элемента как базовый. Для точности вычислений умножим его на 1000.

for #i 1 3 1
    for #n 1 3 1
        set #coefBase #coefBase + %colorRGB [ #i #n ]
    end_for
end_for
set #coefBase #coefBase * 1000
log

// Далее вычисляем коэффициенты для каждого из каналов.

for #i 1 3 1
    for #n 1 3 1
        set %colorCoefSource [ #i #n ] #coefBase / %colorRGB [ #i #n ]
log #i #n ]    %colorCoefSource [ #i #n ]   
    end_for
end_for


// Тут пропущены полностью аналогичные действя для найденной точки.
// Единственное отличие: умножать не на 1000, а на 100000.
// Подразумевается что у нас есть массив с кооэфициентами
// для найденной точки %colorCoefFinded

for #i 1 3 1
    for #n 1 3 1
        set %succes [ #i #n ] %colorCoefFinded [ #i #n ] %colorCoefSource [ #i #n ]
log #i #n ]    %succes [ #i #n ]   
    end_for
end_for

// В массиве %succes мы имеем процент совпадения коэффицинта
// каждого канала для каждой точки.

stop_script 

Код полностью не откатывал, но вроде работает.

Сообщение отредактировал DarkMaster - 23.10.2012, 19:53

[DarkMaster]

Там не обработано исключение деления на ноль. Будь осторожен. Обработка с тебя)

[_LESTAT_]

Спасибо большое !
Пока не опробовал, но выглядит впечатляюще, хотя и жаль что для такой казалось бы простой задачи придется увеличить код скрипта на целую четверть. Возможно стоит ввести новые команды по переработке деситичных цветов, в RGB , чтобы такую массивную операцию выполнять одной двумя строками. Это было бы просто великолепно.
Верхнюю часть скрипта, по преобразованию цвета в RGB я понял.
А вот когда дошло дело до "коэффициента" , мозг отказался работа. Что это такое и зачем оно нужно ? Мне кажется коэффициент, это процент совпадения получившегося числа, с ожидаемым, или я не прав ?
тоесть если изначальный RGB у нас 200 100 50 , и мы знаем, что яркость должна снизиться на половину, тоесть до RGB 100 50 25 .
Но что если у нас определилось RGB 100 51 24 ? Нужно как то заставить скрипт принять его за правильный цвет, тоесть задать диапазон, для каждого из трех каналов, скажем +/-2. Мне нужно именно это. Чтобы это сделать и нужен коэффициент ?
Блин мой мозг совсем уже не варит. Попробую снова перечитать завтар пример на свежую голову.

[DarkMaster]

Чтобы это сделать и нужен коэффициент ?

Почти. Коэффициент позволяет проверить соотношение цветов. В приведеном вами примере у вас 4 части первого канала 2 части второго и одна часть третьего. Именно для соблюдения данной пропорции и нужен коэффициент.
По скрипту получится примерно так:
пропорции
200 100 50
1
2
4

100 51 24
100 // помним, что тут на два нуля больше
196
416

100/1=100%
196/2=98%
416/4=104%

Ну и соответственно дальше сравниваешь, что получилось:
if 98 > 97 and 98 < 103
msg успех
end_if

Кстати до меня только сейчас дошло. Правильным будет использовать для базового коэффициента сумму всех каналов. Велосипед изобретал)

Причем надо еще поменять местами каналы и #coefBase, наоборот делить... А все каналы умножить на 1000.... Короче сейчас.

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

[DarkMaster]

Код

log mode compact
log clear

set %color [ 1 1 ] 12642802
set %color [ 2 1 ] 9821212
set %color [ 3 1 ] 6857136

//Для начала разложим их на каналы

for #i 1 3 1
    set %colorRGB [ #i 1 ] %color [ #i 1 ] / 256 / 256 // Синий
    set %colorRGB [ #i 2 ] ( %color [ #i 1 ] - %color [ #i 1 ] / 256 / 256 * 65536 ) / 256 // Зеленый
    set %colorRGB [ #i 3 ] %color [ #i 1 ] - %color [ #i 1 ] / 256 * 256 // Красный
log [ #i 1 ]    %colorRGB [ #i 1 ]  
log [ #i 1 ]    %colorRGB [ #i 2 ]
log [ #i 1 ]    %colorRGB [ #i 3 ]
end_for

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

for #i 1 3 1
    for #n 1 3 1
        set #coefBase #coefBase + %colorRGB [ #i #n ]
    end_for
end_for
log  coefBase #coefBase

for #i 1 3 1
    for #n 1 3 1
        set %colorRGB [ #i #n ] %colorRGB [ #i #n ] * 1000
    end_for
end_for

// Далее вычисляем коэффициенты для каждого из каналов.

for #i 1 3 1
    for #n 1 3 1
        set %colorCoefSource [ #i #n ] %colorRGB [ #i #n ] / #coefBase
log #i #n ]    %colorCoefSource [ #i #n ]   
    end_for
end_for


// Тут пропущены полностью аналогичные действя для найденной точки.
// Единственное отличие: умножать не на 1000, а на 100000.
// Подразумевается что у нас есть массив с кооэфициентами
// для найденной точки %colorCoefFinded

for #i 1 3 1
    for #n 1 3 1
        set %succes [ #i #n ] %colorCoefFinded [ #i #n ] %colorCoefSource [ #i #n ]
log #i #n ]    %succes [ #i #n ]   
    end_for
end_for

// В массиве %succes мы имеем процент совпадения коэффицинта
// каждого канала для каждой точки.

stop_script 

Теперь вроде на правду похоже.

Сообщение отредактировал DarkMaster - 23.10.2012, 21:47

[_LESTAT_]

Сколько не пытался, так ничего и не понял (IMG:style_emoticons/default/sad.gif)
С помощью вашего кода(чуть чуть упорядоченого) с добавлением определения цветов.
Получил три цвета в RGB , получил так называемый коэффициент.
Но вот что делать с ним я так и не знаю, потому что непонимаю , что означает число коэффициента.
И как мне из полученных чисел вычислить, что это теже точки, пусть и с изменившейся яркостью. Вы вроде и разжевали все, но всеравно не понятно. Что делаьт с этими цифрами, прошу сжалиться над моим низким интелектом и продолжить помощь! Вот что вышло из вашего кода:

Запуск первый, при яркой кнопке
10:59:56 4 (, 17): - 1 1 ] 8
10:59:56 4 (, 18): - 1 1 ] 93
10:59:56 4 (, 19): - 1 1 ] 57
10:59:56 4 (, 20): - --------
10:59:57 4 (, 17): - 2 1 ] 5
10:59:57 4 (, 18): - 2 1 ] 75
10:59:57 4 (, 19): - 2 1 ] 47
10:59:57 4 (, 20): - --------
10:59:58 4 (, 17): - 3 1 ] 7
10:59:58 4 (, 18): - 3 1 ] 141
10:59:58 4 (, 19): - 3 1 ] 65
10:59:58 4 (, 20): - --------
10:59:58 4 (, 23): - ================
11:00:01 4 (, 29): - coefBase 498
11:00:04 4 (, 42): - 1 1 ] 16
11:00:05 4 (, 42): - 1 2 ] 186
11:00:05 4 (, 42): - 1 3 ] 114
11:00:05 4 (, 44): - -------------
11:00:06 4 (, 42): - 2 1 ] 10
11:00:06 4 (, 42): - 2 2 ] 150
11:00:06 4 (, 42): - 2 3 ] 94
11:00:07 4 (, 44): - -------------
11:00:07 4 (, 42): - 3 1 ] 14
11:00:07 4 (, 42): - 3 2 ] 283
11:00:08 4 (, 42): - 3 3 ] 130
11:00:08 4 (, 44): - -------------
Тут вроде бы все понятно, скрипт читал цвета, а в коофициэнте выдал в два раза более яркие.(Хотя поидее должен был выдать в два раза более тусклые, Но не суть важно. Важно то, что начальные цвета и коэффициент (чтобы это небыло) различаются почти в два раза.
Запуск два, (по тем же координатам) но когда кнопка стала тусклой.
11:01:05 4 (, 0): - mode compact
11:01:08 4 (, 17): - 1 1 ] 5
11:01:08 4 (, 18): - 1 1 ] 56
11:01:08 4 (, 19): - 1 1 ] 34
11:01:08 4 (, 20): - --------
11:01:09 4 (, 17): - 2 1 ] 3
11:01:09 4 (, 18): - 2 1 ] 45
11:01:09 4 (, 19): - 2 1 ] 28
11:01:09 4 (, 20): - --------
11:01:10 4 (, 17): - 3 1 ] 4
11:01:10 4 (, 18): - 3 1 ] 85
11:01:10 4 (, 19): - 3 1 ] 39
11:01:10 4 (, 20): - --------
11:01:10 4 (, 23): - ================
11:01:13 4 (, 29): - coefBase 299
11:01:16 4 (, 42): - 1 1 ] 16
11:01:17 4 (, 42): - 1 2 ] 187
11:01:17 4 (, 42): - 1 3 ] 113
11:01:17 4 (, 44): - -------------
11:01:18 4 (, 42): - 2 1 ] 10
11:01:18 4 (, 42): - 2 2 ] 150
11:01:18 4 (, 42): - 2 3 ] 93
11:01:18 4 (, 44): - -------------
11:01:19 4 (, 42): - 3 1 ] 13
11:01:19 4 (, 42): - 3 2 ] 284
11:01:20 4 (, 42): - 3 3 ] 130
11:01:20 4 (, 44): - -------------
Что коэффициент выдал здесь, я вообще не понимаю, и прошу разъяснения.
Видимо пока я не пойму, зачем он нужен и что он вычисляет, и как это использовать для моих целей, то так и буду тупить.
Прошу вас DarkMaster-сенсей, помогите достичь просветления.

Сам код:

log mode compact
log clear

get color #col1 150, 105
get color #col2 155, 110
get color #col3 160, 115
set %color [ 1 1 ] #col1
set %color [ 2 1 ] #col2
set %color [ 3 1 ] #col3


//Для начала разложим их на каналы

for #i 1 3 1
set %colorRGB [ #i 1 ] %color [ #i 1 ] / 256 / 256 // Синий
set %colorRGB [ #i 2 ] ( %color [ #i 1 ] - %color [ #i 1 ] / 256 / 256 * 65536 ) / 256 // Зеленый
set %colorRGB [ #i 3 ] %color [ #i 1 ] - %color [ #i 1 ] / 256 * 256 // Красный
log [ #i 1 ] %colorRGB [ #i 1 ]
log [ #i 1 ] %colorRGB [ #i 2 ]
log [ #i 1 ] %colorRGB [ #i 3 ]
log --------
end_for
// Теперь вычислим сумму каналов для того, чтобы узнать какой процент составляет каждый канал.
log ================
for #i 1 3 1
for #n 1 3 1
set #coefBase #coefBase + %colorRGB [ #i #n ]
end_for
end_for
log coefBase #coefBase

for #i 1 3 1
for #n 1 3 1
set %colorRGB [ #i #n ] %colorRGB [ #i #n ] * 1000
end_for
end_for

// Далее вычисляем коэффициенты для каждого из каналов.

for #i 1 3 1
for #n 1 3 1
set %colorCoefSource [ #i #n ] %colorRGB [ #i #n ] / #coefBase
log #i #n ] %colorCoefSource [ #i #n ]
end_for
log -------------
end_for
stop_script

[DarkMaster]

А вы сравните результат первого и второго прогона. Они чрезвычайно близки. Значит все работает.
По факту берется общая сумма каналов(тупо все складывается), а потом вычисляется процент содержания каждого из каналов. Если быть точнее, то промилле ибо результат в тысячных, а не в сотых.

[DarkMaster]

Кстати учитывая точность, то можно обойтись простым арифметическим сравнением, а не вычислять процент совпадения коэффициентов. И выкинуть этот кусок кода.

for #i 1 3 1
for #n 1 3 1
set %succes [ #i #n ] %colorCoefFinded [ #i #n ] %colorCoefSource [ #i #n ]
log #i #n ] %succes [ #i #n ]
end_for
end_for

Сообщение отредактировал DarkMaster - 24.10.2012, 11:43

[_LESTAT_]

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

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

Есть шесть точек, на определенном друг от друга расстоянии
Расположен они так.
1 2
3 4
5 6
Координаты первой известны. Например х=383, y=124
Так же известно расстояние между точками. По оси X = 54 , по оси Y = 74
Промптом запрашиваться число(от 1 до 6) у пользователя, на какую точку переключаться.
Нужно получить координаты этой точки(желательно по проще и как можно компактней в коде).

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

[DarkMaster]

set #xN #xFirst + #xOffset * (#n - #n / 2 * 2)
set #yN #yFirst + #yOffset * ( ( #n - 1 ) / 2)
пробуй

[_LESTAT_]

set #xN #xFirst + #xOffset * (#n - #n / 2 * 2)
set #yN #yFirst + #yOffset * ( ( #n - 1 ) / 2)
пробуй

Спасибо, почти верно, наоснове твоего примера, пришел к верному решению:
set #xN #xFirst + #xOffset - #xOffset * (#n - #n / 2 * 2)
set #yN #yFirst + #yOffset * ( ( #n - 1 ) / 2)

Проверял, вот этим скриптом:

for #n 1 6 1
set #xFirst 383
set #yFirst 124
set #xOffset 54
set #yOffset 74
set #xN #xFirst + #xOffset - #xOffset * (#n - #n / 2 * 2)
set #yN #yFirst + #yOffset * ( ( #n - 1 ) / 2)
move #xN #yN
wait 1s
end_for
stop_script

Еще раз большое спасибо, а то я долго над этим тупил.

[змеючище]

столкнувшись с похожей проблемой(в течении минуты плавают внебольших пределах цвета и яркость)
решил проблему так

взял скрипт отсюда https://forum.uokit.com/index.php?showtopic=22116


// Автор скрипта DarkMasterwait
wait 5s // Делаем паузу, чтобы развернуть нужное приложение и навести мышь на нужную точку.
set timerset #n 1get mouse_pos #x #ywhile timer < 20000 // Собираем все цвета в выбранной точке на протяжении 20 секунд.
get color #colorForArr #x, #y set %colorArr [#n] #colorForArr // Напрямую массив использовать нельзя.
set #n #n + 1end_whilesave_array %colorArr d:\color.txtalarm // Подаем звуковой сигнал об окончании работы скрипта.
stop_script

с его помощью определил диапазаон цветов(время и координаты точки подставить свои), затем взял такой кусочек кода:

set $a findcolor (865, 65 875, 75 1 1 (3754554-6385505) %arr 1) //проверка группы цветов
if $a > 0
.....
......
end_if

проблема была решена опознaвалась группа цветов в точке и окресностях может это подойдёт ?

[_LESTAT_]

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

[DarkMaster]

просто из любопытства. насколько точно другие точки определяются по коэффициентам? Кстати можно несколько увеличить точность, умножая не на 1000, а на 2500(больше вроде точность не увеличит).